Re: Looking for a reasonable explanation as to why $_REQUEST exists
| From: | Philip Thompson | Date: | Tue, 08 Jul 2008 13:54:00 +0000 |
| Subject: | Re: Looking for a reasonable explanation as to why $_REQUEST exists | ||
| References: | 1 2 3 4 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-276435@lists.php.net to get a copy of this message | ||
On Jul 7, 2008, at 2:19 PM, Eric Butera wrote:
On Mon, Jul 7, 2008 at 2:47 PM, mike <mike503@gmail.com> wrote:Try the shorter if/else... $id = isset ($_POST['id']) ? $_POST['id'] : $_GET['id']; Or, if you wish for _GET to have precedence... $id = isset ($_GET['id']) ? $_GET['id'] : $_POST['id']; Happy coding. ~Philip PS... Not a fan of _REQUEST because... well, it's longer to spell than _POST and _GET! =POn 7/7/08, Eric Butera <eric.butera@gmail.com> wrote:Usually from what I've seen $_REQUEST is a lazy way to get an id from either a post or a get. Say you show a form and the url is page.php?id=x and then you post said page it might include a hidden form field called id so using request you don't have to worry about how to load your record back based on get or post. I'm not saying it is right, but that is how a lot of people use it. If your app is written correctly it doesn't matter what is thrown at it, it should always work. Even if a variable gets overridden it should still be forced to play with the rules of the app and work like a valid request does. I think that having a set of if statements that say something like the following is silly. if (isset($_POST['id'])) { } else if (isset($_GET['id'])) { }Laziness/convenience. I always get my data from the exact source I want. If someone chooses to use REQUEST it shouldn't break their application. You say it is a security risk, but not really. As long as everything is filtered/escaped properly it should be fine because you force the data to play by your rules.I'm not talking about escaping/filtering. I'm talking about variable overriding. In the past, it was $_GET['foo'] $foo register_globals fixed that. however, if your app is relying on $_SESSION['username'] or $_COOKIE['username'] or something like that, depending on the variables order, it can be overridden. I don't see why if you -know- you need $_COOKIE['username'] someone would be lazy and use $_REQUEST['username'] It winds up allowing the end user to override information themselves (again, depending on the variables order) which depending on that and how poor the code is (which to me if you're relying on $_REQUEST you've probably got some bugs and exploitable holes in there) creates a security risk. and session vars are in $_REQUEST, I tried it to sanity check myself before posting this :)
The id should always be a get parameter since it is part of the request to build the state, not the state itself. So on my stuff if I need an id lookup, that is always going to be a GET. My post action will be save?id=x.