Edit report at https://bugs.php.net/bug.php?id=48673&edit=1
ID: 48673
Comment by: not-bogus at example dot com
Reported by: joey at blouzar dot com
Summary: Make session serialization functions available to
php
Status: Bogus
Type: Feature/Change Request
Package: Session related
Operating System: All
PHP Version: 5.2.10
Block user comment: N
Private report: N
New Comment:
This is a reasonable Feature Request. Why was it marked Bogus?
There is a whole slew of poor userland implementations in the PHP Manual. Being
able to reliable and safely decode serialized session data into an array
instead of into $_SESSION would make a lot of that poor code obsolete.
Previous Comments:
------------------------------------------------------------------------
[2011-01-02 05:21:04] joey at blouzar dot com
There are serialize/unserialize functions but they are
not compatible with PHP's default internal
serialization mechanism for sessions. I found many
better ways to achieve what I was trying to achieve
over a year ago but still think that the
session_encode and session_decode functions are
undesirably inflexible.
Here is an example why unserialize is not an a
realistic option with default PHP sessions:
# php -d "suhosin.session.encrypt=Off" session.php
Started session.
$_SESSION set to:
array(2) {
["a"]=>
int(1)
["b"]=>
int(2)
}
Closed session with write.
$_SESSION from serialize(): a:2:{s:1:"a";i:1;s:1:"b";i:2;}
$_SESSION from session file: a|i:1;b|i:2;
Attempting to unserialize session:
PHP Notice: unserialize(): Error at offset 0 of 12 bytes in session.php on
line
16
bool(false)
As we can see with session_handler set to php
what is produced is not 100% compatible with
the user serialisation functions. Other save
handlers can be set that do not share this
problem. There is no elegant way to use
serialize() in sessions that I am aware
without avoiding the PHP API provided for
session handling entirely.
Additionally, other filters may be in place
that would presumably be handled by
session_encode and session_decode but not
so easily by other means. Using custom
handlers allows the user to easily add
additional features such as compression,
encryption, and locking, but for
serialisation leaves little choice.
There are many ways around this and if you look at
http://php.net/manual/en/function.session-decode.php
you can see some real such kludges. If you don't want
to improve this that is understandable as obviously
it really is a very minor annoyance but I don't think
it is a bogus request :)
------------------------------------------------------------------------
[2011-01-02 02:30:50] [email protected]
There's already unserialize() and serialize() functions, so what are you really
requesting for..?
------------------------------------------------------------------------
[2009-06-24 11:11:26] joey at blouzar dot com
Description:
------------
The default serialisation scheme in php for session data is different than that
provides by php to the scripting environment. While on one scale it uses the
"userland" serialisation format overall it uses its own scheme that is very
hard to parse safely without writing a grammer.
There are existing functions that can serialise/deserialise session data using
the session scheme. However they are not flexible and can lead to risky code.
These functions are session_encode and session_decode. Their short-fall is that
they do not let the programmer choose where the data is deserialised/serialised
to or from. It always works with the $_SESSION global.
I submit a simple proposal to provide functions to serialise session data with
the same level of flexibility as the conventional serialisation functions.
An example of how the functions might appear (pseudo):
String|false session_serialize(Array* $in_assoc_array);
Array|false session_unserialize(String $serialized_data);
Or:
Boolean session_unserialize(String $serialized_data,Array* $out_assoc_data);
Of course another suggestion would be to use normal php serialisation on the
whole array rather than just it's members.
Thanks.
Reproduce code:
---------------
$result=$db->query('SELECT * FROM sessions WHERE
user='.$recipient);
$oldsession=session_encode();
while($session=$result->object())
{
$_SESSION=array();
session_decode($session->data);
++$_SESSION['menu']['inbox'];
$db->query('UPDATE sessions SET
data="'.$db->escape(session_encode()).'" WHERE
id="'.$db->escape($session->id).'"');
}
$_SESSION=array();
session_decode($oldsession);
Expected result:
----------------
As this is a feature request the code does exactly what is expected. The code
here is an example of the current system. Actually result contains the
downfalls of this.
Quick redundant note. This code may not be the best example (one might argue
that the counter should be stored elsewhere) but was the closest one to hand.
Actual result:
--------------
While it works fine it is somewhat risky. Loading the data to the current
session is beyond requirement. If an inexperienced developer were to alter this
code it could result in a mistake such as breaking the restoration of the
session that causes the user submitting the post to adopt the session of the
recipient. It is also somewhat inefficient as the existing session data should
not really need to be backed up and restored. I did try just copying the global
to another variable and back again but this somehow resulted in the user being
logged in as the recipient. I decided to play it safe after that and
serialize/deserialize it instead.
With a custom save handler it could be possible to implement a security switch.
However, this is far from elegant.
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=48673&edit=1
