From: [EMAIL PROTECTED] Operating system: Win XP PHP version: 4.2.1 PHP Bug Type: Session related Bug description: $_SESSION support may be inconsistent
Situation: Working with PHP4's session functions, I've encountered a problem on a local install (PHP 4.2.1, Apache2 (could also be an Apache2 bug), Windows XP, MySQL 3.23.49) that does not exist with the same script on a Linux/Apache 1.x/PHP 4.1.2 installation with the same PHP configurations. It would appear to be a bug in PHP's handling of $_SESSION in certain situations, but it's possible something else is going on that has escaped my attention. Symptoms: Using $_SESSION as outlined in the PHP docs with session_start() and no session_register() for register_globals being turned off, logging into the script in question creates a session but does not write the actual session data (key/value pairs) to it. Just a session id and expiry. This happens with either the standard /tmp/ flatfile or MySQL (session_set_save_handler) session logging. Solution: The only thing I found that could get it to correctly write the session data is to replace $_SESSION with $HTTP_SESSION_VARS throughout the script. That doesn't make sense, since 4.2.1 is obviously more recent than the 4.1.0 release which added $_SESSION... Ok, one step down. More surprising is that on logging out, unset'ing the session variables is not "writing" the empty session to the database. It should leave the session id and expiry in place and wipe out the session data, but all remains untouched. The session variables themselves are being emptied (tested by echoing them to the browser), but that's it. unset($HTTP_SESSION_VARS['sess_id']); unset($HTTP_SESSION_VARS['sess_name']); or: unset($HTTP_SESSION_VARS); Neither of those approaches worked from the standpoint of changing the session (as opposed to the variables' values). The thing that I found which sort of works is to set the session variables to NULL instead of unset'ing them: $HTTP_SESSION_VARS['sess_id'] = NULL; $HTTP_SESSION_VARS['sess_name'] = NULL; That didn't exactly empty the session, but it did make it invalid, with the following session data resulting: sess_id|N;sess_name|N; as opposed to the valid format which might look like: sess_id|s:1:"1";sess_name|s:5:"admin"; For a username of "admin" and a id of "1". I guess that's better than nothing, but it isn't overly assuring that unset() doesn't work... I did find mention of what appears to be the same problem in another bug tracker report: http://bugs.php.net/bug.php?id=15923 Making the above outlined changes did not adversely affect the non-local installation of the script, so it appears to be a good balance if you need something to work on multiple server environments. A couple of other bug reports that are loosely related by may or may not be the same are: http://bugs.php.net/bug.php?id=17069 http://bugs.php.net/bug.php?id=16890 Thanks, Dan Kaplan -- Edit bug report at http://bugs.php.net/?id=17512&edit=1 -- Fixed in CVS: http://bugs.php.net/fix.php?id=17512&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=17512&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=17512&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=17512&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=17512&r=support Expected behavior: http://bugs.php.net/fix.php?id=17512&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=17512&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=17512&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=17512&r=globals
