Hi!
> What I wonder about in this thread: If we struggle here why not take
> the full step and abstract curl details comletely away and provide
> something like pecl/http by default instead?
curl extension is widely used. So suggesting we just throw it away makes
no sense to me. We need to fix th
Hi Stas,
I think you're right using object is the safest way to do it safely.
It might look strange because there are no object at all in the
current extension and the procedural function will use in this
specific case an object but still we have to provide a safe way to do
it.
I also agree with
On Wed, Jan 2, 2013 at 4:39 PM, Johannes Schlüter wrote:
>
>
> Stas Malyshev wrote:
>
> >Hi!
> >
> >I'm thinking maybe the best solution is to have a new class - say,
> >CurlFile - and do this:
> >
> >$file = new CurlFile("myface.png", "image/png");
> >curl_setopt($ch, CURLOPT_POSTFIELDS, array("
On Wed, Jan 2, 2013 at 8:39 AM, Johannes Schlüter
wrote:
> Stas Malyshev wrote:
> >I'm thinking maybe the best solution is to have a new class - say,
> >CurlFile - and do this:
> >
> >$file = new CurlFile("myface.png", "image/png");
> >curl_setopt($ch, CURLOPT_POSTFIELDS, array("foo" => "bar", "p
Stas Malyshev wrote:
>Hi!
>
>I'm thinking maybe the best solution is to have a new class - say,
>CurlFile - and do this:
>
>$file = new CurlFile("myface.png", "image/png");
>curl_setopt($ch, CURLOPT_POSTFIELDS, array("foo" => "bar", "picture" =>
>$file);
What I wonder about in this thread: If
Hi!
I'm thinking maybe the best solution is to have a new class - say,
CurlFile - and do this:
$file = new CurlFile("myface.png", "image/png");
curl_setopt($ch, CURLOPT_POSTFIELDS, array("foo" => "bar", "picture" =>
$file);
This would allow us to do two things:
1. Protect ourselves from injectio
Hi,
You're right the proposed implementation did not removed the issue but
was just changing the way to produce it and I agree that the most
secure way to do it would be as you suggested to add a separate option
but I see some issues that we will have.
Usually libcurl doesn't allow to call curl_e
Hi!
> I know this topic was opened a long time ago, but I would like to get
> it resolved before 5.5 got released.
I agree, it looks like a place where we could use improvement, current
API is kind of dangerous.
> A last solution would be to something similar to libcurl curl_formadd
> (this one
Hi all,
I know this topic was opened a long time ago, but I would like to get
it resolved before 5.5 got released.
One solution proposed by Richard Lynch was to add a new
CURLOPT_FILEFIELDS that takes an array of the parameters that are
supposed to be files, so the ones that are expected to have
We could add a flag to disable the @ usage but I'm against having the
'@' usage disabled by default. This BC break would be in my opinion
too big.
An other solution would be to have something like (We will also have
to add the type and filename support to this solution so this is just
a first prop
On 12/03/12 20:36, Richard Lynch wrote:
> On Sun, March 11, 2012 6:29 pm, Stas Malyshev wrote:
>> This doesn't look good. Documentation does say the @ prefix exists,
>> but
>> it has very high potential of creating security holes for unsuspecting
>> people. open_basedir would help limit the impact,
On Sun, March 11, 2012 6:29 pm, Stas Malyshev wrote:
> Hi!
>
>> I'd sure like a PHP extension that didn't have this obvious and
>> nasty bug:
>>
>> https://bugs.php.net/bug.php?id=46439
>
> This doesn't look good. Documentation does say the @ prefix exists,
> but
> it has very high potential of cre
Hi!
I'd sure like a PHP extension that didn't have this obvious and nasty bug:
https://bugs.php.net/bug.php?id=46439
This doesn't look good. Documentation does say the @ prefix exists, but
it has very high potential of creating security holes for unsuspecting
people. open_basedir would help
13 matches
Mail list logo