go to bug id or search bugs for
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.
Add a Patch
Add a Pull Request
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.
This bug is related to
Procedure to reproduce this issue
Start CLI server
$ php -S 127.0.0.1:8888
Access test.php and press F5 few minutes
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.
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.
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.
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.
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
Related To: Bug #74118