php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data
Submitted: 2015-02-26 18:05 UTC Modified: 2021-09-28 14:29 UTC
Votes:14
Avg. Score:4.9 ± 0.3
Reproduced:13 of 14 (92.9%)
Same Version:12 (92.3%)
Same OS:1 (7.7%)
From: rbsimao at yahoo dot com dot br Assigned: yohgaki (profile)
Status: Assigned Package: Session related
PHP Version: Any OS: Any
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: rbsimao at yahoo dot com dot br
New email:
PHP Version: OS:

 

 [2015-02-26 18:05 UTC] rbsimao at yahoo dot com dot br 
Description:
------------
---
From manual page: http://www.php.net/function.session-regenerate-id
---

The piece of code below works ok most of the time. Randomly it does not work: session_regenerate_id(true) issues a warning saying it could not delete the old session data. But the session file is there and the permissions are untouched. Also, when it issues the warning, all the session data is lost on the new generated session.

Tested on ubuntu11 to ubuntu14 with default phps and windows 7/php5.5.

Test script:
---------------
<?php

session_start(); 
session_regenerate_id(true);
session_write_close();

?>

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-02-27 05:00 UTC] yohgaki@php.net
-Status: Open +Status: Verified -Assigned To: +Assigned To: yohgaki
 [2015-02-27 05:00 UTC] yohgaki@php.net 
This is known issue and I proposed fix for this.
However, there are people who do not like my proposal.

Since session data and browser is not synced, session module must handle session_regenerate_id(true) in async way. This is what I proposed before.

I shall try to fix this again. Thank you for reporting.
 [2015-05-24 06:22 UTC] yohgaki@php.net 
This bug is related to
https://bugs.php.net/bug.php?id=65746
 [2015-09-07 22:17 UTC] yohgaki@php.net
-Operating System: debian7, ubuntu11-12-13-14, win7 +Operating System: Any -PHP Version: 5.5.22 +PHP Version: Any
 [2015-09-19 23:41 UTC] yohgaki@php.net 
Procedure to reproduce this issue

test.php
--------------
<?php
ob_start();
session_start();
echo "<pre>";

var_dump(session_id(),
		 $_SESSION['v']++);
session_regenerate_id(true);
var_dump(session_id());
?>
--------------

Start CLI server
$ php -S 127.0.0.1:8888

Access test.php and press F5 few minutes
http://127.0.0.1:8888/test.php

You'll see counter value ($_SESSION['v']) is resetted sometimes.

PHP 7.0 git + Fedora 22 + Chrome 45.0.2454.93 (64-bit) : Easy to reproduce. Thousands of requests are enough.
PHP 7.0 git + Fedora 22 + Firefox 40.0.3 : Very hard to reproduce. Tens of thousands of requests are required.

CLI server process requests one by one. The reason why there is difference would be how browser locks cookie data. It seems Chrome locking is more lazy or no locks at all. (BTW, even if browser locks cookie strictly, lost packet/etc could cause lost session. Therefore, "eventually consistent" approach is required for reliable HTTP session management.)

Let me know if you(anyone) could reproduce the bug or not by this procedure - PHP version, OS name/version, Browser name/version and easiness/hardness of reproducibility.
 [2015-09-29 02:07 UTC] yohgaki@php.net 
Related RFC
https://wiki.php.net/rfc/precise_session_management
 [2015-12-29 00:33 UTC] yohgaki@php.net
-Status: Verified +Status: Analyzed
 [2016-01-13 19:06 UTC] yohgaki@php.net 
Session module code has race condition.

When session_regenerate_id(true) is called, session module close/unlock current session, then remove it. If there is other access for the session, it waits until unlocked and accesses empty obsolete data.

This situation can be avoided by RDBMS's serialized level transaction isolation, but file system based storage cannot.
 [2016-04-13 22:12 UTC] jolyon at nixbox dot com 
Is this also related to alternate session handlers?  session_regenerate_id is failing for us when we add a custom save handler (memcache, in our case) and is returning the same error:

Recoverable Error(4096) session_regenerate_id(): Failed to create(read) session ID: user (path: /var/lib/php/session) occurred at line 320 in /var/local/app/library/Zend/Session.php

We are using version 1.12.16 of Zend Framework.  After troubleshooting their library code, I believe this is a core PHP issue, not ZF.  

I think this might be indirectly related, but if not I will create a new ticket with details.
 [2016-04-13 22:14 UTC] jolyon at nixbox dot com 
I forgot to add our issue is PHP 7.0.x only, When we switch back to PHP 5.6.20, session_regenerate_id works fine with our memcache backend.  Also, turning off memcache backend entirely resolves the issue.  For now, we can just not use regenerateId, but would prefer to keep it enabled for session security reasons.
 [2016-04-13 22:33 UTC] jolyon at nixbox dot com 
My bad, apparently this is a known issue with a patch in the works for ZF1 - please disregard previous two comments.  https://github.com/zendframework/zf1/issues/659
 [2017-02-17 17:24 UTC] cmb@php.net 
Related To: Bug #74118
 [2017-10-24 03:06 UTC] kalle@php.net
-Status: Analyzed +Status: Assigned
 [2021-09-28 14:29 UTC] cmb@php.net 
This looks partially related to bug #78155.  We would need
separate lock files for each session to avoid the server side race
condition.  However, that would not solve the client side/network
issues.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Fri Nov 22 05:01:29 2024 UTC