Edit report at https://bugs.php.net/bug.php?id=61470&edit=1
ID: 61470
Updated by: yohgaki@php.net
Reported by: david at grudl dot com
Summary: session_regenerate_id() do not create session file
Status: Assigned
Type: Bug
Package: Session related
Operating System: ANY
PHP Version: 5.4.0
Assigned To: yohgaki
Block user comment: N
Private report: N
New Comment:
Oops. Hit submit button too early, but I think you can get what I mean.
Previous Comments:
------------------------------------------------------------------------
[2014-10-29 06:44:27] yohgaki@php.net
Right. Even when session ID is not shared explicitly, locking could be useful.
As we knew, most browsers supports multiple connections (6 or so). Once session ID is set by cookie,
then subsequent request would request the new session ID that the date is not stored yet. (i.e. no
data file/record) This behavior could damage session data consistency.
This could be rare, but the app might be affected by this is perfectly valid app.
------------------------------------------------------------------------
[2014-10-29 03:53:58] david at grudl dot com
> there cannot be two concurrent requests for the same session?
They can be. session_regenerate_id() sends new cookie and next request is concurrent with the
current request.
------------------------------------------------------------------------
[2014-10-29 01:41:46] webmaster at tubo-world dot de
@yohgaki: I don't get it. Session file is created for locking on session_start for the given
id. But with session_regenerate_id you create a new, random session id. How would locking/creating a
session file make any difference when there cannot be two concurrent requests for the same session?
------------------------------------------------------------------------
[2014-10-27 00:14:41] yohgaki@php.net
Locking would not be useful most of the time. Shared session is rare in real apps, but such apps may
exist. Therefore, I would lock the file(data) as usual.
This bug is about new session ID file(data) isn't created when session_regenerate_id() is
called. It's inconsistent with automatic session ID generation. So I would like to fix this
issue in near future hopefully.
------------------------------------------------------------------------
[2014-10-26 23:41:45] webmaster at tubo-world dot de
There is no point in having session_regenerate_id create a file and lock.
It makes no sense at all since a parallel session_regenerate_id would create a different random ID
anyway.
All you have to make sure is, that you call session_write_close immediatly AFTER
session_regenerate_id as I also explained in #49462
This way, the data will be available on the next request. See also https://github.com/symfony/symfony/issues/7885
So I think the issue can be closed.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=61470
--
Edit this bug report at https://bugs.php.net/bug.php?id=61470&edit=1