#18071 [Com]: unset($_SESSION['name']); not works when varible is readed before unset

ID: 18071 Comment by: hgardner@cooksonelectronics.com Reported By: lampa@brutusmud.net Status: Critical Bug Type: Session related Operating System: win 2k, debian 2.2 PHP Version: 4.2.1 New Comment: On WinNT 4.0 running Apache 2.0.39/PHP 4.2.2 I have seen the same thing. unset($_SESSION['xyz']) does NOT remove the variable xyz from the session file. It only kills the instance on the page being processed. This is an extremely critical problem if other scripts pass what should be "one-shot" values. The receiving page immediately does an unset thinking that the variable no longer exists ANYWHERE, but if the user does a refresh... poof... the value reappears. Example snippet: Script #1 $_SESSION['manage'] = 'Create'; echo "<input type=button name='continue' value='Create another?' onClick=\"window.location='pcomanage.php'\">\n"; Script 1 is passing 'manage=Create' to pcomanage.php versus POSTing it, as we may not want the user to be clued to anything by viewing source in the browser. Script 2 if (isset($_SESSION['manage'])) { $manage = $_SESSION['manage']; unset($_SESSION['manage']); } Okay, based on my workflow if the session variable 'manage' is set then I know I'm coming from a script (vs. a POST), so I make a local copy and try to kill the session variable created in Script 1. No joy! I have checked the pertinent session file following the processing of the script and 'manage' still appears with it's value (Create). Previous Comments: ------------------------------------------------------------------------ [2002-07-13 05:10:15] manzella@lucent.com this issue is especially nasty when there's an "initiator" script that does validation of user before it is taken to the "main" script. if the latter relies on recursion and checking for instance that a $_SESSION['comingfromscript'] is not set (against cut&paste of the URI) before proceeding, the test will unexpectedly succeed if in a previous recursion step the $_SESSION['comingfromscript'] has been assigned to a normal variable even if afterward the $_SESSION['cominfromscript'] is unset. ------------------------------------------------------------------------ [2002-06-30 08:46:22] sander@php.net Reproduced with 4.3.0-dev. Something really weird is going on (some reference-stuff?). Making this critical. ------------------------------------------------------------------------ [2002-06-30 07:35:21] lampa@brutusmud.net when using unset($_SESSION[...]) insted session_unregister(...) and before calling read _$SESSION[...] variable WILL NOT unset. please try these examples and see result. here is method how to produce this bug (you must have cookies enabled): 1. run script 2. reload page (you should see 2 $_SESSION arrays with the same value) 3. click on unset link 4. now you should see first array filled with test value and second should be empty - that's OK - but variable test should be deleted from session 5. reload page 6. here is BUG: i unset session variable test so i shouldn't exists, but exists. --- 7. comment line marked #fatal and go to repeat process from begining on step 6. both arrays will be empty!!!! <?php session_start(); echo '<pre>'; print_r($_SESSION); if (isset($_GET['submit'])) { $test = $_SESSION['test']; # fatal unset($_SESSION['test']); } else { $_SESSION['test'] = 'this is test'; } echo '<a href="'.$_SERVER['PHP_SELF'].'?submit=yes">unset</a><br>'; print_r($_SESSION); echo '</pre>'; ?> replace unset($_SESSION['test']); with session_unregister('test'); and repeat process - here will be everything OK. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=18071&edit=1