#23689 [Opn->Bgs]: serializing - deserializing session data doesn't work

ID: 23689 Updated by: derick@php.net Reported By: marty at excudo dot net -Status: Open +Status: Bogus Bug Type: Session related Operating System: linux PHP Version: 4.3.1 New Comment: > From the manual: > "You can also create a session variable by simply setting > the appropriate member of the $_SESSION" It says *member* *of* the *$_SESSION* not $_SESSION itself. You can not re-assign to $_SESSION, or any other super global without it losing it's special functions. It's not a bug, leave the status set to Bogus. Previous Comments: ------------------------------------------------------------------------ [2003-05-19 03:35:47] marty at excudo dot net Well, i could agree on this part about the $_POST and $_GET superglobals. In fact i think doing that is a little dirty myself. But i do not agree about the $_SESSION superglobal! I am simply doing what i would be doing with session_register() and session_unregister() in PHP < 4.1! Why is this suddenly not allowed? From the manual: "You can also create a session variable by simply setting the appropriate member of the $_SESSION" "Note: If $_SESSION is used, use unset() to unregister a session variable." That's all i am doing! Could you please enlighten me why this is suddenly bogus? (i promise i won't touch the $_POST and $_GET anymore, i simply want an answer on the $_SESSION one) (p.s. i changed the status back the open - i wasn't sure if this is necessary to get another comment from you) ------------------------------------------------------------------------ [2003-05-19 01:56:31] derick@php.net Superglobals don't work like this. You can not overwrite them by assigning them. Not a bug -> bogus ------------------------------------------------------------------------ [2003-05-18 20:11:36] marty at excudo dot net I'm reopening the bug. I just did what i suggested in my last post. i created those temporary arrays, thereby not serializing the $_SESSION data directly. This should, in my humble opion, by allowed. Since this: $_SESSION['key'] = "value"; and this: unset($_SESSION['key']); is both valid code, i don't see how this =>=>=>=>: $temp_session = $_SESSION; $serialized_session = serialize($temp_session); <=<=<=<=: unset($_SESSION); $temp_session = unserialize($serialized_session); $_SESSION = $temp_session; is different? However, the later produces the initial bug i reported (if i use it in my script) ------------------------------------------------------------------------ [2003-05-18 18:51:33] marty at excudo dot net I'm not sure whether you choose your words badly, or not, but Serializing is not the problem. Serializing the $_SESSION data works fine (as my example shows). The problem is filling $_SESSION again by UNserializing the serialized representation. Also, nowhere in the manual it is pointed out that the (un)serialize function can't be used with these superglobals. (and if this is really true it should do so!!) Is there really a reason why this should not be done / doesn't work, or is it a bug after all and this the answer i get because no one at php is gonna fix it? Ok, sorry, i don't mean to flame, but this is a very unsatisfactory answer - i spent a lot of time on this function and also a lot of time creating a proper bug-report! Just answer this question for me then: If i create 3 temporary arrays, by filling them with the data from $_GET, $_POST and $_SESSION -> i serialize Them and store them in my db. And then when i want to restore them i unset() $_SESSION again (unsetting $_GET and $_POST won't be necessart at this point); i unserialize the data from the database, store them in 3 temporary arrays and then assign those arrays again to $_SESSION, $_GET and $_POST ($_SESSION = $temporary_array;) That should, in theory, work then, right? ------------------------------------------------------------------------ [2003-05-18 17:42:05] sniper@php.net Don't serialize $_SESSION...or any other of those superglobal variables either. Not bug. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/23689 -- Edit this bug report at http://bugs.php.net/?id=23689&edit=1