Doc #76358 [Opn]: Cannot change session name when session is active

Edit report at https://bugs.php.net/bug.php?id=76358&edit=1 ID: 76358 Updated by: requinix@php.net Reported by: tony at marston-home dot demon dot co dot uk Summary: Cannot change session name when session is active Status: Open Type: Documentation Problem Package: Session related Operating System: Windows 10 PHP Version: 7.2.5 Block user comment: N Private report: N New Comment: Actually, correction on 3: > 3. It should not change the session name but it should return the "old" (still > current) one. As such it should warn > that the name couldn't be changed. This is a compromise between 2 and 4. Somewhat BC. "Somewhat" because it depends on the code, like whether it calls any additional session functions. But forget that. I just realized that the use of session_regenerate_id is significant because it closes and reopens the session - it doesn't just change the ID but works like a session_write_close() + session_start(). The question as to what session_start+session_name should do is still relevant, but @tony's original code subtly (and perhaps accidentally) did make use of the renamed session. So there's that to consider. It hasn't changed my opinion though. Previous Comments: ------------------------------------------------------------------------ [2018-05-25 20:34:37] requinix@php.net > Do I understand the change here? Yes. Before it returned the name (and didn't change), now it returns false. > Also, curious, is the following also affected in PHP 7.2? I assume not: Correct. The warning and false only apply when a name argument is passed. So that's FOUR different opinions on the behavior of session_start() + session_name($new): 1. It should change the active session name and return the old one; the fact that 7.2 warns and returns false is thus moot. PHP has never done this but the rationale is that it should because the docs supposedly say it should. Unknown what would happen if headers had been sent, or how it would manage both the old and new session data. BC with 7.2 but not <7.2. 2. It should change the session name (literally the session.name setting), which would affect the next session and not the current one, and return the old name. This is <7.2's behavior. 3. It should not change the session name but it should return the "old" (still current) one. As such it should warn that the name couldn't be changed. This is a compromise between 2 and 4. Is BC. 4. It should fail (ie, warn and return false) because the session name cannot be changed. Rationale is that changing the name was presumably the intention behind calling the function with a name argument, and therefore that the <7.2 behavior was a bug which 7.2 has fixed. Not BC with <7.2 but does expose underlying bugs regarding multiple sessions. Note that the only real difference between 1 and 4 is whether it's possible to "rename" an active session. ------------------------------------------------------------------------ [2018-05-25 19:38:18] philip@php.net This discussion hurts my brain; can it start over and be simplified? Example: session_start(); $old = session_name('foo'); Do I understand the change here? In that: * Before 7.2: $old = the current session name * 7.2: $old = false; and E_WARNING generated * Before 7.2: session name does not change to 'foo' as it's after session_start() * 7.2: same, session name does not change to 'foo' Also, curious, is the following also affected in PHP 7.2? I assume not: session_start(); $old = session_name(); // current session name If I understand it correctly then there was a BC break. The change probably saw it was silly to allow session_name('foo') in situations that the session name could not change, which I understand, now should the return value have also changed without official deprecation first? Probably. Returning false now means that the session name could not be changed when before it simply returned the current session name. FWIW, and if I understand the change here, I'd leave the change at this point although it's not an easy decision. Using session_name('foo') means the programmer expects 'foo' as the new session name as otherwise the bogus code should fail. I can't think of another use case or reason it should not fail but maybe others can. ------------------------------------------------------------------------ [2018-05-24 13:45:04] tony at marston-home dot demon dot co dot uk > It did not change the session name, though. Yes it did. I stated using "session_name('newname')" as early as 2003 (and documented on my website in 2005). It kept on doing just that until it was broken in 7.2. > The documentation also clearly states: | Thus, you need to call session_name() for every request (and | before session_start() or session_register() are called). That means that you must follow a call to session_name() with a call to session_start() before the new name can take effect. It *DOES NOT* mean that you cannot call session_name('newname') while the current session is still active. > Since session_name('foo') does not update the name of the session > if it has already been started, it *must* not return the name of > the old session according to the documentation. The fact that "$oldname = session_name('newname')" did not work AS DOCUMENTED was a bug. The description for this function CLEARLY states the following: "session_name() returns the name of the current session. If name is given, session_name() will update the session name *AND* return the old session name. That clearly states that you should be able to both return the name of the current session *AND* set a new session name at the same time. It was *NEVER* necessary to close the current session before changing its name. ------------------------------------------------------------------------ [2018-05-24 13:01:21] cmb@php.net > I expect session_name() to do what it has been doing for the > past 15 years, that is to return the existing session name while > assigning a new one. It did not change the session name, though. > The documentation clearly states "Get and/or set the current > session name", and the "and/or" indicates that it should be able > to do both at the same time. The documentation also clearly states: | Thus, you need to call session_name() for every request (and | before session_start() or session_register() are called). And: | If name is given and function updates the session name, name of | the old session is returned. Since session_name('foo') does not update the name of the session if it has already been started, it *must* not return the name of the old session according to the documentation. ------------------------------------------------------------------------ [2018-05-23 11:44:09] notasockpuppet at atotallyrealdomain dot com I am HORRIFIED to find that a change was made that was not personally signed off by Toby. I will not be using PHP any more, this is the final straw. I can cope with the weird names and inconsistent APIs and segfaults and projects possessed by demonic forces, but I WILL NOT support a community that does not respect such wise people as Tiny. ------------------------------------------------------------------------ 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=76358 -- Edit this bug report at https://bugs.php.net/bug.php?id=76358&edit=1