ID: 17512
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Win XP
PHP Version: 4.2.1
New Comment:
Given your response to my sample tells me that sessions do work
properly. I suspect a bug in the code you use or the way you expect
sessions to work.
Try to cut it down to a simple, self-contained example what you're
trying to archive.
Previous Comments:
------------------------------------------------------------------------
[2002-05-30 15:54:38] [EMAIL PROTECTED]
sorry for the mistake my post is for the "Bug #17441 session register"
------------------------------------------------------------------------
[2002-05-30 15:36:07] [EMAIL PROTECTED]
Y have the same trouble with win XP and easyPHP 1.6 even if i upgarde
PHP to 4.2.1
------------------------------------------------------------------------
[2002-05-30 12:01:04] [EMAIL PROTECTED]
Thanks for the quick reply.
I do have Win2k, but no server setup on that computer, so I can't
easily test that piece.
I tried out your sample script and it seems to work fine.
> Note: you've to refresh after a registration!
Do you mean just for that sample script (which did require refreshing)
or in general? With the problem I outlined above, my script normally
redirects to a main page after successful login (and subsequent session
updating). To isolate the problem, I had removed the redirect/refresh
to see if the session was actually being written on the login page,
which it wasn't. So, I don't think refreshing is the culprit there,
since that same approach works fine on non-local installs (including
lots of other servers it's been used on).
Thanks,
Dan
------------------------------------------------------------------------
[2002-05-30 06:40:02] [EMAIL PROTECTED]
Can you test the same no W2K ?
Can't reproduce this on W2k, try this simple script and see if it
works:
--8<---
<?
session_start();
if (isset($_REQUEST['key']) && isset($_REQUEST['value'])) {
$GLOBALS[$_REQUEST['key']] = $_REQUEST['value'];
session_register($_REQUEST['key']);
echo "Registered {$_REQUEST['key']}.<br />\n";
}
if (count($_SESSION) > 0) {
echo "The following session variables are registered:<br />\n";
foreach ($_SESSION as $key => $value) {
echo "$key => $value<br />\n";
}
echo "<br />\n";
}
?>
<hr />
<form action="<?=$_SERVER['PHP_SELF']?>" method="post">
Key: <input name="key"/><br />
Value: <input name="value"><br />
<input type="submit" />
</form>
--8<---
Note: you've to refresh after a registration!
------------------------------------------------------------------------
[2002-05-29 14:41:23] [EMAIL PROTECTED]
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 this bug report at http://bugs.php.net/?id=17512&edit=1
