php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18071 unset($_SESSION['name']); not works when varible is readed before unset
Submitted: 2002-06-30 07:35 UTC Modified: 2002-09-11 11:31 UTC
Votes:7
Avg. Score:4.7 ± 0.7
Reproduced:7 of 7 (100.0%)
Same Version:4 (57.1%)
Same OS:2 (28.6%)
From: lampa at brutusmud dot net Assigned:
Status: Closed Package: Session related
PHP Version: 4.2.1 OS: win 2k, debian 2.2
Private report: No CVE-ID:
 [2002-06-30 07:35 UTC] lampa at brutusmud dot 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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-06-30 08:46 UTC] sander@php.net
Reproduced with 4.3.0-dev. Something really weird is going on (some reference-stuff?). Making this critical.
 [2002-07-13 05:10 UTC] manzella at lucent dot 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-07-30 13:21 UTC] hgardner at cooksonelectronics dot com
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).
 [2002-08-07 10:29 UTC] andre at switch dot no
I have the same problem, running 4.1.1 on FreeBSD, put this script somewhere at your site and run it:

session_start();
echo '<h2>Session just after session_start()</h2>';
echo '<pre>';
print_r($_SESSION);
echo '</pre>';
if(isset($_GET['set'])) {
    $_SESSION['foo'] = 'bar';
    echo '<h2>Session after $_SESSION[\'foo\'] = \'bar\'</h2>';
    echo '<pre>';
    print_r($_SESSION);
    echo '</pre>';
}
if(isset($_GET['unset'])) {
    unset($_SESSION['foo']);
    echo '<h2>Session after unset($_SESSION[\'foo\'])</h2>';
    echo '<pre>';
    print_r($_SESSION);
    echo '</pre>';
}


if($_GET['step'] == 0) {
    echo '<a href="unset.php?step=1&set=1">Next</a>';
}
if($_GET['step'] == 1) {
    echo '<a href="unset.php?step=2">Next</a>';
}
if($_GET['step'] == 2) {
    echo '<a href="unset.php?step=3&unset=1">Next</a>';
}
if($_GET['step'] == 3) {
    echo '<a href="unset.php?step=4">Next</a>';
}
if($_GET['step'] == 4) {
    echo '<p>$_SESSION should be an empty array at this point!</p>';
}
 [2002-08-07 15:45 UTC] kalowsky@php.net
Your (andre@switch.no) sample script does not work for me.  Results look like:
 session just after session_start()

Array
(
)

Next

and the Next link unset.php doesn't exist.  Can you finish your test case please?
 [2002-08-08 05:18 UTC] andre at switch dot no
unset.php should be the name you save the testscript as...
 [2002-08-08 08:33 UTC] andre at switch dot no
Final note; we're currently running with register_globals on, while we migrate old code. It seems that this is the reason unset($_SESSION['varname']) won't work. But, the inconsistent behavior (you can assign to $_SESSION but not unset variables from it), is simply intolerable.

Either both:
$_SESSION['varname'] = 'value';
unset($_SESSION['varname']);

work as intended, even with register globals on, or none of them should work. I would prefer them both to work because this will make it much easier to migrate old code while still running with register globals on.
 [2002-08-15 18:17 UTC] kalowsky@php.net
Please try a recent snapshot, of the non-stable kind.  I believe Zeev just fixed this (at least your test case works for me).  
 [2002-09-11 11:31 UTC] sniper@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2014 The PHP Group
All rights reserved.
Last updated: Sat Apr 19 22:02:16 2014 UTC