Erwin Moller wrote:
thecrow wrote:
Alright, what the hell is going on here?
In the following code, I expect the printed result to be:
DEBUG: frank's last name is burns.
Instead, what I get is:
DEBUG: frank's last name is burns.
That is than excactly what you wanted. :P
Here is the code:
$frank = "burns";
$_SESSION['frank'] = "black";
echo "DEBUG: frank's last name is is $frank";
So what is your problem?
$frank contains "burns", so what else should PHP print?
If you want the content for the session-var 'frank', use it.
Like:
echo "DEBUG: frank's last name is is ".$_SESSION['frank'];
What is coming into play here? I thought of register_globals but I
thought that only dealt with GET, POST, REQUEST, etc.
Indeed.
Go get a cup of coffee.
You are just being sloppy. :-)
Regards,
Erwin Moller
I think thecrow meant to say:
In the following code, I expect the printed result to be:
DEBUG: frank's last name is burns.
Instead, what I get is:
DEBUG: frank's last name is black.
Here is the code:
session_start();
$frank = "burns";
$_SESSION['frank'] = "black";
echo "DEBUG: frank's last name is is $frank";
I tried this test with register_globals turned on and turned off. With
it on, I got what thecrow got. With it off, I got what thecrow had
hoped for. So yes, register_globals is the culprit.
It makes sense for $_SESSION to trump other variables when
register_globals is turned on. Imagine if a malicious user passed
"user_level=admin" on the query string. And in that PHP page, you
populated $_SESSION['user_level'] with the result of a database query.
What would you like to see when accessing $user_level? The data you
explicitly put into $_SESSION or the data the malicious user passed to
your script?
It is because of the confusing and possibly dangerous side-effects of
register_globals that it was disabled by default as of PHP 4.2.0