ID: 24843
Updated by: [EMAIL PROTECTED]
Reported By: luttgens at fusl dot ac dot be
-Status: Open
+Status: Bogus
Bug Type: Session related
Operating System: *
-PHP Version: php >= 4.3.2
+PHP Version: 4.3.2
New Comment:
There is nothing wrong with the function. RTFM.
Previous Comments:
[2004-09-05 12:27:47] hdNOSPAM at phportals dot de
PHP MUST call the user functions to destroy the old session data. The
now working way is a high risk, because people expect another
implementation than it is now.
[2004-07-13 07:20:17] support at spill dot nl
Unless this is handled differently for the default (file-based) session
handler, the current implementation of session_regenerate_id() would
leave stale files (possibly containing sensitive session data). I agree
with nathan php should go the long way and make sure to destroy the old
session.
About the calling of the write function of user defined session
handlers even on empty sessions, ages ago I reported this bug:
http://bugs.php.net/bug.php?id=25954
I think this should either be fixed in the documentation, or (if this
is unwanted behaviour) in PHP itself.
[2004-06-29 08:34:45] [EMAIL PROTECTED]
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.
[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.
--
