Edit report at https://bugs.php.net/bug.php?id=76358&edit=1
ID: 76358
User updated by: tony at marston-home dot demon dot co dot uk
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:
When the documentation at http://uk1.php.net/manual/en/function.session-name.php
says "session_name() must be called before session_start() in order session to work
properly" it actually means that the new session name will not take effect until the next call
to session_start(). It will not change the name of any currently open session.
Previous Comments:
------------------------------------------------------------------------
[2018-05-29 10:34:32] tony at marston-home dot demon dot co dot uk
When the documentation says that session_name() should be called before session_start() it means
that the name change will not take effect until the next call to session_start(). The reason that I
call session_start() before the call to session_name() is that I want to access the $_SESSION array
for the current session so that I can copy it across to the new session. I actually want to have two
browser windows running different parts of my application at the same time, and this will only work
if each of the browser windows has its own session_id, and this requires each session to have its
own name.
I have been using these functions as documented since 2003 without any problems, so imagine my
horror when this well-established behaviour was suddenly changed WITHOUT ANY WARNING WHATSOEVER.
Breaks in BC should always be handled by following the correct procedures, and I'm afraid that
those procedures were completely ignored on this occasion.
It is perfectly valid to call session_name() while a session is active as it would otherwise be
unable to follow the documentation and return the name of the current session. The documentation
also states that this function can be used to both get *AND* set the session name at the same time,
which means that it has always been possible to change the session name while a session is active.
The new name will not take effect until the next call to session_start(), and it is *ONLY*
session_start() that will fail if a session is already active. Thus it is *ONLY* necessary to close
the current session before the 2nd call to session_start(), *NOT* the call to session_name().
The only bug with session_name() is that if you tried to both get *AND* set at the same time it
would actually do neither. In changing the documented behaviour of this function they failed to fix
a genuine bug and instead introduced an artificial one.
Note that session_name does NOT change any session cookies. That is done either by
session_regenerate_id() or session_start().
------------------------------------------------------------------------
[2018-05-29 09:53:41] a at b dot c dot de
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".
------------------------------------------------------------------------
[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 :)
------------------------------------------------------------------------
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