Destroying a session from a background job
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:
$_GET[session_name()]=$sid;
session_start();
// prove we are getting the web session data
foreach($_SESSION as $k => $v) echo($k."=".$v);
// now kill the thief
$_SESSION['username']=NULL;
//web session variable now NULL - honestly!
session_destroy
(PHP 4, PHP 5)
session_destroy — セッションに登録されたデータを全て破棄する
説明
bool session_destroy ( void )session_destroy()は、現在のセッションに 関連づけられた全てのデータを破棄します。この関数は、 セッションに関するグローバル変数を破棄しません。 また、セッションクッキーを破棄しません。
ユーザーがログアウトするときのように、セッションを切断するには、 セッション ID の割り当ても解除する必要があります。セッション ID の受け渡しに クッキーが使用されている場合（デフォルト）には、セッションクッキーも 削除されなければなりません。 そのためには setcookie() が利用できます。
返り値
成功した場合に TRUE を、失敗した場合に FALSE を返します。
例
例 2208. $_SESSIONでセッションを破棄する
<?php
// セッションの初期化
// session_name("something")を使用している場合は特にこれを忘れないように!
session_start();
// セッション変数を全て解除する
$_SESSION = array();
// セッションを切断するにはセッションクッキーも削除する。
// Note: セッション情報だけでなくセッションを破壊する。
if (isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time()-42000, '/');
}
// 最終的に、セッションを破壊する
session_destroy();
?>
注意
注意: $_SESSION を使っていない古いコードでのみ session_unset() を使用するようにしましょう。
参考
| unset() |
| setcookie() |
session_destroy
administrator at anorhack dot com
01-Aug-2007 11:34
01-Aug-2007 11:34
wade at defianceinteractive dot com
13-Feb-2007 04:59
13-Feb-2007 04:59
You should also be careful when you destroy a session. I believe a previous user posted something similar to this but didn't emphasize this point.
If you are creating a new session, but want to make sure that there are currently no sessions active by doing session_destroy(); make sure you start the session again using session_start(); or else your session data will not register properly.
Colin
07-Feb-2007 06:52
07-Feb-2007 06:52
Note that when you are using a custom session handler, session_destroy will cause a fatal error if you have set the session destroy function used by session_set_save_handler to private.
Example:
Fatal error: Call to private method Session::sessDestroy()
where sessDestroy was the function I specified in the 5th parameter of session_set_save_handler.
Even though it isn't all that desirable, the simple solution is to set sessDestroy to public.
r dot swets at guidance dot nl
21-Dec-2006 05:59
21-Dec-2006 05:59
Bothering with the timestamp can always give troubles. A lot better is forcing the sessionid to be regenrerated. A trick to destroy the session completly is actually restarting the session, like someone closed and reopened his browser. This will fix the whole authority problem and browser cookie deletion problem quite more easy, and it gives cleaner code without having to clean the $_SESSION array.
I would suggest the following function session_restart();
<?php
session_start();
// Some simple code etc etc
$requested_logout = true;
if ($requested_logout) {
session_restart();
}
// Now the session_id will be different every browser refresh
print(session_id());
function session_restart()
{
if (session_name()=='') {
// Session not started yet
session_start();
}
else {
// Session was started, so destroy
session_destroy();
// But we do want a session started for the next request
session_start();
session_regenerate_id();
// PHP < 4.3.3, since it does not put
setcookie(session_name(), session_id());
}
}
?>
NOTE: session_restart() acts like session_start(), so no output must be written before its called.
rob a.t. mobius d.o.t. ph
02-Dec-2006 07:02
02-Dec-2006 07:02
I was experiencing problems with "sess_deleted" files and tracked it down to:
setcookie(session_name(), '', time()-42000, '/');
When "setcookie" is passed an empty value (ie, ''), it changes the value to the string "deleted" and sets the date to exactly one year and one second in the past, ignoring the expiration parameter.*
So, I'm guessing that if a client machine has its time set to more than a year in the past or if the browser is somehow broken, then a site visitor could potentially send a PHPSESSID with a value of "deleted". This will cause PHP to create a "sess_deleted" file in the sessions directory.
In my case, I was seeing several incidents per minute, with each user clobbering the other's session data causing all kinds of security and identity issues. Two changes seemed to have solved the problem:
1) Use session_id() in place of '' in setcookie, as well as pick a date that's far in the past (in this case Jan 1, 1970, 8:00:01AM):
setcookie(session_name(), session_id(), 1, '/');
2) Use session_regenerate_id() when logging a user in or otherwise changing their authority level.
Hope this helps somebody.
Rob
* Here is the relevant code in head.c:
if (value && value_len == 0) {
/*
* MSIE doesn't delete a cookie when you set it to a null value
* so in order to force cookies to be deleted, even on MSIE, we
* pick an expiry date 1 year and 1 second in the past
*/
time_t t = time(NULL) - 31536001;
dt = php_format_date("D, d-M-Y H:i:s T", sizeof("D, d-M-Y H:i:s T")-1, t, 0 TSRMLS_CC);
sprintf(cookie, "Set-Cookie: %s=deleted; expires=%s", name, dt);
markus at fischer dot name
16-Mar-2005 06:09
16-Mar-2005 06: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.
Johan
20-Nov-2004 11:00
20-Nov-2004 11: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
08-Oct-2004 12:25
08-Oct-2004 12: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 .
powerlord at spamless dot vgmusic dot com
19-Nov-2002 04:41
19-Nov-2002 04: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();