To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.
I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them all
(well, most) together again and allows for a POST to override a GET or
a SESSION var (depending on your settings of course)
If people want something like $_REQUEST they can make their own
$_REQUEST = array_merge($_GET, $_POST, etc)
or
if(isset($_GET['myvar'])) {
do stuff;
} elseif(isset($_POST['myvar'])) {
do stuff;
}
I actually unset($_REQUEST) in my framework so the developers on my
team can't use it. If I ever have a mixed source where I'm not sure if
it it's a POST or GET, I use an example like the second one - that
gives me ultimate control of the order in which I trust the variables
and such.
Seems to me with PHP 5.3 requiring changes to adopt and PHP 6 with
code change requirements, I would personally recommend removing
$_REQUEST (along with $HTTP_GET_VARS, $HTTP_POST_VARS, and all the
other long versions, again, something I unset just in case some junior
developer steals some code or doesn't understand the shorthand
superglobal exists already...)
I can see (albeit with mixed acceptance) the need to look at GET,
POST, and whatever other sources $_REQUEST might pull in for some
certain applications because they're not sure if it comes through.
Personally I always make sure it comes through one way or the other;
but I guess that is not always the case. But for those cases, there
are easy enough ways to code around it, doing something like example
#1, for instance. Then, you can control the order of trust wherever
you use it - perhaps sometimes you want to prefer POST first,
sometimes you want to prefer SESSION first, etc...
I don't know of any other reasoning behind this and have brought this
up with many people, possibly even this list in the past. But since
changes have to occur anyway for 5.3 and 6, maybe one of those can
actually implement this removal?
Thanks,
mike
Michael Shadle wrote:
To me, it basically creates some laziness and reintroduces a vector on
the register_globals issue.I've been using $_GET $_POST $_COOKIE $_SESSION $_SERVER etc. since
they were introduced, and have never had any problems. Was there a
reasoning behind making a variable that essentially glues them all
(well, most) together again and allows for a POST to override a GET or
a SESSION var (depending on your settings of course)If people want something like $_REQUEST they can make their own
$_REQUEST = array_merge($_GET, $_POST, etc)
or
if(isset($_GET['myvar'])) {
do stuff;
} elseif(isset($_POST['myvar'])) {
do stuff;
}I actually unset($_REQUEST) in my framework so the developers on my
team can't use it. If I ever have a mixed source where I'm not sure if
it it's a POST or GET, I use an example like the second one - that
gives me ultimate control of the order in which I trust the variables
and such.Seems to me with PHP 5.3 requiring changes to adopt and PHP 6 with
code change requirements, I would personally recommend removing
$_REQUEST (along with $HTTP_GET_VARS, $HTTP_POST_VARS, and all the
other long versions, again, something I unset just in case some junior
developer steals some code or doesn't understand the shorthand
superglobal exists already...)I can see (albeit with mixed acceptance) the need to look at GET,
POST, and whatever other sources $_REQUEST might pull in for some
certain applications because they're not sure if it comes through.
Personally I always make sure it comes through one way or the other;
but I guess that is not always the case. But for those cases, there
are easy enough ways to code around it, doing something like example
#1, for instance. Then, you can control the order of trust wherever
you use it - perhaps sometimes you want to prefer POST first,
sometimes you want to prefer SESSION first, etc...I don't know of any other reasoning behind this and have brought this
up with many people, possibly even this list in the past. But since
changes have to occur anyway for 5.3 and 6, maybe one of those can
actually implement this removal?Thanks,
mike
bc? all the reasoning in the world won't justify it to 1 million
businesses running php 4 code which is reliant on $_REQUEST behind the
scenes.
although it would generate a tonne of freelance work :p
bc? all the reasoning in the world won't justify it to 1 million businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.although it would generate a tonne of freelance work :p
that code has to change for 5.3 or 6.0 anyway.
now is the time to yank out some of the legacy crap. we don't want PHP
to be like windows, do we?
2009/5/15 Michael Shadle mike503@gmail.com
bc? all the reasoning in the world won't justify it to 1 million businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.although it would generate a tonne of freelance work :p
that code has to change for 5.3 or 6.0 anyway.
now is the time to yank out some of the legacy crap. we don't want PHP
to be like windows, do we?
Hello,
I think Michael's vision is right in this area, maybe bc could just be
achieved having a "register_request" INI parameter that is set by
default to OFF that people just have to enable if they rely on
$_REQUEST.
We could manage it the same way register_globals is:
"This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0"
Patrick
I think this strikes a good balance between backward compatibility...
I would hope though the code for it is very simple, to not add
overhead to PHP. Basically in PHP the pseudocode equivalent would be
if(ini_get('reigster_request') == true) {
$_REQUEST = array_merge($_GET, $_POST, $_COOKIE, $_SESSION);
}
On Thu, May 14, 2009 at 11:01 PM, Patrick ALLAERT
patrick.allaert@gmail.com wrote:
Hello,
I think Michael's vision is right in this area, maybe bc could just be
achieved having a "register_request" INI parameter that is set by
default to OFF that people just have to enable if they rely on
$_REQUEST.
We could manage it the same way register_globals is:
"This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0"Patrick
Michael Shadle wrote:
bc? all the reasoning in the world won't justify it to 1 million businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.although it would generate a tonne of freelance work :p
that code has to change for 5.3 or 6.0 anyway.
now is the time to yank out some of the legacy crap. we don't want PHP
to be like windows, do we?
The more stuff like this we remove, the harder it becomes for people to
quickly move to newer, faster and more secure versions of PHP. That
causes way more frustration for everyone than a few "ugly" legacy
features. If there is a decent technical reason, performance or
security, then we need to take a hard look at it. In this case, the
thing we should be looking at isn't whether we should remove $_REQUEST
but whether we should remove cookie data from it. Many configurations
already do that, including all of my own, and there is a strong valid
security reason for not including cookies in $_REQUEST. Most people use
$_REQUEST to mean GET or POST, not realizing that it could also contain
cookies and as such bad guys could potentially do some cookie injection
tricks and break naive applications.
-Rasmus
Michael Shadle wrote:
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrixham@gmail.com
wrote:bc? all the reasoning in the world won't justify it to 1 million
businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.although it would generate a tonne of freelance work :p
that code has to change for 5.3 or 6.0 anyway.
now is the time to yank out some of the legacy crap. we don't want
PHP
to be like windows, do we?The more stuff like this we remove, the harder it becomes for people
to
quickly move to newer, faster and more secure versions of PHP. That
causes way more frustration for everyone than a few "ugly" legacy
features. If there is a decent technical reason, performance or
security, then we need to take a hard look at it. In this case, the
thing we should be looking at isn't whether we should remove $_REQUEST
but whether we should remove cookie data from it. Many configurations
already do that, including all of my own, and there is a strong valid
security reason for not including cookies in $_REQUEST. Most people
use
$_REQUEST to mean GET or POST, not realizing that it could also
contain
cookies and as such bad guys could potentially do some cookie
injection
tricks and break naive applications.
Its already fixed in 5.3. There is a new ini option that defines what
should go into $_REQUEST. See the following blog post for details:
http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/
Also a lot of work was put into restructuring the php.ini files we
ship with PHP.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Lukas Kahwe Smith wrote:
Michael Shadle wrote:
On Thu, May 14, 2009 at 3:03 PM, Nathan Rixham nrixham@gmail.com
wrote:bc? all the reasoning in the world won't justify it to 1 million
businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.although it would generate a tonne of freelance work :p
that code has to change for 5.3 or 6.0 anyway.
now is the time to yank out some of the legacy crap. we don't want PHP
to be like windows, do we?The more stuff like this we remove, the harder it becomes for people to
quickly move to newer, faster and more secure versions of PHP. That
causes way more frustration for everyone than a few "ugly" legacy
features. If there is a decent technical reason, performance or
security, then we need to take a hard look at it. In this case, the
thing we should be looking at isn't whether we should remove $_REQUEST
but whether we should remove cookie data from it. Many configurations
already do that, including all of my own, and there is a strong valid
security reason for not including cookies in $_REQUEST. Most people use
$_REQUEST to mean GET or POST, not realizing that it could also contain
cookies and as such bad guys could potentially do some cookie injection
tricks and break naive applications.Its already fixed in 5.3. There is a new ini option that defines what
should go into $_REQUEST. See the following blog post for details:
http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/Also a lot of work was put into restructuring the php.ini files we ship
with PHP.
Right, I obviously know that, I should have explained better. What I
meant by removing cookie data from $_REQUEST was to never allow it at
all. Right now you have to set request_order to "GP" in order to not
get it. If, like most people, you upgrade and use the same php.ini file
as before, then we default back to variables_order which has always
included cookie data by default. So, as much as I appreciate the work
that has gone into the new recommended php.ini settings, we all know
that most people completely ignore our .ini suggestions and go with
whatever their distro chooses or whatever they have had in there since
their PHP4 days. My prediction is that the bulk of people after
upgrading to 5.3 will still have cookies in their $_REQUEST.
-Rasmus
Michael Shadle wrote:
bc? all the reasoning in the world won't justify it to 1 million
businesses
running php 4 code which is reliant on $_REQUEST behind the scenes.although it would generate a tonne of freelance work :p
that code has to change for 5.3 or 6.0 anyway.
now is the time to yank out some of the legacy crap. we don't want PHP
to be like windows, do we?The more stuff like this we remove, the harder it becomes for people to
quickly move to newer, faster and more secure versions of PHP. That
causes way more frustration for everyone than a few "ugly" legacy
features. If there is a decent technical reason, performance or
security, then we need to take a hard look at it. In this case, the
thing we should be looking at isn't whether we should remove $_REQUEST
but whether we should remove cookie data from it. Many configurations
already do that, including all of my own, and there is a strong valid
security reason for not including cookies in $_REQUEST. Most people use
$_REQUEST to mean GET or POST, not realizing that it could also contain
cookies and as such bad guys could potentially do some cookie injection
tricks and break naive applications.Its already fixed in 5.3. There is a new ini option that defines what should
go into $_REQUEST. See the following blog post for details:
And simplified version in the docs http://php.net/request_order
-Hannes
The more stuff like this we remove, the harder it becomes for people to
quickly move to newer, faster and more secure versions of PHP. That
causes way more frustration for everyone than a few "ugly" legacy
features. If there is a decent technical reason, performance or
security, then we need to take a hard look at it. In this case, the
thing we should be looking at isn't whether we should remove $_REQUEST
but whether we should remove cookie data from it. Many configurations
already do that, including all of my own, and there is a strong valid
security reason for not including cookies in $_REQUEST. Most people use
$_REQUEST to mean GET or POST, not realizing that it could also contain
cookies and as such bad guys could potentially do some cookie injection
tricks and break naive applications.
But since there is going to be a dramatic change here anyway, this is
the perfect time to do it. To me adding namespaces is a lot more scary
and will lead to a lot of confusing code...
P.S. It looks like you'll be speaking at OSBridge in Portland in a
month or so. If I attend I look forward to meeting you and thanking
you for PHP :)
Its already fixed in 5.3. There is a new ini option that defines what should
go into $_REQUEST. See the following blog post for details:
http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/Also a lot of work was put into restructuring the php.ini files we ship with
PHP.
This is a good step I think; will it be possible to allow it to be
empty and have $_REQUEST not exist or even be initialized?
Also, you said it yourself in your blog - not caring what is done via
GET and POST is bad practice. Why not enforce this in the engine?
It makes PHP look insecure when apps have security issues because of
poor coding. It's not because PHP itself had a flaw, but to a lot of
people, they see "PHPNuke" or know that postnuke runs under PHP, or
phpbb, etc - the language -can- enforce better techniques, especially
since 5.3 and 6.0 will require some changes in code anyway; this one
is a pretty simple change too -
Someone could make a function like import_request_variables() but
allow it to re-create $_REQUEST and tell people to put it at the top
of their scripts or a central include file if they're too lazy to fix
their code to be more secure. I for one would love to see this be
enforced at the engine level, so that packages I wind up having to use
like Wordpress/etc. have been forced to change their logic (hopefully)
to go back to $_GET, $_POST etc.
Also, I had thought $_REQUEST had included session data too. At least
that is not there. Talk about easy exploitation options then! :)
On Fri, May 15, 2009 at 1:32 AM, Lukas Kahwe Smith
mls@pooteeweet.org wrote:The more stuff like this we remove, the harder it becomes for
people to
quickly move to newer, faster and more secure versions of PHP. That
causes way more frustration for everyone than a few "ugly" legacy
features. If there is a decent technical reason, performance or
security, then we need to take a hard look at it. In this case, the
thing we should be looking at isn't whether we should remove
$_REQUEST
but whether we should remove cookie data from it. Many
configurations
already do that, including all of my own, and there is a strong
valid
security reason for not including cookies in $_REQUEST. Most
people use
$_REQUEST to mean GET or POST, not realizing that it could also
contain
cookies and as such bad guys could potentially do some cookie
injection
tricks and break naive applications.But since there is going to be a dramatic change here anyway, this is
the perfect time to do it. To me adding namespaces is a lot more scary
and will lead to a lot of confusing code...
Confusing new code is totally different from breaking existing code.
Its already fixed in 5.3. There is a new ini option that defines
what should
go into $_REQUEST. See the following blog post for details:
http://www.suspekt.org/2008/10/01/php-53-and-delayed-cross-site-request-forgerieshijacking/Also a lot of work was put into restructuring the php.ini files we
ship with
PHP.This is a good step I think; will it be possible to allow it to be
empty and have $_REQUEST not exist or even be initialized?Also, you said it yourself in your blog - not caring what is done via
GET and POST is bad practice. Why not enforce this in the engine?
Just FYI: Not sure which blog you are talking about, but that is
Stefan Esser's blog that is linked above.
Also, I had thought $_REQUEST had included session data too. At least
that is not there. Talk about easy exploitation options then! :)
Indeed, that would have been insane.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Confusing new code is totally different from breaking existing code.
True but aren't some changes in 6.0 at least (and possibly 5.3) going
to require code changes? Or is it still going to be "legacy enough" ?
There's gotta be a time in the natural evolution to "cut the cord" so
to speak - Python just launched 3.0 and dropped backwards
compatibility. Why can't PHP do the same in 6.0? :) (Or 5.3 for all I
care. But it really should align with a major revision #)
Just FYI: Not sure which blog you are talking about, but that is Stefan
Esser's blog that is linked above.
Sorry, used to most people pushing their own blog links :)
Am Freitag, 15. Mai 2009 schrieb Michael Shadle:
Hallo,
There's gotta be a time in the natural evolution to "cut the cord" so
to speak - Python just launched 3.0 and dropped backwards
compatibility. Why can't PHP do the same in 6.0? :) (Or 5.3 for all I
care. But it really should align with a major revision #)
Splitting PHP in 3 independent parts could help solving the
backwards problem.
-
Library (Functions, Methods)
-
Virtual Machine (Zend Engine)
-
Compiler for PHP 5.2, PHP 6, ...
Library | VM | P-Code/Bytecode / | \ / | \ 5.2 5.3 6.0 ... compiler
So a system could contain a compiler for each major
PHP version. Sourcecode written for PHP 5.2 will
use PHP compiler 5.2, sourcecode for PHP 6.0 will use
PHP compiler 6.0, ... No backwards problem for existing
code.
It's still necessary to update 5.2 code to use it
with the PHP 6.0 compiler but the existing code
does not prevent to use PHP 6.0 now for new scripts and
classes. And this is IMO easier then using (fast) CGI or
multiple instances of a webserver to have different
versions of PHP on one server.
There could also be different major versions of
the library.
tschuess
[|8:) http://www.sven-drieling.de/
Michael Shadle wrote:
Confusing new code is totally different from breaking existing code.
True but aren't some changes in 6.0 at least (and possibly 5.3) going
to require code changes? Or is it still going to be "legacy enough" ?
There's a big difference between changing some rare features (and no,
5.3 needs - almost no to - no changes with the code bases I know) and
removing something everybody uses.
Apart from the fact that _REQUEST is not evil per se, the new setting
request_order turns it into something sane again...
So please let's end (at least the public) discussion here ;-)
- Chris
On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
cschneid@cschneid.com wrote:
There's a big difference between changing some rare features (and no,
5.3 needs - almost no to - no changes with the code bases I know) and
removing something everybody uses.Apart from the fact that _REQUEST is not evil per se, the new setting
request_order turns it into something sane again...So please let's end (at least the public) discussion here ;-)
Not everybody uses it.
a) Once again I'll use python as an example, you -can- break backwards
compatibility to finally break free of certain stigmas
b) Would it be possible to tweak request_order so if it is blank, it
does not even create $_REQUEST? That I suppose would be good enough
for me.
Michael Shadle wrote:
On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
cschneid@cschneid.com wrote:There's a big difference between changing some rare features (and no,
5.3 needs - almost no to - no changes with the code bases I know) and
removing something everybody uses.Apart from the fact that _REQUEST is not evil per se, the new setting
request_order turns it into something sane again...So please let's end (at least the public) discussion here ;-)
Not everybody uses it.
a) Once again I'll use python as an example, you -can- break backwards
compatibility to finally break free of certain stigmas
PHP != Python. PHP has lot more users. ;)
b) Would it be possible to tweak request_order so if it is blank, it
does not even create $_REQUEST? That I suppose would be good enough
for me.
Just leave request_order empty in your php.ini and $_REQUEST will be
empty. Now, please stop spamming the list about this issue.
--Jani
Jani Taskinen wrote:
Michael Shadle wrote:
On Mon, May 18, 2009 at 4:38 AM, Christian Schneider
cschneid@cschneid.com wrote:There's a big difference between changing some rare features (and no,
5.3 needs - almost no to - no changes with the code bases I know) and
removing something everybody uses.Apart from the fact that _REQUEST is not evil per se, the new setting
request_order turns it into something sane again...So please let's end (at least the public) discussion here ;-)
Not everybody uses it.
a) Once again I'll use python as an example, you -can- break backwards
compatibility to finally break free of certain stigmasPHP != Python. PHP has lot more users. ;)
b) Would it be possible to tweak request_order so if it is blank, it
does not even create $_REQUEST? That I suppose would be good enough
for me.Just leave request_order empty in your php.ini and $_REQUEST will be
empty. Now, please stop spamming the list about this issue.
I think it defaults back to variables_order if you do that actually, but
you could set it to just "G" and then $_REQUEST will be the same as
$_GET which should also be fine for people who don't like to mix them.
-Rasmus