session_destroy: It this method a bad idea?

Joseph_Sliker

Hi;

I have a multi-frame site that depends a lot on session values that get set and reset as the user moves along through various tasks and menus.

I am trying to create a clean simple logout process that really clears all that junk when the user logs out.

I have not used cookies, just sessions.

Upon first arriving at my site the very top of the login/menu page (in a frame on the left side of the browser window) runs like so:

<?php
session_start(); //page needs to load any existing session to destroy it.
session_destroy(); // I think this is the trick!
session_start(); //this has to be re-started so the subsequent login stuff will work
?>
...then the rest of the html/php stuff runs including presenting them with a login form....

Clicking the submit button sends them back to this page, and depending on what they entered in the username and password boxes, a mysql query runs on this page and lets them in or not (and looks up/creates whichever function buttons their login allows) and fills in various session variable/values that will apply to the various functions.

A successful login also creates a logout button, which reloads target="_top" (the frames page) and passes no values. So when they click that, the same login/menu page runs again with

and I think this does the trick: while testing I always "print_r($_SESSION);" at the very end of the page and the results seem to be what I intend.

This was all developed through my typical RTE development method (rapid trial & error) but it seems to work.

Does anyone out there who actually understands this stuff have any cautions for me about doing this this way?

Thanks.

NogDog

Look at Example #1 on the [man]session_destroy[/man] manual page for how to completely log someone out. session_destroy only destroys the data stored on the host for that session ID, but does nothing regarding the data in $_SESSION, nor does it get rid of the session ID cookie.

Joseph_Sliker

Thanks for that reply and suggestion...maybe I am doing it wrong, but the original method seems to work more reliably for me:

If I use my original code:

session_start();
session_destroy(); // I think this is the trick!
session_start();

I can log in as one person, all the linked pages seem to work as appropriate for that person, I can then log out, and immediately log back in as someone else, and all pages seem to work fine for that person. Everything seems to work fine so far as I have tested it (it's a very complex site)

BUT if I replace that with the code taken directly from the manual:

// 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();
(....tried it both with and without adding session_start(); at the end here)

...logging out and logging back in as someone else does NOT work: even though I can log in as a different user, the subsequent pages that depend on a new set of session variable/values related to that new user do not work properly: it is as if the required session values do not exist at all for the new user.

If I am using a frames page, do the session functions have to be coded into it somehow?

NogDog

Each separate frame's file will need a session_start() (before anything is output) if that frame needs to read and/or write session data.

Weedpacket

Urk; I've never been a fan of frame-driven sites. As soon as you have communication between frames you're into all sorts of synchronisation-problem territory. And if two frames are refreshed concurrently - which one gets run first?

Joseph_Sliker

I have heard that frames are not a good idea, but the main site I'm concerned with is work-related and it has taken on a life of it's own with hundreds of users and tens of thousands of datapoints being contributed each year, so I dare not mess with the design too radically all at once. Mostly I'm trying to weed out (sorry) the really horrible Rube-Goldberg type scripting that I wrote for some of the earliest functions.

I think I have to just stick with my existing (start/destroy/(re)start) method for now. It does seem to behave just the way I need it to. If someone tells me that there is some specific serious inherent danger in not doing it more by the book, I'll try to revisit it.