unset($_SESSION['var']) fails

[ppowell]

unset($_SESSION['mainDisplay']);

In my original environment (PHP 4.3.2) this line will delete the session variable 'mainDisplay'. But in the testing environment (PHP 4.3.6) the variable persists even after unset() is called.

Is there some special setting in PHP that can allow a session to persist even if you attempt to delete it? I am only able to delete the session variable upon closing the browser and rebooting computer.

Thanx
Phil

[devinemke]

...so when you do:

unset($_SESSION['mainDisplay']);
print_r($_SESSION);

...you still see "mainDisplay" as part of the session array? impossible.

[ppowell]

Sure do, every time. I did print_r($SESSION) even after a redirect which occurs after unset($SESSION['mainDisplay']) and it's still there!

Phil

[devinemke]

let's back up a sec. open a completely blank test.php file and do this:

<?
session_start();
$_SESSION['mainDisplay'] = 'this is a test';
unset($_SESSION['mainDisplay']); 
print_r($_SESSION);
?>

what do you see?

[ppowell]

I see $_SESSION['mainDisplay'] all of its contents intact.

Phil

[ppowell]

Wait. Someone might need to explain this to me:

Can you unset a $_SESSION variable inside a function or a method depending on register_globals being on or off?

Phil

[devinemke]

you can add/unet indexes from the $SESSION array inside functions and those changes will carry over outside of the function. those changes do not, however, affect any global variables you may have made from the $SESSION array (like when register_globals is ON).

[ppowell]

Oh CRAP that's right, I forgot about that!

global($_SESSION);

I would have to do that if register_globals is on

Phil

[devinemke]

you do not need to call global $SESSION; inside fo your functions. this is precisely why $GET, $POST, $SESSION, etc. are called superglobals (or autoglobals), that is, they are global everywhere without having to explicitly make them so.

as far as register_globals, it is a bad idea all around but particularly bad when dealing with sessions. changes to the global variables affect the $_SESSION index. in fact there is a well documented bug dealing with this in PHP 4.2 (look in you php.ini file under session.bug_compat_42 and session.bug_compat_warn).

[ppowell]

Ok, then what on earth do I do?

I have to unset $_SESSION['mainDisplay'] and the change must take even after the method is exited; this only works if register_globals is off

However, on one of the servers, register_globals must remain on (requirement for the server due to legacy programs) and this will break my application's functionality once I put that there!

Phil

[devinemke]

you can always run a local php.ini file in your script directory with register_globals OFF.

[ppowell]

you mean doing ini_set()?

Phil

[ppowell]

if ((int)ini_get('register_globals') === 1) ini_set('register_globals', 0);
unset ($_SESSION['mainDisplay']);
global $_SESSION;

And guess what?

print_r($_SESSION['mainDisplay']);

after redirection of page STILL produces that session variable, no matter what!

In PHP 4.3.2 with register_globals off you can alter the autoglobal value and it'll take; in PHP 4.3.6 with register_globals on, apparently, you can't, which means my application will never work in any version of PHP after version 4.3.2 with register_globals on, which is a big problem because that's the required environment for my application to be run in!

Phil

Phil

[ppowell]

Ok perhaps final update.. in index.php, the very first script ever called in my application, I did this, and I'd please like an explanation from a guru out there (DevinEmke especially) why this works:

if ((int)ini_get('register_globals') === 1) ini_set('register_globals', false);
session_cache_limiter();
session_start();

Huh? How did I get away with this knowing that session_start() must be called first?

Phil

[keith73]

first thing you need to do is stop using global $_SESSION because its just wrong.

second thing is look in the user comments section of the manual. I found this in there, it may help you.

andre at twg dot com dot au
06-Mar-2004 07:16
Only This works with register_globals being 'ON'.

unset( $_SESSION['variable'] );

The above will not work with register_globals turned on (will only work outside of a function).

$variable = $SESSION['variable'];
unset( $SESSION['variable'], $variable );

The above will work with register_globals on & inside a function

http://us4.php.net/manual/en/function.unset.php

• keith

[keith73]

Originally posted by ppowell
Ok perhaps final update.. in index.php, the very first script ever called in my application, I did this, and I'd please like an explanation from a guru out there (DevinEmke especially) why this works:

if ((int)ini_get('register_globals') === 1) ini_set('register_globals', false);
session_cache_limiter();
session_start();

Huh? How did I get away with this knowing that session_start() must be called first?

Phil [/B]

session_start only needs to be called before any output to the browser, but session_cache_limiter is REQUIRED to be called before session_start as are any other session functions that determine how the session works.
i.e. session_name('foo') or session_set_cookie_params(), etc.

again, consult the bible, book of sessions.

The cache limiter is reset to the default value stored in session.cache_limiter at request startup time. Thus, you need to call session_cache_limiter() for every request (and before session_start() is called).

• keith

[ppowell]

Sorry but I meant the ini_set() line before any of the session functions.. why am I able to do THIS particular call first before session_start()?

Thanx

Phil

[devinemke]

you cannot use ini_set() to turn of register_globals. from the manual:

Please note that register_globals cannot be set at runtime (ini_set()). Although, you can use .htaccess if your host allows it as described above. An example .htaccess entry: php_flag register_globals on.

to turn off register_globals in an environment where it is on you can do a few things. if you are using Apache and you are running PHP and an Apache module then you might be able to do the htaccess trick described above (depending on the Apache configuration). the other way is to copy the system-wide php.ini to your local public directory and change the register_globals setting there. PHP (usually) will first look in the same directory as the script being called for a php.ini, if there is none it will use the system wide one (defined at compile time: /usr/local/bin/php.ini or C:\Windows\php.ini). either way you have some options here to turn off register_globals.

I persoanlly am the webmaster of several sites that are hosted on register_globals ON environments. In each case the host is running UNIX/Apache/PHP as CGI. what i do is run a nightly cron job that copies the server's php.ini, make certain changes (including register_globals = OFF) and then writes it back to a file in my document root. i then use symlinks to recursively have each subdirectory point to my master php.ini.

[ppowell]

That would, of course, pre-suppose I will have that kind of access on every machine this application will be put on, and this has to be a totally portable and usable PHP web application (with some XML, Bash and TCL thrown in for flavor). That means it will be on a server that may be Linux or Windows, Apache or IIS, MySQL or whatever else, and register_globals on or off and whatever PHP version exists (minimum requirement is 4.1.2).

If you can't turn off register_globals at runtime, how on earth am I able to turn off register_globals at runtime, and, furthermore, successfully unset the session variable by attempting to do so whereas I could not before?

Phil

[ppowell]

Sorry but the manual has to be wrong on this one.

print_r(ini_get('register_globals'))); echo '<P>';
if ((int)ini_get('register_globals') === 1) ini_set('register_globals', false);
session_cache_limiter();
session_start();
print_r(ini_get('register_globals'))); echo '<P>';

in PHP 4.3.6 with register_globals ON produces:

1

I am fully capable of turning off register_globals at runtime in PHP 4.3.6. Furthermore, in my original environment of 4.3.2 I am also capable fully of turning off register_globals at runtime.

What can I say?

Phil