Edit report at https://bugs.php.net/bug.php?id=76358&edit=1
ID: 76358
Updated by: yohgaki@php.net
Reported by: tony at marston-home dot demon dot co dot uk
Summary: Cannot change session name when session is active
Status: Assigned
Type: Bug
Package: Session related
Operating System: Windows 10
PHP Version: 7.2.5
Assigned To: yohgaki
Block user comment: N
Private report: N
New Comment:
Session name MUST be specified before starting session. Otherwise it will NOT take effect since
output is already started. (i.e. HTTP header is already sent)
With output buffering, output may delay and it is possible change buffered HTTP header and outputs
(Note: transid requires to rewrite buffered output. This isn't simple)
In addition we have user defined and 3rd party session save handlers which can use session name for
some reasons to achieve better session management.
Simply restoring old behavior allows hard to find find bug in PHP session because it cannot working
correctly.
Older PHP session was allowing too many bogus operations which will not work at all, and works only
for specific condition. This is one of them.
Previous Comments:
------------------------------------------------------------------------
[2021-03-19 22:47:58] cmb@php.net
I guess reverting to the old behavior is the way to go, but
apparently that would require an RFC now, so likely it won't
happen. SCNR.
------------------------------------------------------------------------
[2019-10-15 19:15:14] 1978 dot jl at gmail dot com
+1, very problematic when we must migrate from 7.1 to 7.3
------------------------------------------------------------------------
[2018-12-04 19:12:02] john at zerocrates dot org
Related To: Bug #77238
------------------------------------------------------------------------
[2018-06-13 15:19:35] tony at marston-home dot demon dot co dot uk
These are the five code samples that Yasuo sent me as "proof" of the broken behaviour with
the session functions which his fix supposedly cures. Below each example is my response which shows
that the problem actually lies with the code that calls those functions and not the functions
themselves.
Example #1 - Wrong write and/or crash>
<?php
session_start();
session_name('new_name');
session_commit(); // Save handler can write session data to wrong storage.
There is no such thing as "wrong" storage in this case as session_commit() does NOT
reference $session_name when calling the write() method in the session handler, it uses $session_id.
This code does not change $session_id so the session data is put back in the same place from where
it was read.
Example #2 - Wrong name returned
<?php
session_start();
session_name('new_name');
// somewhere in the code
$my_current_session_name = session_name(); // Wrong session name. session_start() uses old one.
// This behavior can cause bug when user is distributing session storage accesses by session name.
There are a number of glaring mistakes here:
- Changing the value of session.name does not take effect until the next call to session_start().
When a session is started the value of session.name is provided in the $session_name argument in the
open() method in the session handler.
- No method or function has ever been provided which will return the value of $session_name which
was used in the call to open().
- If the value of session.name is changed while a session is active that change is not communicated
with the session handler and does not affect the session handler in any way as all read() and
write() operations are performed using the $session_id.
- If the session name is used to change the value in $save_path then it should be done in the open()
method in the session handler where both $save_path and $session_name are provided as arguments. If
these values need to be used in other methods then they should be stored as class properties and
accessed using $this->varname.
Example #3 - Wrong write and/or crash. Pattern 2.
<?php
session_start();
session_name('new_name');
// somewhere in the code
session_regenerate_id();
// Save handler can write session data to wrong storage.
// In worst cases, PHP crashes
?>
Bad usage again. session_regenerate_id() will regenerate a new id for the CURRENT session, but this
will be linked with the value of session.name which was available when the current session was
started. The value 'new_name' will not take effect until the next call to session_start(),
just as the manual says.
Example #4 - Wrong write and/or crash. Pattern 3.
<?php
session_start();
session_name('new_name');
session_write(); // Save handler can write session data to wrong storage.
// In worst cases, PHP crashes
?>
This is the same as Example #1.
Example #5 - Wrong write and/or crash. Pattern 4. + Bogus session_name() call.
<?php
session_start();
session_name('new_name');
// Save handler can write session data to wrong storage at the end of script execution.
// In worst cases, PHP crashes
// In addition, user wouldn't notice bogus session_name() call if there is no error.
?>
This is a duplicate of #1 and #4. The session is started with a particular $session_id, and as that
$session_id is never changed any updates to that session data will be written back using the same
$session_id. A change in $session_name does not change the $session_id. The $session_name and
$session_id are different entities which are accessed using different functions. They are only
brought together when the cookie is accessed, which is either by session_start() or
session_regenerate_id(). This code does nothing to cause 'new_name' to be written out as a
cookie, therefore it simply disappears.
------------------------------------------------------------------------
[2018-06-06 09:50:10] requinix@php.net
Related To: Bug #76413
------------------------------------------------------------------------
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