Req #78054 [NEW]: session_decode should optionally return data rather than populate $_SESSION

From: 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

« previous php.bugs (#220955) next »