Re: [PHP] $_POST vs $_REQUEST

[email protected] (Jochem Maas)
Newsgroups php.general
Message-ID <[email protected]>
Op 2/24/10 11:18 AM, Ashley Sheridan schreef:
> On Wed, 2010-02-24 at 07:55 +0000, Jochem Maas wrote:
> 
>> Op 2/22/10 10:49 PM, John Black schreef:
>>> On 02/22/2010 11:42 PM, Michael Shadle wrote:
>>>> The difference here is you can at least have some control over the data
>>>> and expect it in a certain fashion. Also the behavior of cookies vs. get
>>>> vs. post are different (cookies have length and expiration limits, get
>>>> has length limits, post has server confgured limits)
>>>
>>> The cookie and post/get part is all mixed up now :)
>>>
>>> I use $_COOKIE when I want cookie information but I know that the data
>>> is not to be trusted and is easily fabricated.
>>>
>>> When reading get or post I just use $_REQUEST nowadays because I don't
>>> have to care how the submitting form is written. This makes my form
>>> handling data more portable.
>>
>> a. if your updating/inserting/storing data for the user you should require
>> POST in order to mitigate CSRF et al - not to mention using a nonce in your forms.
>>
>> b. when you use $_REQUEST like you do you assume it's either GET or POST data, but
>> it might be COOKIE data ... which will overwrite what is sent via GET or POST in the
>> $_REQUEST array .. which creates a potential for a denial-of-service attack on the
>> users of a site:
>>
>> imagine an 'id' parameter for displaying articles, then imagine a
>> user was tricked into loading a cookie onto his machine for your domain with the
>> name of 'id' and a value of 1 ... said user would only ever be able to see the
>> article referred to be id=1 if you wrote code that took the 'id' parameter from the
>> $_REQUEST var.
>>
>> ... I advocate not trusting any data *and* being explicit about the input vectors
>> on which any particular piece of data is accepted in a given context. (GET, POST and COOKIE
>> are 3 different vectors)
>>
>>
>>
> 
> 
> Which becomes a moot point if you use the request_order ini setting to
> specify the ordering of the overriding of variables in $_REQUEST.

which I think is another bit of magic I can do without. besides you don't
always have control of the ini file (and you obviously can't change this value
during the running of the script as $_REQUEST is already defined)

> I do see what you're getting at, and yes there are concerns to be had
> with one global array overriding another if you don't know to look out
> for such a caveat. The thing is, there are many times where $_REQUEST is
> just perfect. Imagine a stylesheet picker, that remembers the visitors
> choice in a cookie. You can utilise $_REQUEST to handle the whole thing
> very easily, and in a way that makes sense.

which would require a request_order of CPG - the opposite of what it normally is,
which is a complete WTF for any new developer of the code base, all so you can
save a couple of lines of very simple code. I don't think it's worth it.

BUT given that you do know what all the ramification are and can control the
request_order in your environment then it's true to say that in your case there
is no actual problem.

> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
> 
> 
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.