session_destroy

Description

bool session_destroy ( void )

session_destroy() destroys all of the data associated with the current session. It does not unset any of the global variables associated with the session, or unset the session cookie.

In order to kill the session altogether, like to log the user out, the session id must also be unset. If a cookie is used to propagate the session id (default behavior), then the session cookie must be deleted. setcookie() may be used for that.

如果成功则返回 TRUE，失败则返回 FALSE。

例子 1. Destroying a session with $_SESSION
<?php // Initialize the session. // If you are using session_name("something"), don't forget it now! session_start(); // Unset all of the session variables. $_SESSION = array(); // If it's desired to kill the session, also delete the session cookie. // Note: This will destroy the session, and not just the session data! if (isset($_COOKIE[session_name()])) { setcookie(session_name(), '', time()-42000, '/'); } // Finally, destroy the session. session_destroy(); ?>

注: Only use session_unset() for older deprecated code that does not use $_SESSION.

See also unset() and setcookie().

add a note User Contributed Notes

webmaster at unitedscripters dot com
13-Sep-2006 01:11


If you unset a session superglobal by

$_SESSION=array()



Be warned, and this warning can't be stressed enough, that then ALL your checks for the existence of a session are IMPLICITLY supposed to be checking with session_id (rush to the documentation there, in case).



The native value of an uninitialized session is null ($_SESSION is the only superglobal that is NOT by default an empty array): unsetting it to array exposes codes that are checking the existence of a session via things like

if(isset($_SESSION)){}

to potential terrible consequences. The check would in fact appear in itself perfectly valid: a non existant session IS null, and the check would succeed.



Yet, if you have reset by $_SESSION=array() THEN your conditional checks should be if session_id() or you are exposed to things like:



$_SESSION=array();

session_destroy();

//several lines of code

if(isset($_SESSION)){$enter->deletePrivileges();}



If you areusing session=array(), you are supposed to use session_id and do not rely any longer on the session carrying its native value of null.

Of course, alternative:

$_SESSION=null;



It is then presumed that you won't loop it. In all cases, something is presumed, and ought to be said in whichever case.

wrong at andright dot com
12-Sep-2006 09:10


$_SESSION is the only superglobal whose uninitialized value is not that of an empty array but that of NULL. If there is no reason behind it, I don't know, but I assume there is.



Therefore, destroy a $_SESSION by assigning to it NULL.



The rationale behind assinging to it array() is that your codes may have loops in it that scan a destroyed session.



The fact is, your codes should not have such loops in the first place. A code that loops a destroyed session, is a terribly bad code and no solutions that encourage terribly bad coding prcatices should be sponsored.



$_SESSION=null

is the _compliant_ way to go. It will pass all tests, included isset($_SESSION).

webmaster [at] darkstarlings [dot] com
01-Mar-2006 04:46


In response to the difficulties that some are having with fully destroying a session (especially with session files remaining on the server) I find that this usually happens when the user is not sent to a "dead" page after the session is destroyed.



Just like any other cookie, changes to a session cookie won't take place immediately on the page at which the command is issued.  



Try:



session_start();

session_destroy();

print "You have been logged out.";



At this point, the user's session file should have been cleared off of the server.  The only way the session id might then be reused (causing the session file to reappear) is if the user's browser remains open and they initiate a request that calls session_start again.  Since the browser will still have the session id cached, PHP may use the same id again and basically re-create the session file.  This behavior is fine as long as you understand it.



This is the behavior I have observed and tested using PHP 4.4.2 and RHEL 4.



This might sound too simple to be your problem, but give it a try.  If you're having to go through step after step to kill off stubborn sessions, this is probably why.

markus at fischer dot name
16-Mar-2005 05:09


Note that there's a bug with custom session handlers and when you want to start a session again after you have called session_destroy.



session_destroy disables the custom session_handler and this a call to session_start after it will fail with "Failed to initialize storage module".



See http://bugs.php.net/32330 for more information and a workaround.

n beh ih AT gmx dott nett
09-Jan-2005 09:57


[Editor's Note]


doing $_SESSION = array();


is faster/quicker and works aswell.


[/Note]





If you want to keep your session_id() unchanged, but you want to reset all session variables, BEWARE of unset($_SESSION). Doing so, and setting session variables (like $_SESSION['test']) afterwards has the effect, that your changes will not be saved at the end of your script (not even with session_write_close()).





So you better code like this:


foreach ($_SESSION as $VarName => $Value)  {


    unset ($_SESSION[$VarName]);


}


$_SESSION['test'] = 'MyTestValue';

Johan
20-Nov-2004 10:00


Remember that session_destroy() does not unset $_SESSION at the moment it is executed.  $_SESSION is unset when the current script has stopped running.

thomas at uninet dot se
07-Oct-2004 11:25


I did encounter a minor problem when I tried to remove the physical file that stores the session. The problem was that my working directory wasn't on the same drive as my PHP installation (yes, I used Windows).



So I used the PHP_BINDIR to start at the same place as PHP does and then change directory to the place that was specified in PHP.INI. This makes it transparent to relative paths in session.save_path.



<?php

function DeleteSessionID($sessionid) {

  $orgpath = getcwd();

  chdir(PHP_BINDIR);

  chdir(session_save_path());

  $path = realpath(getcwd()).'/';

  if(file_exists($path.'sess_'.$sessionid)) {

    // Delete it here

    unlink($path.'sess_'.$sessionid);

  } else {

    // File not found

  }

  chdir($orgpath);

}



?>



The final chdir($orgpath) is just to restore the working directory as it were before .

nhamill at wam dot umd dot edu
15-Aug-2003 11:36


For deleting the session cookie:

 setcookie( session_name() ,"",0,"/");

that worked for me.  When I ran that function without the last parameter, it didn't work.  If you leave out that parameter( domain ), it will default to the current directory, which isn't always the same as the session cookie's domain.



nick

powerlord at spamless dot vgmusic dot com
19-Nov-2002 03:41


This code might be a bit better for expiring session cookies, in case your domain, path, and/or secure session cookie settings are changed.



    $CookieInfo = session_get_cookie_params();

    if ( (empty($CookieInfo['domain'])) && (empty($CookieInfo['secure'])) ) {

        setcookie(session_name(), '', time()-3600, $CookieInfo['path']);

    } elseif (empty($CookieInfo['secure'])) {

        setcookie(session_name(), '', time()-3600, $CookieInfo['path'], $CookieInfo['domain']);

    } else {

        setcookie(session_name(), '', time()-3600, $CookieInfo['path'], $CookieInfo['domain'], $CookieInfo['secure']);

    }

    unset($_COOKIE[session_name()]);

    session_destroy();

add a note