php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #5231 session_destroy() doesn't.
Submitted: 2000-06-26 03:05 UTC Modified: 2000-11-07 23:52 UTC
From: chris-php-bugs at digitaria dot com Assigned:
Status: Closed Package: Session related
PHP Version: 4.0.0 Release OS: NT 4.0 SP6a
Private report: No CVE-ID: None
 [2000-06-26 03:05 UTC] chris-php-bugs at digitaria dot com
session_start();
echo '<P> Session ID: ' . session_id() . '</P>';
echo '<P>destroy ' . (session_destroy() ? ' successful' : 'failed') . '</P>';

will always print failed. The temp file will not be removed, the browser will keep the same session cookie and the session variables will still be available. As far as I can tell, session_destroy() is a NOP.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-06-26 03:37 UTC] chris-php-bugs at digitaria dot com
There was an omission in the original report. The problem with session_destroy() was exposed because I had included some code in my session logic that correctly set the session cookie with the path session_start() should set but does not (see bug #4920).

My logout function is now:

session_destroy();

// Manually expire things since session_destroy doesn't.
$CookieParms = session_get_cookie_params();
setcookie(session_name(), '', time(), $CookieParms["path"], $CookieParms["domain"]);
setcookie(session_name(), '', time(), '/members/', $CookieParms["domain"]);

This works in that the browser will stop using that session ID and will thus be assigned a new one by the next session start.

However, the big problem here is that session_destroy() doesn't actually destroy anything, contrary to the documentation. If the browser continues to ask for a given session identifier, all of that data will still be available. I can't even delete the temp file as unlink() is broken on Win32!


 [2000-06-26 03:38 UTC] chris-php-bugs at digitaria dot com
There was an omission in the original report. The problem with session_destroy() was exposed because I had included some code in my session logic that correctly set the session cookie with the path session_start() should set but does not (see bug #4920).

My logout function is now:

session_destroy();

// Manually expire things since session_destroy doesn't.
$CookieParms = session_get_cookie_params();
setcookie(session_name(), '', time(), $CookieParms["path"], $CookieParms["domain"]);
setcookie(session_name(), '', time(), '/members/', $CookieParms["domain"]);

This works in that the browser will stop using that session ID and will thus be assigned a new one by the next session start.

However, the big problem here is that session_destroy() doesn't actually destroy anything, contrary to the documentation. If the browser continues to ask for a given session identifier, all of that data will still be available. I can't even delete the temp file as unlink() is broken on Win32!

 [2000-06-28 05:31 UTC] stas at cvs dot php dot net
session_destroy destroys session data, not session itself.
That's what manual says.
Also, session_destoy is void, so how would you expect it to return anything?
 [2000-07-04 05:54 UTC] chris-php-bugs at digitaria dot com
<BLOCKQUOTE>session_destroy destroys session data, not session itself.
That's what manual says.</BLOCKQUOTE>

When you use the built in files handler, the data is not destroyed. Future requests with the same session ID (e.g. for some reason the cookie isn't deleted or you have the session ID embedded in a URL) will still have all of the old session data. There's no way this counts as deleting the data.

 [2000-07-04 09:52 UTC] stas at cvs dot php dot net
OK, then we need reproducing script and your session variables settings in php.ini
I just tried it and for me it works.
 [2000-07-04 18:42 UTC] chris-php-bugs at digitaria dot com
PHP.ini:
session.save_handler = files
session.save_path = D:\TEMP\PHPSessions

<?
	session_start();
	session_register('counter');

	echo "<P>Reload count: " . @$counter++ . "</P>";

	if ($counter < 10) {
		echo '<A HREF="bug_5231.php?PHPSESSID=' . session_id() . '">Reload</A>';
	} else {
		echo "Hit reload limit. Destroying session";
		session_destroy();
	}
?>

Observed behaviour is that the session count will be reach nine and stay there. session_destroy() will be called each time at that point, which appears to prevent counter's change to 10 from being written. However, the session still remains valid and so "Reload count: 9" will be displayed for all subsequent reloads. A working session handler will restart at zero after the session is destroyed.

 [2000-07-04 19:02 UTC] stas at cvs dot php dot net
Well, it works for me again. Please try 4.0.1pl2 - maybe it will work for you too.
 [2000-08-03 11:09 UTC] hholzgra@php.net
definetly works for unix, maybe it's a windows problem?


by the way, since July 4th session_destroy() 
will return success status as true or false
 [2000-08-20 02:36 UTC] sniper@php.net
No feedback from user.

--Jani
 [2000-08-20 16:38 UTC] chris-php-bugs at digitaria dot com
Re-opened because it was closed in error. The problem still happens, there's a script which reproduces the problem on the listed platform and it's still a bug in all released versions of PHP4 including 4.0.1pl2, as was mentioned in response to both previous questions.
 [2000-08-21 14:04 UTC] sniper@php.net
Have you tried latest CVS or snapshot from snaps.php.net?

--Jani
 [2000-09-18 06:06 UTC] sniper@php.net
Again, NO feedback for a while..please try php4.0.2 and if that 
doesn't work, the latest CVS or snapshot. Reopen if problem still exists.

--Jani
 [2000-10-03 02:55 UTC] waldschrott@php.net
reopened due to new bug reports and I verifed that this does not work on *win32*, this message appears:

Warning: Session object destruction failed in ...
 [2000-10-03 03:10 UTC] waldschrott@php.net
duped out about 7 similar bugs, this *is* a win32 issue and should be fixed before 4.0.3
 [2000-11-07 23:52 UTC] dbeu@php.net
fixed in cvs already, wait for 4.0.4
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jul 21 10:01:30 2024 UTC