Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64427
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain webstart.fr from 74.125.82.53 cause and error)
MIME-Version: 1.0
In-Reply-To: <4F5D3569.8050307@sugarcrm.com>
References: <CAOfKkdQMOgxBmKSo3DHaJZeHFe4fAOzg8a7amA9_--1=CeSBjA@mail.gmail.com>
	<4F5C5540.8010204@sugarcrm.com>
	<CAORXhG+=Tpzad-OxdWNcZdjvJDrF7jVOtiQ9PGvymL9HQAFEwA@mail.gmail.com>
	<4F5D3569.8050307@sugarcrm.com>
Date: Mon, 24 Dec 2012 13:03:29 -0500
Message-ID: <CAOfKkdTA8E4enoZuJB=ZReF2GMrDFO26PEF0URUAH9HUzHEAHQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Tom Boutell <tom@punkave.com>, Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] CURL file posting
From: pierrick@webstart.fr (Pierrick Charron)

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 '@'. One
problem that we may have to deal with this solution is that the user
will have to add all the post params in 2 steps (first for the string
data and then for the files). Internally, libcurl only allow one call
to CURLOPT_HTTPPOST (second will override the first one), so it may
become unclear either the new data are appended, or overwrite the old
one.

An other solution proposed by =C1ngel Gonz=E1lez was to add a new option
to disable the '@' check, problem with this is that it will only
prevent uploading unwanted files if someone write something starting
with an '@', but it also disable completely the feature.

A last solution would be to something similar to libcurl curl_formadd
(this one could be added to the previous one so that the old way work
but there is a more secure way to do it) :

curl_setopt($curl_handle, CURLOPT_POSTFIELDS, array(
    'firstname' =3D> 'pierrick',
    'lastname' =3D> array(CURLFORM_CONTENTS =3D> 'charron'),
    'lastname' =3D> array(CURLFORM_FILENAME =3D> 'name.png', CURLFORM_FILE
=3D> '/home/pierrick/picture.png', CURLFORM_CONTENTTYPE =3D> 'image/jpg')
);

One thing we have to think about this solution is if at some point we
want to allow sending array via curl, will it conflict ?

Do someone have an other better idea ? Which one would you prefer and
see implemented ?

Thanks all for your inputs

Pierrick

On 11 March 2012 19:29, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi!
>
>> I'd sure like a PHP extension that didn't have this obvious and nasty bu=
g:
>>
>> https://bugs.php.net/bug.php?id=3D46439
>
>
> This doesn't look good. Documentation does say the @ prefix exists, but i=
t
> has very high potential of creating security holes for unsuspecting peopl=
e.
> open_basedir would help limit the impact, but still it's not a good thing=
.
> Any ideas on fixing it without breaking the BC?
> --
> Stanislav Malyshev, Software Architect
> SugarCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>