# register_globals work arounds - Thread: https://externals.io/message/61961 - Original archive: https://news-web.php.net/php.internals/61961 - Started by Lester Caine on 2012-08-02T11:51:16+00:00 - Messages: 8 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #61961 — Lester Caine — 2012-08-02T11:51:16+00:00 URL: https://externals.io/message/61961#61961 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 --- ## #61962 — rich gray — 2012-08-02T12:34:00+00:00 URL: https://externals.io/message/61961#61962 · In reply to: #61961 > 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 --- ## #61963 — Lester Caine — 2012-08-02T12:49:32+00:00 URL: https://externals.io/message/61961#61963 · In reply to: #61962 rich gray wrote: > > […] > 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 --- ## #61964 — Anthony Ferrara — 2012-08-02T13:02:28+00:00 URL: https://externals.io/message/61961#61964 · In reply to: #61963 Lester, > rich gray 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. 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 --- ## #61965 — Ferenc Kovacs — 2012-08-02T13:56:52+00:00 URL: https://externals.io/message/61961#61965 · In reply to: #61962 > > > > > […] > tried `extract()` ? > http://fr2.php.net/extract > > Rich > 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: > > On Thu, Aug 2, 2012 at 2:34 PM, rich gray > wrote: > > > > > OK > > > IMO - this should be posted on PHP general not internals -- have > you tried `extract()` ? > http://fr2.php.net/extract > > Rich > > > 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: > 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... --- ## #61967 — Lester Caine — 2012-08-02T16:07:40+00:00 URL: https://externals.io/message/61961#61967 · In reply to: #61964 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 --- ## #61969 — Gustavo Lopes — 2012-08-02T16:21:25+00:00 URL: https://externals.io/message/61961#61969 · In reply to: #61967 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