On Friday, February 24, 2012 at 5:16 PM, Larry Garfield wrote: > On 2/24/12 3:28 PM, Richard Lynch wrote: > > 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. > > > > > Because GET and POST are not even remotely the same thing and treating > them as completely interchangeable is a bug in the first place. It is > in fact legal to have both in the same request. Then what do you do? > >
The same thing that is done with $_REQUEST and virtually any other global parameter-based framework. You set your data priority. If you need to access them separately, then you can do that. What Richard said wasn't that they are identical, rather they should be treated with equal security measures. The idea that POST is more secure than GET is ridiculous. That said, you *should* care about which section of the request header you submit the data (e.g. you obviously don't want your login form to submit via GET). > > The idea of having a real request object in PHP is a good one; however, > a superglobal is not it. Making it a superglobal eliminates the value > of a real request object, namely that you can encapsulate it, override > it locally, pass it around, mock it for testing, etc. in a safe fashion. > A superglobal request object is a complete waste of time. > > There are a number of existing request object libraries out there > already. PECL HTTP in C, both Zend and Symfony2 have their versions, > etc. Drupal is in the process of moving to Symfony's. Any PHP-core > request object (which in general I will agree is a good thing, and > something sorely missing in the language today) should be based on one > of those, where there's already existing work done to work out the > kinks. Simply throwing $_GET onto a property of a superglobal object > does not accomplish anything useful. > > As you noted, every framework has their own version of request/response objects. This is the job of a framework and not the core language. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
