session_destroy

(PHP 4, PHP 5, PHP 7)

session_destroy — Destroys all data registered to a session

Description

boolsession_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.
To use the session variables again, session_start() has
to be called.

Note:
You do not have to call session_destroy() from usual
code. Cleanup $_SESSION array rather than destroying session data.

In order to kill the session altogether, 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.

When session.use_strict_mode
is enabled. You do not have to remove obsolete session ID cookie because
session module will not accept session ID cookie when there is no
data associated to the session ID and set new session ID cookie.
Enabling session.use_strict_mode
is recommended for all sites.

Warning

Immediate session deletion may cause unwanted results. When there is
concurrent requests, other connections may see sudden session data
loss. e.g. Requests from JavaScript and/or requests from URL links.

Although current session module does not accept empty session ID
cookie, but immediate session deletion may result in empty session ID
cookie due to client(browser) side race condition. This will result
that the client creates many session ID needlessly.

To avoid these, you must set deletion time-stamp to $_SESSION and
reject access while later. Or make sure your application does not
have concurrent requests. This applies to session_regenerate_id() also.

Return Values

Examples

<?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 (ini_get("session.use_cookies")) {$params = session_get_cookie_params();setcookie(session_name(), '', time() - 42000,$params["path"], $params["domain"],$params["secure"], $params["httponly"] );}

It took me a while to figure out how to destroy a particular session in php. Note I'm not sure if solution provided below is perfect but it seems work for me. Please feel free to post any easier way to destroy a particular session. Because it's quite useful for functionality of force an user offline.

1. If you're using db or memcached to manage session, you can always delete that session entry directly from db or memcached.

For session_destroy() only destroy current session mean that if you specify name or change the save path of session etc ,it will not destroy it mean for example

create.php

<?php session_name('testing') ;session_start() ;

$_SESSION['id'] = '35' ; ?>

delete.php<?php session_start() ;

session_destroy() ;?>

session_destroy only delete the new session which is created by session_start(). correct way is <?php session_name('testing') ;session_start() ;

session_destroy() ;?>

this is also valid for if you change session.save path throught ini_set() , you have to mention in delete.php. remember session_destroy() function destroy only current session not all .i hope this is worth to mention.

What I discovered is that clearing $_SESSION and removing the cookie destroys the session, hence the warning. To avoid the warning while still keeping the value of using session_destroy(), do this after everything else:

I have a thief-protection system that compares country codes from login IPs via whois. This has to run in the background as it is way too processor-hungry to be run in the browser.

What I needed was a way to destroy the web session from the background job. For some reason, a background session_destroy APPEARS to work, but doesnt't actually destroy the web session.

There is a work around, I set the username to NULL and the web code picks up on that, bouncing the user (thief) to a "gotcha" page where his IP is logged.

Yes I know its nasty and dirty, but surprisingly it works.

$sid = the session_id() of the suspicious web session, passed in $argv to the background job

The trick is to "stuff" the $_GET array with the sid, then the session_start in the background job picks this value up (as if it were a genuine trans-sid type thing...?PHPSESSID=blah) and "connects to" the web session. All $_SESSION variable can be viewed (and CHANGED , which is how this kludge works) but for some reason (that no doubt someone will illuminate) they can't be unset...setting the particular variable to NULL works well though: