Looking for a reasonable explanation as to why $_REQUEST exists

I have never had a use for this feature. To me it introduces another
register_globals style atttack vector. I see no need why people need
to combine post/get/etc variables into the same superglobal. I
actually run unset($_REQUEST) on it at the top of my library to
discourage its use.

For third party products which use it I tell people to combine it
themselves by using array_merge() - like $_REQUEST =
array_merge($_POST, $_GET) etc...

Anyway can someone here please give me a good reasoning why it should
exist? It isn't as easily abused as register_globals but when people
have a session variable they want to access and use $_REQUEST for it I
could easily override it by using a GET param on the url (depending on
how the order of globals get processed)

Simply put, I see no reason why people would not want to clearly
define where they are getting their input from. If for some reason
there is some need to lazily code something I would still say to do
something like:

if(isset($_GET['foo'])) {
$foo = $_GET['foo'];
} elseif(isset($_POST['foo'])) {
$foo = $_POST['foo'];
} else {
$foo = 'default value';
}

.... or just do the array merge.

But please someone maybe can justify this to me... I've been using
superglobals before I really understood how important they were and
then one day I see they introduced $_REQUEST and thought .. okay that
seems stupid. I finally am deciding to see if anyone can give me a
reason as to why this is useful and not just a lazy coding practice
that can lead to security risks.

You don't really know if your data is coming from GET, from POST, a
SESSION variable, etc...

I'd love to see a good discussion going on this. I might have
overlooked something important.

mike schreef:
> I have never had a use for this feature. To me it introduces another
> register_globals style atttack vector. I see no need why people need
> to combine post/get/etc variables into the same superglobal. I
> actually run unset($_REQUEST) on it at the top of my library to
> discourage its use.
>
> For third party products which use it I tell people to combine it
> themselves by using array_merge() - like $_REQUEST =
> array_merge($_POST, $_GET) etc...
>
> Anyway can someone here please give me a good reasoning why it should
> exist? It isn't as easily abused as register_globals but when people
> have a session variable they want to access and use $_REQUEST for it I
> could easily override it by using a GET param on the url (depending on
> how the order of globals get processed)
>
> Simply put, I see no reason why people would not want to clearly
> define where they are getting their input from. If for some reason
> there is some need to lazily code something I would still say to do
> something like:
>
> if(isset($_GET['foo'])) {
> $foo = $_GET['foo'];
> } elseif(isset($_POST['foo'])) {
> $foo = $_POST['foo'];
> } else {
> $foo = 'default value';
> }
>
> ... or just do the array merge.
>
> But please someone maybe can justify this to me... I've been using
> superglobals before I really understood how important they were and
> then one day I see they introduced $_REQUEST and thought .. okay that
> seems stupid. I finally am deciding to see if anyone can give me a
> reason as to why this is useful and not just a lazy coding practice
> that can lead to security risks.
>
> You don't really know if your data is coming from GET, from POST, a
> SESSION variable, etc...
>
> I'd love to see a good discussion going on this. I might have
> overlooked something important.

Hi Mike,

my 2 cent:

I can only say I agree with you.
$_REQUEST offers at most a shorthand for situations seldom met, and even
then it can be avoided with a few more characters of code.

In my humble opinion, using $_REQUEST as a programmer only shows you
don't know where your data comes from.

The only situation I found myself in when I was temped to use it was this:
1) My existing scripts expected $_POST["acrticleid"].
$articleid = (int)$_POST["articleid"];

2) During the process of adding extra functionality I started to use
that script too from an URL in an email, like this:
http://www.example.com/showarticle.pgp?articleid=23

So using $_REQUEST["articleid"] could make some sense, but I found it
totally ugly, not to mention I MIGHT add articleid to cookies later for
some reason and screw up my existing script.
The simple solution, you know already of course, was:

$articleid = -1;
// The script used -1 for non existant message.
if (isset($_POST["articleid"])){
$articleid = (int)$_POST["articleid"];
} else {
if (isset($_GET["articleid"])){
$articleid = (int)$_GET["articleid"];
}
}

A few more lines of code, and no need for $_REQUEST[].
(The above can also be written on 1 line using ternary operators.)

I never used it, and will never use it.
In my years on comp.lang.php I also found a few others who think this
superglobal is a bad addition to the language.

Regards,
Erwin Moller

On Mon, Jul 7, 2008 at 3:10 AM, mike <mike503@gmail.com> wrote:
> I have never had a use for this feature. To me it introduces another
> register_globals style atttack vector. I see no need why people need
> to combine post/get/etc variables into the same superglobal. I
> actually run unset($_REQUEST) on it at the top of my library to
> discourage its use.
>
> For third party products which use it I tell people to combine it
> themselves by using array_merge() - like $_REQUEST =
> array_merge($_POST, $_GET) etc...
>
> Anyway can someone here please give me a good reasoning why it should
> exist? It isn't as easily abused as register_globals but when people
> have a session variable they want to access and use $_REQUEST for it I
> could easily override it by using a GET param on the url (depending on
> how the order of globals get processed)
>
> Simply put, I see no reason why people would not want to clearly
> define where they are getting their input from. If for some reason
> there is some need to lazily code something I would still say to do
> something like:
>
> if(isset($_GET['foo'])) {
> $foo = $_GET['foo'];
> } elseif(isset($_POST['foo'])) {
> $foo = $_POST['foo'];
> } else {
> $foo = 'default value';
> }
>
> ... or just do the array merge.
>
> But please someone maybe can justify this to me... I've been using
> superglobals before I really understood how important they were and
> then one day I see they introduced $_REQUEST and thought .. okay that
> seems stupid. I finally am deciding to see if anyone can give me a
> reason as to why this is useful and not just a lazy coding practice
> that can lead to security risks.
>
> You don't really know if your data is coming from GET, from POST, a
> SESSION variable, etc...
>
> I'd love to see a good discussion going on this. I might have
> overlooked something important.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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 don't trust any piece of data that exists on
my site whether it comes from request data, the database, or
filesystem. So whether id comes from get or post doesn't matter
because I always require it to be an int so it really wouldn't matter
the origin.

Eric Butera wrote:
> On Mon, Jul 7, 2008 at 3:10 AM, mike <mike503@gmail.com> wrote:
>> I have never had a use for this feature. To me it introduces another
>> register_globals style atttack vector. I see no need why people need
>> to combine post/get/etc variables into the same superglobal. I
>> actually run unset($_REQUEST) on it at the top of my library to
>> discourage its use.
>>
>> For third party products which use it I tell people to combine it
>> themselves by using array_merge() - like $_REQUEST =
>> array_merge($_POST, $_GET) etc...
>>
>> Anyway can someone here please give me a good reasoning why it should
>> exist? It isn't as easily abused as register_globals but when people
>> have a session variable they want to access and use $_REQUEST for it I
>> could easily override it by using a GET param on the url (depending on
>> how the order of globals get processed)
>>
>> Simply put, I see no reason why people would not want to clearly
>> define where they are getting their input from. If for some reason
>> there is some need to lazily code something I would still say to do
>> something like:
>>
>> if(isset($_GET['foo'])) {
>> $foo = $_GET['foo'];
>> } elseif(isset($_POST['foo'])) {
>> $foo = $_POST['foo'];
>> } else {
>> $foo = 'default value';
>> }
>>
>> ... or just do the array merge.
>>
>> But please someone maybe can justify this to me... I've been using
>> superglobals before I really understood how important they were and
>> then one day I see they introduced $_REQUEST and thought .. okay that
>> seems stupid. I finally am deciding to see if anyone can give me a
>> reason as to why this is useful and not just a lazy coding practice
>> that can lead to security risks.
>>
>> You don't really know if your data is coming from GET, from POST, a
>> SESSION variable, etc...
>>
>> I'd love to see a good discussion going on this. I might have
>> overlooked something important.
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>
> 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 don't trust any piece of data that exists on
> my site whether it comes from request data, the database, or
> filesystem. So whether id comes from get or post doesn't matter
> because I always require it to be an int so it really wouldn't matter
> the origin.

When you use register_globals it extracts the vars from get, post,
cookie and session, or used to. But, I don't think session vars are in
$_REQUEST.

-Shawn

On Mon, Jul 7, 2008 at 11:23 AM, Shawn McKenzie <nospam@mckenzies.net> wrote:
> When you use register_globals it extracts the vars from get, post, cookie
> and session, or used to. But, I don't think session vars are in $_REQUEST.
>
> -Shawn


http://us2.php.net/manual/en/ini.cor....request-order

[snip]
When you use register_globals it extracts the vars from get, post,
cookie and session, or used to. But, I don't think session vars are in
$_REQUEST.
[/snip]

$_REQUEST is no different than $_POST or $_GET from a security
standpoint. And using register_globals did not carry a security risk as
long as the programmer did every responsible thing with regard to that
input.

$_GET['foo']
$_POST['foo']
$_REQUEST['foo']
$foo

It is all a matter of how you handle foo, the rest is semantics.

Eric Butera wrote:
> On Mon, Jul 7, 2008 at 11:23 AM, Shawn McKenzie <nospam@mckenzies.net> wrote:
>> When you use register_globals it extracts the vars from get, post, cookie
>> and session, or used to. But, I don't think session vars are in $_REQUEST.
>>
>> -Shawn
>
>
> http://us2.php.net/manual/en/ini.cor....request-order

So I was 50% correct. That's better than my normal 0%-33%.

-Shawn

On Mon, Jul 7, 2008 at 11:23 AM, Shawn McKenzie <nospam@mckenzies.net> wrote:
>
> When you use register_globals it extracts the vars from get, post, cookie
> and session, or used to. But, I don't think session vars are in $_REQUEST.

They can be. Google "EGPCS".

--
</Daniel P. Brown>
Dedicated Servers - Intel 2.4GHz w/2TB bandwidth/mo. starting at just
$59.99/mo. with no contract!
Dedicated servers, VPS, and hosting from $2.50/mo.

On Mon, Jul 7, 2008 at 11:36 AM, Shawn McKenzie <nospam@mckenzies.net> wrote:
> So I was 50% correct. That's better than my normal 0%-33%.

Haha ;)

They can be what? I was wrong, the S is $_SERVER not $_SESSION.

-Shawn

Daniel Brown wrote:
> On Mon, Jul 7, 2008 at 11:23 AM, Shawn McKenzie <nospam@mckenzies.net> wrote:
>
>> When you use register_globals it extracts the vars from get, post, cookie
>> and session, or used to. But, I don't think session vars are in $_REQUEST.
>>
>
> They can be. Google "EGPCS".
>
>