php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #61470 session_regenerate_id() do not create session file
Submitted: 2012-03-22 04:48 UTC Modified: 2015-02-02 09:43 UTC
Votes:7
Avg. Score:4.7 ± 0.5
Reproduced:7 of 7 (100.0%)
Same Version:5 (71.4%)
Same OS:4 (57.1%)
From: david at grudl dot com Assigned: yohgaki (profile)
Status: Closed Package: Session related
PHP Version: 5.4.0 OS: ANY
Private report: No CVE-ID: None
 [2012-03-22 04:48 UTC] david at grudl dot com
Description:
------------
session_start() creates and locks session file, but session_regenerate_id() doesn't do it. After session_regenerate_id() session is started with new ID, but the file is not created immediately (is created when session is closed) and therefore is not locked. 

I think this causes bugs like #49462.



Test script:
---------------
$path = ini_get('session.save_path') . '/sess_';

session_start(); 
// starts session & creates and locks file
echo is_file($path . session_id()); // -> TRUE

session_regenerate_id();
// starts new session, but file is not create!
echo is_file($path . session_id()); // -> FALSE


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-03-22 14:27 UTC] david at grudl dot com
Because this bug is very insidious and difficult to discover, I offer workaround https://github.com/nette/nette/commit/a4e4e80562cfb45d11d80e05d254fc207c456308#L0R241

$_SESSION is backed up before session_start() and restored to preserve the references.
 [2012-03-25 21:00 UTC] riptide dot tempora at opinehub dot com
How much of the bug is caused by having an echo before session_regenerate_id() which tries to send a new cookie to the end-user?
 [2012-03-27 16:23 UTC] david at grudl dot com
Usage of echo does not matter.
 [2012-03-28 08:02 UTC] yohgaki@php.net
-Status: Open +Status: Assigned -Operating System: Windows 7 x64 +Operating System: ANY -Assigned To: +Assigned To: yohgaki
 [2012-03-28 08:02 UTC] yohgaki@php.net
I have to deal with session ID collision detection in session_regenerate_id() for 
strict session.

I think I found what's wrong. Assigned to myself.
 [2012-05-24 21:19 UTC] chris at netshake dot de
This Workaround works well for me.

// Session is already started

session_regenerate_id( true ); // delete old session
session_write_close(); // i'm not sure about that but it's required.
session_start(); // reinitialize session with newly created id from 'session_regenerate_id()'

I hope that future PHP-Versions will not make problems with this.

Greets Chris
 [2014-10-26 23:41 UTC] 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.
 [2014-10-27 00:14 UTC] 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-29 01:41 UTC] 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-29 03:53 UTC] 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 06:44 UTC] 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 06:46 UTC] yohgaki@php.net
Oops. Hit submit button too early, but I think you can get what I mean.
 [2014-10-29 10:57 UTC] webmaster at tubo-world dot de
Let's be concrete.

session_start();
session_regenerate_id();
// send headers
// new request between new session id and written session id
session_write_close();

The only place where session data could be lost is when a new request comes with a regenerated session id that is not saved yet. Now you propose to create the session file/lock already in session_regenerate_id to circumvent the problem. This way the new request will definitely block. This would solve the problem for the 'files' save handler indead. BUT there is no way this behavior can be replicated for custom save handlers! session_regenerate_id does not call any methods of a save handler. So custom save handlers would never be able to also create a lock.

This is way I said, the only solution in the moment is for users to make sure the regenerated session is saved before the headers are sent. Then there is no problem at all. So to me this is more a documentation issue and I don't think PHP can do anything here with the current design of the session extension.
 [2015-02-02 09:43 UTC] yohgaki@php.net
-Status: Assigned +Status: Closed
 [2015-02-02 09:43 UTC] yohgaki@php.net
It's fixed already. Probably by use_strict_mode patch. Test for this bug is added.

 http://git.php.net/?p=php-src.git;a=commitdiff;h=fb803ff81993eb8acde0cdd5f513b6253221c349
 [2015-02-02 22:26 UTC] webmaster at tubo-world dot de
@yohgaki How to replicate that behavior with custom save handlers? Since session_regenerate_id does not trigger any callable, it seems impossible. If so, the PHP session extension is broken by design.
 [2015-02-03 03:24 UTC] yohgaki@php.net
Automatic comment on behalf of yohgaki
Revision: http://git.php.net/?p=php-src.git;a=commit;h=e93042998af1fea9204e17bc5cdd13c702156d5b
Log: Fixed bug #61470 - session_regenerate_id() does not create session file. Made session_regenerate_id() raise error for wrong usage.
 [2016-07-20 11:39 UTC] davey@php.net
Automatic comment on behalf of yohgaki
Revision: http://git.php.net/?p=php-src.git;a=commit;h=e93042998af1fea9204e17bc5cdd13c702156d5b
Log: Fixed bug #61470 - session_regenerate_id() does not create session file. Made session_regenerate_id() raise error for wrong usage.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sat Dec 07 09:01:24 2019 UTC