Edit report at http://bugs.php.net/bug.php?id=48673&edit=1

 ID:                 48673
 Updated by:         [email protected]
 Reported by:        joey at blouzar dot com
 Summary:            Make session serialization functions available to
                     php
-Status:             Open
+Status:             Bogus
 Type:               Feature/Change Request
-Package:            Feature/Change Request
+Package:            Session related
 Operating System:   All
 PHP Version:        5.2.10
 Block user comment: N
 Private report:     N

 New Comment:

There's already unserialize() and serialize() functions, so what are you
really requesting for..?


Previous Comments:
------------------------------------------------------------------------
[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 http://bugs.php.net/bug.php?id=48673&edit=1

Reply via email to