Bug #76358 [Com]: Cannot change session name when session is active

Edit report at https://bugs.php.net/bug.php?id=76358&edit=1 ID: 76358 Comment by: a at b dot c dot de Reported by: tony at marston-home dot demon dot co dot uk Summary: Cannot change session name when session is active Status: Open Type: Bug Package: Session related Operating System: Windows 10 PHP Version: 7.2.5 Block user comment: N Private report: N New Comment: I have to admit; the semantics of the session_* functions are a bit murky to me. The only time I've found a use for session_name was to avoid a collision with a third-party package's use of PHPSESSID. I've never tried changing the name of an active session until this. Thing is, the documentation has always said that session_name() should be used BEFORE session_start(). Right in the function's description. "The session name is reset to the default value stored in session.name at request startup time. Thus, you need to call session_name() for every request (and before session_start() or session_register() are called). " The currently top-voted user comment, made by Hongliang Qiang fourteen years ago recognises that "...the session already started thus cannot be altered before the session_name() function--wherever it is in the script--is executed, same reason session_name needs to be called before session_start() as documented.". As far as I can see, trying to change the session name of an active session would - if it worked at all - would just cause _two_ Set-Cookie headers (one sent when the session started and one when the name changed) with the _same_ session ID value (hence both referring to the same session). The client would send both cookies back. I suppose regenerating the ID sends a _third_ Set-Cookie header, with a repeated name and the new value, but because the name's repeated there's explicitly no guarantee which (if either) value would be retained by the client. But, like I said, I find the semantics of the documented functions a bit cloudy. In the synopsis, for example, the phrase "current session name" could be parsed as "current-session name" or "current session-name". Documentation and behaviour suggests it should be the latter, because when it's called there shouldn't be a "current-session". Previous Comments: ------------------------------------------------------------------------ [2018-05-25 23:14:37] tony at marston-home dot demon dot co dot uk The function was changed to ignore the documented behaviour when it should have been changed to IMPLEMENT the documented behaviour. There is no logical reason to prevent the session name being changed while a current session is active. The fact that the new name cannot be used until the next call to session_start() is neither here nor there. ------------------------------------------------------------------------ [2018-05-25 23:10:15] tony at marston-home dot demon dot co dot uk There are two uses for session_name: 1) Return the current session name. 2) Assign a new session name. According to the documentation for the last 20 years it should also be possible to do both, which implies that it is not necessary to close the current session before using session_name('newname'). The fact that it does not do that is a bug. Few people spotted it is simply because they generally want to do one or the other, but rarely both at the same time. The reason that I want to change the session name is that when I have a particular part of my enterprise application open in one browser window I sometimes want to open a second browser window (or even a third) so that I can look at another part of my application at the same time. In Internet Explorer the Ctrl+K key combination will produce a clone of the current tab in another tab. However, at this point they are both using the same session name and id, so I have a hyperlink on the screen which executes the following code: session_start(); // this uses the old name and id ... do stuff session_name('newname'); session_regenerate_id(); session_write_close(); … restart script so that it uses the new session name and old, … but leaves the old one alone. Since PHP 4 all the way up to 7.1 this worked as advertised. Since 7.2 the call to session_name('newname') does NOT change the session name because somebody decided that it was not proper to do so while a session was already active. That opinion differed from the documentation, therefore that opinion was wrong. The fact that I can workaround this newly generated BC break by moving a single line of code is not the issue. The important fact is that this BC break happened WITHOUT WARNING and without ever being documented or appearing in any change logs. I think that it is a sad day when somebody can decide that the documented behaviour of a 20 year old function does not fit it with their beliefs, so they go ahead and change it without following the correct procedure - raise RFC, discuss it on the internals list, then put it to a vote. If any Tom, Dick or Harry can now insert a BC break at any time without warning, then that sounds the death knell for the language. It will become so unreliable it will become unusable for anyone who expects to build an application with a long life. ------------------------------------------------------------------------ [2018-05-25 22:03:14] philip@php.net Just in case, I did not suggest opinion #3 to do today but rather think it was "probably" a good option to consider for 7.2.0. But I didn't realize #2 was pre-7.2 behavior and thought all it did was return the current session name. Anyhow, this old-timer will stop cluttering this bug with uneducated words now :) ------------------------------------------------------------------------ [2018-05-25 21:09:02] requinix@php.net 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. ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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