Re: $_PARAMETERS Super Global Object
| From: | Richard Lynch | Date: | Fri, 24 Feb 2012 21:28:46 +0000 |
| Subject: | Re: $_PARAMETERS Super Global Object | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-58026@lists.php.net to get a copy of this message | ||
On Wed, February 22, 2012 9:10 am, Michael Morris wrote:
> $_REQUEST does nothing of the sort, and it's use is dangerous in
> RESTful architecture. $_REQUEST is a smash together of $_GET, $_POST
> and $_COOKIE, in that order but the php.ini directive can change it.
> Hence there's no way of knowing if $_REQUEST['password'] came from
> $_COOKIE, $_POST, or $_GET, and worse, if two values in those source
> arrays have the same key $_REQUEST will overwrite them. $_REQUEST to
> be honest, is a lame shortcut and bad idea almost on par with
> register_globals.
Given that all three of $_GET $_POST and $_COOKIE are equally suspect
from a security POV, and you shouldn't really *care* which way the
client delivered the value, or at least not rely on it for anything
useful, I've never understood the resistance to using $_REQUEST.
Yes, GET should be idempotent, but there are many APIs and functions
in a large app that are idempotent by nature, and having a REST that
just doesn't care how the data comes in allows the consumer of the
service to use whatever they prefer.
If your entire REST service is read-only, such as an RSS feed, why not
allow GET or POST (or, silly as it may be COOKIE) and just use
$_REQUEST.
--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE