tags:

views:

619

answers:

6

I'm trying to create an authentication mechanism for my PHP Application and I'm having difficulty destroying the session. I've tried unsetting the authentication token which was previously set within the session array and destroying the session through

session_destroy,

as well as resetting the session array completely before destroying the session. I'm calling the header function and going back to my index.php page at the end of the function calls. I've also tried

session_write_close

to handle closing the session. When I log the user out, I do a vardump of the session, and It shows no data present, however when I go back to the index.php page, I'm getting back the user authentication data. I also did a vardump of the Post data just to ensure I'm not somehow resubmitting the post authentication handler.

Any suggestions on what to do here?

A: 

I would check what is sending the browser to the server using Fiddler and also check what information do you have stored in your session.save_path

rossoft
A: 

Are you sure the page isn't cached?

Write over the authentication token:

session_start();
$_SESSION['varName'] = null;
$_SESSION = array();
session_destroy();
Scott Saunders
A: 

however when I go back to the index.php page

Isn't the particular page just been requested from the browser cache? Do a hard refresh of the page (CTRL+F5 in most webbrowsers).

If that turns out to be the cause and you want to disable request caching, add the following set of headers to HTML <head> your page:

<meta http-equiv="cache-control" content="no-cache,no-store,must-revalidate">
<meta http-equiv="pragma" content="no-cache">
<meta http-equiv="expires" content="0">

or, in the PHP code using PHP's header() function:

header('cache-control: no-cache,no-store,must-revalidate'); // HTTP 1.1.
header('pragma: no-cache'); // HTTP 1.0.
header('expires: 0'); // Proxies.

Don't forget to clear the browser cache before testing :)

BalusC
+1  A: 

First, make sure you're calling session_start(); before calling session_destroy(); because it will only issue a warning if you don't.

Also, from PHP: session_destroy:

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.
Jonathan Campbell
+1 for not calling session_start on the logout.php page.
Jonathan Kushner
A: 

Also worth noting about PHP sessions, session_unset() > session_destroy(); I do not know why. After reading the PHP Manual entry on session_destroy(), it seems to only remove data within the current context, and not actually clear it from the flat session file, so if you didn't clear the cookie you could get it right back. This seems highly counter-intuitive (as PHP often is), and might be the reason why I decided (and then promptly forgot the reason) years ago to always use session_unset() over session_destroy().

Also, make sure your redirect is occurring after you do all this session nonsense, as PHP acts in ways which not all developers expect. Best Practice, IMO, is to follow every header('Location: ...'); call with a die;

Dereleased
A: 

If you use only session_unset() then buggy IE still keeps data my suggestion is to use both.

Kaido

related questions