Um, this might sound a bit weird. We were having some problems with a specific browser under a very specific condition, and finally narrowed down the problem to the fact that we were not properly destroying the old sessions after doing session_regenerate_id(). I believe I have solved this problem by doing session_regenerate_id(true) now, but how does one verify that the previous sessions really do not exist any more? Someone suggested cURL but I cannot find my way around their docs. Sadly(?) the boss does not take 'it just works' for an answer so I'd really appreciate any advice!
To be sure that the session data are gone, you should look at the session saving backend. By default it stores sessions as plain disk files (this is why a session survives an apache restart for example). You may want to look through them, and check that the one corresponding to the session you were observing has been effectively deleted.
Or, if this is such a critical information, you may want to build your own session backend (which is not difficult at all) to have even more control, and more debugging options (you'd manually destroy the data and you could add logging statements to demonstrate that the data has been deleted).
See here: http://php.net/manual/en/function.session-set-save-handler.php
Or here: http://devzone.zend.com/article/141
By default session_regenerate_id();
will only replace the current session with a new one. So the old session file need not actually get deleted.
But doing a session_regenerate_id( true );
will delete the old session file. ( http://php.net/session_regenerate_id )
To check if old session is deleted you can do something like this
<?php
$file=ini_get('session.save_path')."/sess_".session_id();
$gotDeleted = file_exists( $file );
?>
You can also do a session_destroy()
. If you must keep some variables, you can try unset()
on specific $_SESSION
values.