难以从网站注销用户

Question

Writing a small CMS. User authentication is by session variables set with php, in a named session. When logout is called, an ajax routine loads a separate php script which does the work. This separate script uses the same session parameters. The session variables are over-written individually with random data, and the session is then destroyed. This works. Examining the browser cookie-list after logout shows that the session cookie has been removed. So far, all OK.

Problem arises if the user either navigates away to another page of the same site whilst logged on, or opens a second page in a new browser tab. Once either has been done, the logout routine cannot destroy or unset the session. Worse, even if the password session variable was randomized at logout, reloading the page reinstates it to its previous value, effectively logging the user back on.

Examining the browser data shows that the session cookie has failed to delete on session_destroy() being issued, and nothing I can do programmatically will delete it.

I'm trying to figure out why opening a second site page (which uses the same session parameters) should seemingly lock the session so it cannot be destroyed from either page. Nowhere does the php manual suggest any such behaviour.

Browser cacheing has been suggested as a possible culprit, but seems unlikely.

Been wrestling with this for some time. Any ideas?

Testing done in Firefox, versions 6 to latest.

Answer 1

session_destroy() doesn't unset the session cookie (or reset the $_SESSION global variable for that matter); it only destroys the server-side session data storage (a file in the default, file-based sessions configuration). Removing the cookie (which can be done "manually" using setcookie() with an empty value) is not necessary to destroy the session data. When session_destroy() is called but the cookie is left intact, using session_start() on a subsequent request will start a new session with the same ID (unless you also call session_regenerate_id() ) but with no session data.

Now regarding your problem, it's really hard to say what's going on without seeing the code, but here's a couple of thoughts:

The session variables are over-written individually with random data, and the session is then destroyed.

There's no point in setting the session data to anything prior to calling session_destroy() since these new values will never make it to the session data storage.

Examining the browser cookie-list after logout shows that the session cookie has been removed.

Like I said, the cookie doesn't get removed automatically; it's more likely it din't get set.

Worse, even if the password session variable was randomized at logout, reloading the page reinstates it to its previous value

This would suggest the session_destroy() doesn't actually destroy anything. Which leads me to a suspition that in your logout script you don't initialize the session (with session_start() ) before trying to destroy it. This should result in a PHP warning which you might not see because you have warning suppressed, or because the script is called through AJAX.

Another, altough less likely possibility is that your logout script does start and then destroy a session, but a completely different one. Use Firebug or a similar tool to see if (and what) session cookie is sent with your AJAX request.

And finally, as someone has already mentioned: you might want to rethink your entire authentication mechanism if you need to store passwords in session variables, but that's a completely different topic.

Answer 2

MarcB has the answer - session_write_close() must be issued before destroying the session.

With this in the ajax logout routine, logging out from any page kills the user's editing rights on all open pages, as it should.

Thanks.