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 > > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
