Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120766
MIME-Version: 1.0
References: <CAEwRQKb1_WQBKR8GJJVrPL3o3QLo=JXNemFMovGY0yFyLdUk-g@mail.gmail.com>
In-Reply-To: <CAEwRQKb1_WQBKR8GJJVrPL3o3QLo=JXNemFMovGY0yFyLdUk-g@mail.gmail.com>
Date: Fri, 7 Jul 2023 18:13:28 +0100
Message-ID: <CALKiJKptpNF4YZkhQ0kFsJRacpBmvEvXPc7OvG8iXFDnnJ3GMg@mail.gmail.com>
To: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] session_regenerate_id concurrency problems
From: rowan.collins@gmail.com (Rowan Tommins)

On 7 July 2023 01:32:39 BST, Vinicius Dias <carlosv775@gmail.com> wrote:
>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]