Answering LIFO:
@
Oren:
and if you don't even know where your data comes from, then you probably won't handle (validate, filter...) it properly.
Bah, cowdung (yay, I beat the smurf filter

). I repeat:
Mordred wrote:True, $_REQUEST may also contain data from other sources, but I usually don't care, and treat them equally (i.e. any unsecure handling I'd do with $_REQUEST, I would have also done with $_GET and $_POST).
"know where your data comes from" is a problem only if one mistakes user input for trusted data. I don't think $_REQUEST looks more trusted than $_GET or $_POST, do
you?
What
feyd "sums up" is an answer to
Everah's concerns about variable overwriting with $_REQUEST, not to the security or insecurity of knowing
"where your data comes from"
Thanks for using
"probably" though, or I'd have accused you of "ad hominem" arguments
@
Everah: I know of the argument and I find it flawed.
In order for this to work, you need a XSS vulnerability on the site, which will have way more severe consequencies than just being able to set a cookie. What setting a cookie would achieve is a fixation of some parameter, which would at most cause a mild DoS for this site (by for example taking the user to the same article id, no matter which article link he clicks on).
@
Jcart: I don't need a request object, I have my nice function, thankyouverymuch

The trouble with more code is not only that it takes longer to execute, but longer to write and read. Also, this concerns the first part of my argument, about the "pros" of using $_REQUEST, while the discussion here is about the second part, that there are no "cons" (my thesis, which you are invited to disprove).
@
Kieran: We shall prevail!
although I rarely have an instance when I don't know the request method going in.
I do, and often, because of the way I handle situations. Some things, like bookmarks and redirects work only with _GET, while (large) forms require using _POST. Because I use reusable encapsulated (/winks at
Jcart) code, $_REQUEST is exactly what I need to make it transparently work in both situations.
(But let's not go into the usability "pros", let's hear arguments about the supposed security "cons".)
@
Everah about
GET and POST are superglobal, so you really don't need to pass them to the function.
Ouch, am I so inexperienced in your eyes?

I know what superglobals are, thankyouverymuch

On a second glance, you will notice though that I don't pass the superglobals themselves, but only the variable I need:
Code: Select all
$nId = GetInt($_REQUEST['id'], 0); //not $_REQUEST, but $_REQUEST['id']
This is done because of two reasons:
1. So I can check if the var is set
2. So I can use the same function for all ocasions that I need a var converted (I have similar functions not only for ints, but for strings and enums and arrays thereof, and the functions themselves can optionally handle additional restrictions, for example ints within a certain boundary etc. etc., in short - it's very useful to me)
I fail to see how
Code: Select all
<?php
$nId = 0;
if (isset($_POST['id']) || isset($_GET['id'])) {
$nId = isset($_POST['id']) ? intval($_POST['id']) : intval($_GET['id']);
}
?>
is simpler than
Code: Select all
$nId = GetInt($_REQUEST['id'], 0);
, or if you insist
Code: Select all
$nId = isset($_REQUEST['id']) ? intval($_REQUEST['id']) : 0;
though
(But let's not go into the usability "pros", let's hear arguments about the supposed security "cons".)