OK
No discussions on why register_globals has been removed we all understand why
and now have to live with that ... I'm not winging here!
The question is "Does anybody have an 'elegant' fix to quickly update a legacy
site that relies on globals to pass variables between page views?"
My original quick thought was simply to remap these variables as
$_SESSION['var'] so as not to get too deeply into the code base. I've used that
in a few quick fixes, but I'm not sure that it is acceptable? I have been
passing the variables via $_REQUEST but that obviously needs a lot more work in
the html generated, so the session approach would seem better? But needs to
observe the European rules on use of cookies :(
I'm thinking that what is needed is a sort of PEAR package that would simply be
added to every page and be provided with a list of variables to manage, so all
we need to do is scan the site for variables and establish which need to be
remembered. I've got all sorts of stuff from google/bing searches, but I'm
obviously not yet asking the right question ;) Has anybody already been down
that track?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
OK
No discussions on why register_globals has been removed we all
understand why and now have to live with that ... I'm not winging here!The question is "Does anybody have an 'elegant' fix to quickly update
a legacy site that relies on globals to pass variables between page
views?"
My original quick thought was simply to remap these variables as
$_SESSION['var'] so as not to get too deeply into the code base. I've
used that in a few quick fixes, but I'm not sure that it is
acceptable? I have been passing the variables via $_REQUEST but that
obviously needs a lot more work in the html generated, so the session
approach would seem better? But needs to observe the European rules on
use of cookies :(I'm thinking that what is needed is a sort of PEAR package that would
simply be added to every page and be provided with a list of variables
to manage, so all we need to do is scan the site for variables and
establish which need to be remembered. I've got all sorts of stuff
from google/bing searches, but I'm obviously not yet asking the right
question ;) Has anybody already been down that track?
IMO - this should be posted on PHP general not internals -- have you
tried extract() ?
http://fr2.php.net/extract
Rich
rich gray wrote:
OK
No discussions on why register_globals has been removed we all understand why
and now have to live with that ... I'm not winging here!The question is "Does anybody have an 'elegant' fix to quickly update a legacy
site that relies on globals to pass variables between page views?"
My original quick thought was simply to remap these variables as
$_SESSION['var'] so as not to get too deeply into the code base. I've used
that in a few quick fixes, but I'm not sure that it is acceptable? I have been
passing the variables via $_REQUEST but that obviously needs a lot more work
in the html generated, so the session approach would seem better? But needs to
observe the European rules on use of cookies :(I'm thinking that what is needed is a sort of PEAR package that would simply
be added to every page and be provided with a list of variables to manage, so
all we need to do is scan the site for variables and establish which need to
be remembered. I've got all sorts of stuff from google/bing searches, but I'm
obviously not yet asking the right question ;) Has anybody already been down
that track?IMO - this should be posted on PHP general not internals -- have you tried
extract()?
http://fr2.php.net/extract
I'm specifically asking in relation to helping users migrate from PHP5.2 ...
trying to expand the documentation of making that process easier. Pointing at a
single manual page is a good example of why we need a more consistent support
for all those users who are not as computer literate as we would like. That
function may be a useful element of solving the problem, but it does not answer
the specific question asked?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Lester,
rich gray wrote:
OK
No discussions on why register_globals has been removed we all
understand why
and now have to live with that ... I'm not winging here!The question is "Does anybody have an 'elegant' fix to quickly update a
legacy
site that relies on globals to pass variables between page views?"
My original quick thought was simply to remap these variables as
$_SESSION['var'] so as not to get too deeply into the code base. I've
used
that in a few quick fixes, but I'm not sure that it is acceptable? I
have been
passing the variables via $_REQUEST but that obviously needs a lot more
work
in the html generated, so the session approach would seem better? But
needs to
observe the European rules on use of cookies :(I'm thinking that what is needed is a sort of PEAR package that would
simply
be added to every page and be provided with a list of variables to
manage, so
all we need to do is scan the site for variables and establish which
need to
be remembered. I've got all sorts of stuff from google/bing searches,
but I'm
obviously not yet asking the right question ;) Has anybody already been
down
that track?IMO - this should be posted on PHP general not internals -- have you
tried
extract()?
http://fr2.php.net/extractI'm specifically asking in relation to helping users migrate from PHP5.2
... trying to expand the documentation of making that process easier.
Pointing at a single manual page is a good example of why we need a more
consistent support for all those users who are not as computer literate as
we would like. That function may be a useful element of solving the
problem, but it does not answer the specific question asked?
Register_Globals has been seen (and touted) as bad practice since the 4.2.
It was disabled by default as of Feb-5-2002, and in 4.2.0. This is a
problem that the vast majority of users solved years ago. If you were still
using them in 5.2 a decade later, you've got other problems.
The documentation exists. The blog posts exist. But they are old, because
this is an old problem. I don't think internals should worry themselves
with it. Especially since 5.2 has been EOL for a while now. If you brought
this up when 5.3 was being planned, perhaps. But at this point, it's either
a general list issue, or MAYBE a docs list issue, but not an internals list
issue...
But I don't think it's an issue at all. Just my $0.02...
Anthony
Anthony Ferrara wrote:
I'm specifically asking in relation to helping users migrate from PHP5.2 ... trying to expand the documentation of making that process easier. Pointing at a single manual page is a good example of why we need a more consistent support for all those users who are not as computer literate as we would like. That function may be a useful element of solving the problem, but it does not answer the specific question asked?Register_Globals has been seen (and touted) as bad practice since the 4.2. It
was disabled by default as of Feb-5-2002, and in 4.2.0. This is a problem that
the vast majority of users solved years ago. If you were still using them in 5.2
a decade later, you've got other problems.
There is still a lot of code which was crudely ported from PHP4 to PHP5 when
PHP4 was end of lifed in 2008. This code still runs fine on 5.2 even if is
archaic and a lot of legacy sites still rely on it. I am still using 199x code
as it's still doing it's job, and since it's on private networks, the hacking
risks don't really apply, but I'm asking simply to get some help to document
processes to allow other users to upgrade.
The documentation exists. The blog posts exist. But they are old, because this
is an old problem. I don't think internals should worry themselves with it.
Especially since 5.2 has been EOL for a while now. If you brought this up when
5.3 was being planned, perhaps. But at this point, it's either a general list
issue, or MAYBE a docs list issue, but not an internals list issue...
Perhaps because it IS such an old issue, that is why it's not coming up in
searches? All I get is how to switch register_globals back on again. Nothing on
ways to rewrite the code so that it will work with PHP5.4 at all ( and the
problems getting some of these changes working with .htaccess hacks Rasmus )
which is probably because it's not actually a 5.2 to 5.3/4 migration problem? To
be honest I can't even see it mentioned in the PHP4 to 5 guide.
IF PHP5.2 is to be put to bed, it needs a concerted effort to get rid of the
reasons that ISP's are not upgrading, and this is one since they know when they
do switch many of their 'naive' customer's sites will simply stop working? 'Not
our problem' is all very well, but if a section of the 60% of users still
running on PHP5.2 are simply knocked off the internet, then it's not very good
press? This may be a non-issue, but it would at least be useful to confirm that
is the case, and that ISP don't need to worry about it?
In the meantime some links to this old material would be helpful, if only to get
access to them on the migration guides. Because I'm actively looking, hopefully
the problem will not arise, but you can guarantee something will pop up that has
been overlooked? There are a lot of subtle little changes which don't on their
own give trouble, but a logjam has been created simply because older code does
still work as long as certain conditions are met, and ensuring that a controlled
release is achieved needs help from people who actually have the answers.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Em 2012-08-02 18:07, Lester Caine escreveu:
[...]
In the meantime some links to this old material would be helpful, if
only to get access to them on the migration guides. Because I'm
actively looking, hopefully the problem will not arise, but you can
guarantee something will pop up that has been overlooked? There are a
lot of subtle little changes which don't on their own give trouble,
but a logjam has been created simply because older code does still
work as long as certain conditions are met, and ensuring that a
controlled release is achieved needs help from people who actually
have the answers.
Could you please move this discussion somewhere else (maybe the docs
mailing list if you want to help better the documentation or the users
if you just want help)?
Unless you are proposing to reintroduce register_globals in the next
PHP version or asking for some help doing that yourself, this is clearly
off-topic.
--
Gustavo Lopes
OK
No discussions on why register_globals has been removed we all understand
why and now have to live with that ... I'm not winging here!The question is "Does anybody have an 'elegant' fix to quickly update a
legacy site that relies on globals to pass variables between page views?"
My original quick thought was simply to remap these variables as
$_SESSION['var'] so as not to get too deeply into the code base. I've used
that in a few quick fixes, but I'm not sure that it is acceptable? I have
been passing the variables via $_REQUEST but that obviously needs a lot
more work in the html generated, so the session approach would seem better?
But needs to observe the European rules on use of cookies :(I'm thinking that what is needed is a sort of PEAR package that would
simply be added to every page and be provided with a list of variables to
manage, so all we need to do is scan the site for variables and establish
which need to be remembered. I've got all sorts of stuff from google/bing
searches, but I'm obviously not yet asking the right question ;) Has
anybody already been down that track?IMO - this should be posted on PHP general not internals -- have you
triedextract()?
http://fr2.php.net/extractRich
unconditionally extracting variables from user-controller arrays into the
current/global scope was really a bad decision, if you don't know why, pls.
check the documentation ( http://php.net/manual/en/security.globals.php )
one could use extract() to simulate the behavior of register_globals, but
with that you would be vulnerable to the same attack vectors, so we
shouldn't support that imo.
for a long term fix, one has to read through all of the codebase, discover
the implicit references of the global variables (this is one of the many
problems with register_globals) and replace them with explicit references.
so in this example:
<?php
include './bootstrap.php';
if($admin){
}
else{
}
one has to discover where does the $admin variable come from, and replace
it with $_SESSION['admin'] for example
it is a painful process and can't really be automated. :(
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Thu, Aug 2, 2012 at 2:34 PM, rich gray <rich@richgray.com
mailto:rich@richgray.com> wrote:OK IMO - this should be posted on PHP general not internals -- have you tried `extract()` ? http://fr2.php.net/extract Richunconditionally extracting variables from user-controller arrays into
the current/global scope was really a bad decision, if you don't know
why, pls. check the documentation (
http://php.net/manual/en/security.globals.php )
one could useextract()to simulate the behavior of register_globals,
but with that you would be vulnerable to the same attack vectors, so
we shouldn't support that imo.
for a long term fix, one has to read through all of the codebase,
discover the implicit references of the global variables (this is one
of the many problems with register_globals) and replace them with
explicit references.
so in this example:
<?php
include './bootstrap.php';
if($admin){}
else{}
one has to discover where does the $admin variable come from, and
replace it with $_SESSION['admin'] for example
it is a painful process and can't really be automated. :(
I agree using extract() is bad as was register_globals but (as I read
his original post) he wanted a solution to simulate register_globals = 1
and I gave it to him - still not sure why this is being discussed on
internals but hey...