What does session_destroy() actually destroy?

The documentation says session_destroy() "destroys all of the data
associated with the current session". Um, like what?

The docs further say that you should remove all information in the _SESSION
global with $_SESSION = array() and you should use setcookie() to set the
session cookie to a blank value. Having done those, what does that leave
session_destroy() to do?

The page at http://au2.php.net/manual/en/functio...on-destroy.php
bandies about terms like "Unset all of the session variables", "If it's
desired to kill the session..." and "destroy the session" without actually
explaining them. That last one is used in the context of a call to
setcookie() and then again in the context of a call to session_destroy().

My current code, which I need to be as secure as possible, doesn't call
session_destroy() because I can't see what it does. Can someone enlighten
me?

--
The email address used to post is a spam pit. Contact me at
http://www.derekfountain.org : <a
href="http://www.derekfountain.org/">Derek Fountain</a>

Derek Fountain wrote:
[color=blue]
> The documentation says session_destroy() "destroys all of the data
> associated with the current session". Um, like what?
>
> The docs further say that you should remove all information in the
> _SESSION global with $_SESSION = array() and you should use setcookie() to
> set the session cookie to a blank value. Having done those, what does that
> leave session_destroy() to do?
>
> The page at http://au2.php.net/manual/en/functio...on-destroy.php
> bandies about terms like "Unset all of the session variables", "If it's
> desired to kill the session..." and "destroy the session" without actually
> explaining them. That last one is used in the context of a call to
> setcookie() and then again in the context of a call to session_destroy().
>
> My current code, which I need to be as secure as possible, doesn't call
> session_destroy() because I can't see what it does. Can someone enlighten
> me?
>[/color]

Hi,

This note of Johan on the same page maybe gives a hint:

-----------------------
Johan
20-Nov-2004 03: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.
-----------------------

So you can use the command session_destroy() to make sure you have access to
the sessionvar untill the end of the script, where your session will be
destroyed.

I must say I never use that function.
When I have authenticated a user I store a key (eg $_SEESION["userid"]) in
the session.
Every script that requires a authenticated user checks for this first.
When I want the user to log out, I simply use $_SESSION = array().

So I NEVER use the fact that a SESSION exists as a 'proof' of
authentication.
It raises all kind of problems (IMHO).
Better is: The session must exists AND it must contain a userid (or whatever
suits you).
CHeck for the existence of that key.

Hope this helps,

Regards,
Erwin Moller

Derek Fountain wrote:[color=blue]
> The documentation says session_destroy() "destroys all of the data
> associated with the current session". Um, like what?[/color]

It deletes the session file. Session file is the one which holds the
serialized session variables; should be available on session path
usually a temp directory on server.
[color=blue]
> The docs further say that you should remove all information in the[/color]
_SESSION[color=blue]
> global with $_SESSION = array() and you should use setcookie() to set[/color]
the[color=blue]
> session cookie to a blank value. Having done those, what does that[/color]
leave[color=blue]
> session_destroy() to do?[/color]

When you session_start(), it actually populates the $_SESSION
array--the values will be available till the script ends--even if you
use session_destroy() in the middle--which is the case, you may want to
avoid-- and so $_SESSION = array().

On usual configurations, cookie will hold the session id.
session_destroy() only deletes the session file at server--it doesn't
reset the session cookie. Since, PHP's session management is
"permissive", even if you delete the session file (and hence the
session data) with session_destroy(), in the next session_start() (the
execution of next page), it will create a session with session id which
is same as of previous (deleted) session. It happens as the session id
of previous (deleted) session is still available in the cookie. That's
why the suggestion is to reset the session cookie--so that you get new
session id (hence "pure new session").

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

Derek Fountain wrote:
[color=blue]
> My current code, which I need to be as secure as possible, doesn't call
> session_destroy() because I can't see what it does. Can someone enlighten
> me?[/color]

session_destroy destroys the storage for session_data. As some other
comment mentioned (which was new to me), these data (which live in
$_SESSION and the file in which they are stored for "files"-type sessions)
are destroyed after the script ends.

For maximal session security, i also destroy the session cookie:

session_destroy();
session_id(session_name(), '', time() - 3600);

or at the very least you should generate a new session id.

good ruck.
marc.



--
I am not an ANGRY man. Remove the rage from my email to reply.