Req #78054 [NEW]: session_decode should optionally return data rather than populate $_SESSION
| From: | phpbugs dot ooglek at 0sg dot net | Date: | Thu, 23 May 2019 04:07:36 +0000 |
| Subject: | Req #78054 [NEW]: session_decode should optionally return data rather than populate $_SESSION | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-220955@lists.php.net to get a copy of this message | ||
From: phpbugs dot ooglek at 0sg dot net
Operating system:
PHP version: 7.3.5
Package: Session related
Bug Type: Feature/Change Request
Bug description:session_decode should optionally return data rather than populate $_SESSION
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().
--
Edit bug report at https://bugs.php.net/bug.php?id=78054&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=78054&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=78054&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=78054&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=78054&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=78054&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=78054&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=78054&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=78054&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=78054&r=support
Expected behavior: https://bugs.php.net/fix.php?id=78054&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=78054&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=78054&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=78054&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=78054&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=78054&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=78054&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=78054&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=78054&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=78054&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=78054&r=mysqlcfg