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

go to bug id or search bugs for

Bug #70013 Reference to $_SESSION is lost after a call to session_regenerate_id()
Submitted: 2015-07-07 23:44 UTC Modified: 2015-09-15 06:22 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: jakub at zalas dot pl Assigned: yohgaki (profile)
Status: Closed Package: Session related
PHP Version: 7.0Git-2015-07-07 (Git) OS: Debian
Private report: No CVE-ID: None
View Developer Edit
 [2015-07-07 23:44 UTC] jakub at zalas dot pl 
Description:
------------
If a reference to $_SESSION is assigned to another variable, it is lost after a call to session_regenerate_id(). It is not lost in previous PHP versions, and Symfony's HttpFoundation actually relies on this behaviour.



php -v
PHP 7.0.0-dev (cli) (built: Jul  7 2015 22:52:27) (DEBUG)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies

Test script:
---------------
session_start();

$session = &$_SESSION;

$session['test'] = 1;
session_regenerate_id(false);
$session['test'] = 2;

// dumps false, should be true
var_dump($session['test'] === $_SESSION['test']);

Expected result:
----------------
bool(true)

Actual result:
--------------
bool(false)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-07-08 07:06 UTC] stloyd at o2 dot pl 
This is BC break that can be easily reproduced: http://3v4l.org/PRhdj
 [2015-07-08 15:10 UTC] [email protected] 
It is a BC break, but I'm not sure if the behavior before was correct.

References should normally be broken up before deletion…
And session_regenerate_id() is exactly that: delete old session, create new session.
 [2015-07-09 09:16 UTC] [email protected] 
Bob: first of all, deleting the old session won't happen by default, so your definition is a bit misleading, and also, from the "new" session will hold the same data only under a different session id, so I think not many people would expect that the $_SESSION superglobal will be recreated hence losing the reference.
if you add this to the fact that this is an undocumented behavior change I think we should consider this a bug and fix it.
 [2015-07-10 09:06 UTC] [email protected] 
+1, "deleting the session", if ever should mean on the backend under the old key; the data will stay the same and a reference to it should be kept intact.
 [2015-07-10 14:53 UTC] [email protected] 
I'd like mark this as won't fix.. the new behaviors seems more reasonable
 [2015-07-11 06:38 UTC] [email protected] 
It may seem more reasonable from an implementors point of view, because you're looking at the C codes, but definitely does not seem reasonable for an appointment developer.

This breaks userland in an very unintuitive way.
 [2015-07-11 06:39 UTC] [email protected] 
Autocorrection FTW.

Of course I meant application developer and s/codes/code/
 [2015-07-11 20:44 UTC] [email protected] 
Hi,

I guess we should revert the change to PHP5 behavior. Please do a proof read of

https://wiki.php.net/rfc/session-lock-ini
http://grokbase.com/t/php/php-internals/142dbaan9h/vote-rfc-introduce-session-start-options-read-only-unsafe-lock-lazy-write-and-lazy-destroy

and also bug #65746. This behavior change is a subset of the mentioned RFC which had major concerns and was declined. Until a proper solution is suggested and accepted, there is no reason to go for BC breaks.

Thanks.
 [2015-07-13 02:17 UTC] [email protected]
-Assigned To: +Assigned To: yohgaki
 [2015-07-13 02:21 UTC] [email protected] 
So what should I do? Restore old behavior or not?
 [2015-07-13 16:09 UTC] [email protected] 
Yasuo,

Me and Anatol, talked it over and we both believe that the old behavior should be restored as to how it was in PHP5. It creates a less WTF factor when upgrading too, even though the new behavior is makes more sense.

So please go ahead and commit a fix to revert the behavior back before Beta 2
 [2015-07-21 09:47 UTC] [email protected] 
Hi Yasuo,

what is the status of this? Obviously too late for beta2 (

Thanks.

Anatol
 [2015-08-08 22:15 UTC] [email protected] 
Yasuo, ping. Probably still should be fixed till RC1.

Thanks.
 [2015-09-06 05:53 UTC] [email protected] 
Sorry, I wasn't paying attention to this. I'll fix this soon.
 [2015-09-06 18:58 UTC] [email protected] 
Automatic comment on behalf of yohgaki
Revision: http://git.php.net/?p=php-src.git;a=commit;h=f34b858ed018d4c33bc0c3f03acc0bf143d35534
Log: Fix #70013: Reference to $_SESSION is lost after a call to session_regenerate_id()
 [2015-09-06 18:58 UTC] [email protected]
-Status: Assigned +Status: Closed
 [2015-09-15 06:22 UTC] [email protected] 
Thanks for the fix, Yasuo. I've added it to the NEWS.

Cheers.
 [2015-09-15 12:13 UTC] [email protected] 
Automatic comment on behalf of yohgaki
Revision: http://git.php.net/?p=php-src.git;a=commit;h=f34b858ed018d4c33bc0c3f03acc0bf143d35534
Log: Fix #70013: Reference to $_SESSION is lost after a call to session_regenerate_id()
 [2015-09-29 02:11 UTC] [email protected] 
Related To: Bug #70584
 [2015-09-29 06:33 UTC] buschmann at nidsa dot net 
Related To: Bug #70584
 [2016-07-20 11:36 UTC] [email protected] 
Automatic comment on behalf of yohgaki
Revision: http://git.php.net/?p=php-src.git;a=commit;h=f34b858ed018d4c33bc0c3f03acc0bf143d35534
Log: Fix #70013: Reference to $_SESSION is lost after a call to session_regenerate_id()
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Thu Jun 12 15:01:27 2025 UTC