Hello, internals. I hope you all are well.
The documentation page for the session_regenerate_id1 function has
the following warning:
Warning
Currently, session_regenerate_id does not handle an unstable network
well, e.g. Mobile and WiFi network. Therefore, you may experience a
lost session by calling session_regenerate_id.
You should not destroy old session data immediately, but should use
destroy time-stamp and control access to old session ID. Otherwise,
concurrent access to page may result in inconsistent state, or you may
have lost session, or it may cause client(browser) side race condition
and may create many session ID needlessly. Immediate session data
deletion disables session hijack attack detection and prevention also.
Since the documentation states that this problem exists currently,
are there any plans to address it?
Thank you all in advance.
The documentation page for the
session_regenerate_id[1] function has
the following warning:Warning
Currently, session_regenerate_id does not handle an unstable network
well, e.g. Mobile and WiFi network.
...Since the documentation states that this problem exists currently,
are there any plans to address it?
The original version of that note [1] was added by the same author,
Yasuo Ohgaki, as a declined RFC [2], which aimed to add various
additional security functionality to PHP's session mechanism.
The RFC seems to have mostly been declined for trying to do too much,
and generally being too complex. Some parts of it were later
introduced separately, but it seems like this particular problem
wasn't revisited; the wording in the manual may be indicating that
Yasuo hoped to do so, but that was nearly 7 years ago.
The fundamental problem is that you can't guarantee that requests and
responses will happen exactly in order: a browser might send a second
request with the old ID before it receives the first response with the
new ID, so the idea is to add a short "grace period" where both IDs
are accepted. The barrier to getting this into PHP is that currently
PHP doesn't manage any content in the session - it generates session
IDs, and uses a pluggable persistence layer to store whatever the user
asks for. The rejected RFC proposed a reserved 'PHP_SESSION' array
inside the session to store the extra data, which on the face of it
isn't a terrible idea.
The standard cheeky open source reply therefore applies: if you think
you have a good implementation, feel free to contribute it; but
otherwise, look to a framework or library for a userland
implementation.
[1] https://github.com/php/doc-en/commit/56562880bd287b2d96519932044f911db518f2cf
[2] https://wiki.php.net/rfc/precise_session_management
Regards,
Rowan Tommins
[IMSoP]