Stas Malyshev smalys...@sugarcrm.com 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:
On Wed, Jan 2, 2013 at 8:39 AM, Johannes Schlüter
johan...@schlueters.de wrote:
Stas Malyshev smalys...@sugarcrm.com 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,
On Wed, Jan 2, 2013 at 4:39 PM, Johannes Schlüter johan...@schlueters.dewrote:
Stas Malyshev smalys...@sugarcrm.com 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,
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
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 this
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 injection since you
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
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
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
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 creating
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, but
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
13 matches
Mail list logo
