Naming a global variable the same as a SESSION, GET or POST variable

[torvista]

Hi,
to cut a load of headache short, I believe it is not allowed to use a global variable name that is the same as a SESSION, GET or POST variable.
This is what I find experimentally and also (much later...) in the code...as far as I can see without really understanding it 100%:

init_sanitize.php

unset($GLOBALS[$key])

Can someone confirm this is so and also why that is, for the non-experts.

This has cropped up due to me using a code snippet from "elsewhere" that I would consider an expert source, hence my interest in knowing the reasons behind this.

Or, do I just have to put this new variable name somewhere in ZC (extra_somethings.php) to allow it?

thanks
Steve

[mc12345678]

Hi,
to cut a load of headache short, I believe it is not allowed to use a global variable name that is the same as a SESSION, GET or POST variable.
This is what I find experimentally and also (much later...) in the code...as far as I can see without really understanding it 100%:

init_sanitize.php


Can someone confirm this is so and also why that is, for the non-experts.

This has cropped up due to me using a code snippet from "elsewhere" that I would consider an expert source, hence my interest in knowing the reasons behind this.

Or, do I just have to put this new variable name somewhere in ZC (extra_somethings.php) to allow it?

thanks
Steve

Here is what I surmise is the situation and potential reasoning... BTW, it extends a little beyond just SESSION, GET, and POST, but also COOKIE.

The function is about sanitization, keeping things clean... In the process of transferring data around the cart operations, it is ideal to
1) minimize the amount of transferred data while also ensuring information is always up-to-date... If a variable is passed/stored using one of the above methods, then the intention is to work with it and then to potentially update anything that needs it. If a variable is passed/stored with/by any of the above four methods, then by keeping the global value set as it was, there would be two values for that variable (potentially the same or different) and at the new location that value could be incorrectly accessed.
2) maintain independent variables throughout the system. This is where the use of multiple plugins can cause a clash if they each use the same variable name when passing from one location to the next, as such could cause a loss of the expected global variable setting moving through the system/code.

Dunno, kinda' going off the cuff with my available time, but yes it looks init_sanitize does remove the GLOBAL version of a variable that is used in a SESSION, GET, POST or COOKIE when moving from page to page.## Ideally, if that value is passed to the next page, then it is used/set in the receiving page to be the value needed, but this also could result in unsetting global variables by passing the equivalent variable as part of the above.## I've been trying to find where there might be an automatic "reassignment" of such variables, but haven't had much luck, like if a value was passed in a GET (anyone can append the key to the uri), what is the effect of not receiving/having the GLOBAL value set when the page is processed? Seems like it could wreak havoc, but something about it also seems like it may be addressed and part of why so much has gone into the security of the software...

Dunno if much help, but yes confirm that init_sanitize.php will unset the global version of the variable that is passed by any of the above four methods... If it is desired/necessary to not affect the GLOBAL version of the variable, then one would need to bypass the unset for each of the desired cases with something like:

if ($key != 'LeaveMeAlone') {
 unset($GLOBALS [$key]);
}

Where LeaveMeAlone is the key value to bypass... If this is to be one of many such as an array, then different functionality could be applied. It may be possible to apply such a bypass and check against a different variable that might be set in say an autoloaded function, depending on the load sequence, which I haven't looked into yet as an option. I am thinking though that this is all done for security's sake and to minimize other issues that could crop up by having both a GLOBAL and "local" variable each with the same name set at the same time...

[torvista]

Seems like it could wreak havoc

Yup. Easy self-destruct in one step.

Maybe related to stopping people writing code based on register_globals being on...?

I've already spent an embarrassing amount of time to find this out so no more suppositions...over to the experts!!

[wilt]

Hi

As suggested by other posters here, the code in init_sanitize that will unset certain $GLOBAL values was done for security reasons, and was meant to 'imitate' setting register_globals=off.

However register_globals was deprecated in php 5.3 and removed in php 5.4, so the benefit of the code in init_sanitize is moot.

If you are using php 5.4 and therefore sure that register_globals is no longer used, then you can safely remove the code.
In the short term and to make upgrading easier, you could use the overrides directory under the init_includes directory.

We will address this in v155.

[torvista]

you can safely remove the code.

So to be completely clear, all eight instances of

unset($GLOBALS[$key]); 

in

init_santize.php

can be commented out for the moment?

[mc12345678]

Hi

As suggested by other posters here, the code in init_sanitize that will unset certain $GLOBAL values was done for security reasons, and was meant to 'imitate' setting register_globals=off.

However register_globals was deprecated in php 5.3 and removed in php 5.4, so the benefit of the code in init_sanitize is moot.

If you are using php 5.4 and therefore sure that register_globals is no longer used, then you can safely remove the code.
In the short term and to make upgrading easier, you could use the overrides directory under the init_includes directory.

We will address this in v155.

So to be completely clear, all eight instances of

unset($GLOBALS[$key]); 

in

init_santize.php

can be commented out for the moment?

That's a method to accomplish what was said. The initial solution being to copy includes/init_includes/init_sanitize.php to includes/init_includes/overrides and then modify the file in that directory to eliminate the removal of the global variables when the equivalently named other type variable is passed...

It could maybe be misinterpreted to mean completely remove all content of init_sanitize.php, but I wouldn't go so far as that considering we were primarily focused on the unsettng of the global variables. But if the other actions imitate register_globals=off functionality then yeah, that/those sections also.

Just make sure your upgrade process includes review of the overrides folder at some point.