Ability to session_decode() in a stateless manner?

php.internals

Deleu

2 years ago
Hi! Earlier today I was working on a small tool to invalidate PHP Sessions in a legacy system. I quickly found out about the `session_decode()` function, but unfortunately this function requires an active session and it is completely stateful, which means when I try to decode a specific session data, I end up overriding the existing session. I also tried combining `ob_start()` with `session_id()`, `session_start()`, `session_destroy()` and `ob_end_clean()`, but this would still cause some weird behaviors by sending two PHP Cookies through the Response Headers. In an ideal world, I would override `session.serialize_handler` and be done with it, but that would require invalidating every existing session and some non-trivial changes in the 20 year old codebase. To my original question, is there any exposed API that would give userland access to the session deserializer algorithm in a stateless manner? Something like `session_deserialize(string $data): array;`, preferably in a way that 1) doesn't require or doesn't conflict with any existing session and 2) returns the session array without any side effects? If not, would this be something that requires an RFC? Are there any controversial thoughts around it? Thanks!
-- Marco Deleu

Robert Landers

2 years ago
On Wed, Nov 22, 2023 at 10:06 PM Deleu <deleugyn@gmail.com> wrote:
> > Hi! > > Earlier today I was working on a small tool to invalidate PHP Sessions in a > legacy system. I quickly found out about the `session_decode()` function, > but unfortunately this function requires an active session and it is > completely stateful, which means when I try to decode a specific session > data, I end up overriding the existing session. > > I also tried combining `ob_start()` with `session_id()`, `session_start()`, > `session_destroy()` and `ob_end_clean()`, but this would still cause some > weird behaviors by sending two PHP Cookies through the Response Headers. > > In an ideal world, I would override `session.serialize_handler` and be done > with it, but that would require invalidating every existing session and > some non-trivial changes in the 20 year old codebase. > > To my original question, is there any exposed API that would give userland > access to the session deserializer algorithm in a stateless manner? > Something like `session_deserialize(string $data): array;`, preferably in a > way that > 1) doesn't require or doesn't conflict with any existing session and > 2) returns the session array without any side effects? > > If not, would this be something that requires an RFC? Are there any > controversial thoughts around it? > > Thanks! > > -- > Marco Deleu
Hey Marco, I vaguely remember dealing with something like this about 10 years ago-ish. If I remember correctly, 1. copy the _SESSION var to a temp var 2. clear the _session var 3. decode the session 4. copy the _session var to an output array 5. clear the _session var 6. restore the original _session var Or something like that. I doubt that is immensely helpful, but maybe it is. Robert Landers Software Engineer Utrecht NL