Apache Friends Support Forum

I've been playing about with php sessions (with no cookies) and noticed this:

<?php session_start(); echo session_id(); ?>
creates and displays my session key in xampp/tmp and

<?php session_destroy(); ?>
deletes the key.

But ...
(1) If I open the session again, I get the same key assigned, so it seems to be stored somewhere besides xampp/tmp ...? In RAM perhaps ...?

(2) Also, if - instead of session_destroy() - I just close my browser, the session key in xampp/tmp isn't deleted at all. That doesn't look right to me - shouldn't the key be destroyed whenever the browser is closed, irrespective of whether a session_destroy has been processed or not ...?

Cheers.

I could be wrong here, but It seems like garbage collection probability must be calculated to 1 (= certainty) to successfully purge session keys ...

Just changing the session.gc_maxlifetime from 1440 to 0 in php.ini will still leave the old session key in xampp/tmp.

But also changing session.gc_divisor = 1 (prev 100), for calculating garbage-removal probability, will cause the old session ID to be over-written with a new session ID.

Seems a bit messy to me - does anyone know of a water-tight way of assuredly purging a session key without having to overwrite it with another one ...?

Cheers.

Hi kiwinz,

kiwinz wrote:I've been playing about with php sessions (with no cookies)

What does "with no cookies" mean? Do you add the SID in the url?

kiwinz wrote:<?php session_start(); echo session_id(); ?>
creates and displays my session key in xampp/tmp and

session_start don't create a session_key if one already exists.

kiwinz wrote:<?php session_destroy(); ?>
deletes the key.

session_destroy() don't delete the key.
The Manual for session_destroy() says everything needed:

session_destroy() destroys all of the data associated with the current session. It does not unset any of the global variables associated with the session, or unset the session cookie. To use the session variables again, session_start() has to be called.

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.

kiwinz wrote:(2)Also, if - instead of session_destroy() - I just close my browser, the session key in xampp/tmp isn't deleted at all. That doesn't look right to me - shouldn't the key be destroyed whenever the browser is closed, irrespective of whether a session_destroy has been processed or not ...?

How should the server know, that the user has closed his browser? The browser don't send any information about that to the server. Thats for what the garbage collector is for.
Think about how the server can know that your Browser has already sended a request and get a session which can be reused.

kiwinz wrote:I could be wrong here, but It seems like garbage collection probability must be calculated to 1 (= certainty) to successfully purge session keys ...

very bad idea to change anything for the gc if you have no idea what you are doing. gc is already configured with the recommend settings and values.

best wishes,
Altrea

Thanks for the response Altrea!

'No cookies' just means I'm not using client-side session management, it's all being done on the server.

But from what I've read at http://stackoverflow.com/questions/758790/how-to-delete-a-php-session it looks like an open session key existing after a session_destroy() isn't an issue, as the session array will be emptied anyway, so the key could be safely re-used. I suppose it could be overwritten with session_regenerate_id() immediately after session_destroy(), but that wouldn't work if the user just closes their browser without signing off, as session_destoy() wouldn't be run in that case.

Still, it looks like your suggestion of unset session_id() would be useful for reducing garbage in cases where the visitor does log off, and I'll just have to rely on time-out functions to clean up otherwise.

Cheers!

kiwinz wrote:'No cookies' just means I'm not using client-side session management, it's all being done on the server.

Even if you are not storing any Data in Cookie client side, there will be a cookie generated with the SID in it. Thats the way the browser can identify itself to the server.
If you want to be sure the session will not be reused, you could simple invalid the SID cookie. The client will not use it anymore and the server can't identify it to give it the known SID.

kiwinz wrote:But from what I've read at http://stackoverflow.com/questions/7587 ... hp-session it looks like an open session key existing after a session_destroy() isn't an issue, as the session array will be emptied anyway, so the key could be safely re-used.

correct.

kiwinz wrote:I suppose it could be overwritten with session_regenerate_id() immediately after session_destroy(), but that wouldn't work if the user just closes their browser without signing off, as session_destoy() wouldn't be run in that case.

There are other reasons why a session id should change. In your case it is not needed.

kiwinz wrote:Still, it looks like your suggestion of unset session_id() would be useful for reducing garbage in cases where the visitor does log off, and I'll just have to rely on time-out functions to clean up otherwise.

?? The garbage collector does good work to reduce garbage. I don't know what more you want to have.

best wishes,
Altrea