ID: 24843 Updated by: [EMAIL PROTECTED] Reported By: luttgens at fusl dot ac dot be Status: Open Bug Type: Documentation problem Operating System: * -PHP Version: 4.3.2 +PHP Version: php >= 4.3.2 New Comment:
if using a user based session handler, php should go the long way in changing a session id. Currently php just changes the session id on an existing session stored, this is fine and good with like files (havent tested sqlite), but with user, creates some problems. The session handler just creates a new session, so you have two active, and keeps the data in the first, and the second one empty. PHP should really copy all data, destroy the old session, create the new session, and import the data into the new session. This avoids any issues with some session handlers that exist these days. thats my opinion anyway, better compatibility, even though theres a little overhead added. Previous Comments: ------------------------------------------------------------------------ [2003-07-29 06:38:44] [EMAIL PROTECTED] Yes, the documentation should be cleared up a bit. ------------------------------------------------------------------------ [2003-07-29 03:53:12] luttgens at fusl dot ac dot be Thanks for your reply, Sniper. This has been the opportunity to understand I've been somewhat too elliptic... So, if you allow, I will try to restate what I had in mind. Let's say I have defined my own session storage management through 6 functions (the args for session_set_save_handler()). On ***my*** system, the behavior seems to be as follows: Call to sessions_start(): 1. _open() gets called 2. _read($id) gets called 3. _gc($time) may be called (according to the "probability") Then, upon script completion: 4. _write($id, $data) gets called 5. _close() gets called Now, if session_regenerate_id() is called after session_start(), argument $id in step 4. indeed differs from what it was in step 2. And this could be used as an indication that an id regeneration has been performed, thus needing some housekeeping. BUT... Above description (steps 1. through 5.) is not explicitely documented, and thus by no means has an official status: it is just empirical. Thus, a first question is: "Does aforementioned change in $id occur through AND ONLY THROUGH a call to session_regenerate_id()?" Moreover, the documentation states: "The write handler is not executed if the session contains no data; this applies even if empty session variables are registered". On ***my*** system, _write($id, $data) seems to be allways called. But if the documentation is right (and my system being thus bogus), it couldn't be relied anymore upon a change in the value of argument id (as step 4. wouldn't occur). Another question is thus: "Could session_id() be reliably used in place to track a possible call to session_regenerate_id()?". Again, such a question occurs because trials tend to show that session_id() indeed reflects the effects of session_regenerate_id(), but this too is empirical only. I would feel more confident if the documentation established true and explicit cross-references for session_id() and session_regenerate_id(). Another formulation could be as follows. A. _read($id), _write($id, $data) and _destroy($id) all have an argument for a session-id. B. session_id() allows to read a "current" session-id. C. session_regenerate_id() allows to operate upon a "current" session-id. May it be taken for granted that all those things systematically refer to the same entity, so that they are allways in sync? Or does one really need some kind of feedback in the user-defined session functions upon a call of session_regenerate_id()? Could just be a kind of documentation "bug". Anyway, thanks again for the follow-up. ------------------------------------------------------------------------ [2003-07-28 10:21:10] [EMAIL PROTECTED] session_regenerate_id() only resets the current session id. Nothing else. ------------------------------------------------------------------------ [2003-07-28 09:45:02] luttgens at fusl dot ac dot be Description: ------------ Some testings tend to show that session_regenerate_id() doesn't call any of the user functions defined through session_set_save_handler(). Should it really be the case (apologies if I'm wrong), I'm wondering if this is a desirable behavior. I tend to consider this as a bug, as the concept of transparent session handling through user-defined functions gets broken: session_regenerate_id() becomes a special case that needs ad-hoc handling to keep in touch with whatever otherwise happens through session_start(), session_destroy() etc. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=24843&edit=1
