On Wed, 2010-02-24 at 12:34 +0100, Rene Veerman wrote:
> sry i gotta disagree.
> a function that queries $_POST/$_GET first and then $_COOKIE seems
> much wiser to me.
> it consolidates all logic in the script, and making that logic obvious
> by syntax, rather than relying on functionality being determined by
> php.ini, which could well cause a new developer to lose heaps of time
> if he/she has to work on it..
> On Wed, Feb 24, 2010 at 11:18 AM, Ashley Sheridan
> <a...@ashleysheridan.co.uk> wrote:
> > 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.
> > 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.
> > Thanks,
> > Ash
> > http://www.ashleysheridan.co.uk
I don't think ini settings should be disregarded so easily though. There
are plenty of other ini settings that affect global variables, and can
all cause issues that can confuse the unwary developer!