php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #78054 session_decode should optionally return data rather than populate $_SESSION
Submitted: 2019-05-23 04:07 UTC Modified: 2021-07-30 14:17 UTC
From: phpbugs dot ooglek at 0sg dot net Assigned:
Status: Open Package: Session related
PHP Version: 7.3.5 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: phpbugs dot ooglek at 0sg dot net
New email:
PHP Version: OS:

 

 [2019-05-23 04:07 UTC] phpbugs dot ooglek at 0sg dot net
Description:
------------
Storing sessions in a Database is great for high-availability and sharing sessions across multiple web hosts. 

However, when one wants to deeply inspect the session data, such as an administrator or an Admin Tool that displays all the information about a current session, there seems to be two options.

1. For a short time, hijack $_SESSION

$tmp = session_encode();
session_decode($data);
$sessdata = $_SESSION;
session_decode($tmp); 

This replaces the current users' $_SESSION with the decoded data until one has time to restore it. If it doesn't restore successfully, you've got a bad situation.

2. Write your own unserialize functions. Wikimedia had to. Yuck. ADODB had one that preg_match'd on a Pipe character, but that broke if the value contained pipes. Someone else wrote a recursive one that worked pretty well and took advantage of the fact that unserialize() will stop unserializing at the next pipe in the string. OK but is that guaranteed to keep working forever?

If session_decode() would be able to return the decoded session (FALSE on failure as it does now, but success gives you the array/object), then nobody would have to write or maintain code that may or may not be exactly how session_decode() works.

Additionally if people start writing their own handlers, yikes. 

session_decode_return() or something similar would be fine too if you don't want to overload session_decode().


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-05-23 04:09 UTC] phpbugs dot ooglek at 0sg dot net
The three supported options for session.serialize_handler are 

php
php_binary
php_serialize (5.5.4+ only)

If someone writes their own handler, they now have to expose some method for someone else to decode their serialized session data.

session_decode() already knows how to handle this, no special case handling necessary.
 [2021-07-30 14:17 UTC] cmb@php.net
While I agree that it is suboptimal that session_decode() doesn't
simply return the decoded data, I don't think this will change
until someone submits a PR[1].

[1] <https://github.com/php/php-src/pulls>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 27 06:01:30 2024 UTC