Bug #17512 Updated: $_SESSION support may be inconsistent

ID: 17512 Updated by: info@virogo.com Reported By: dan@abledesign.com Status: Open Bug Type: Session related Operating System: Win XP PHP Version: 4.2.1 New Comment: Same in NT4 / IIS4. No consistent registering possible... It writes 2 ses_3237234748 bla bla, one of them is 0 bytes. The other contains the sessiondata. But when trying to read out the sessiondata thru $_SESSION, it seems to be empty. Previous Comments: ------------------------------------------------------------------------ [2002-05-30 18:47:09] dan@abledesign.com > Given your response to my sample tells > me that sessions do work properly. The point of the report was not to say that sessions do not work (they obviously do, as shown by the fix I outlined above), rather that certain aspects of them do not appear to be properly supported in some environments. > I suspect a bug in the code you use or > the way you expect sessions to work. Ok, here is what I've got, in simplified form (no need for you to read through the extraneous hidden fields, MySQL queries, and what not): -- login form: print <<<HERE <form action="$PHP_SELF" method="GET"> <input type="text" name="username" value="" size="20" maxlength="15"> <input type="password" name="password" value="" size="20" maxlength="15"> <input type="submit" value="Submit"> </form> HERE; -- login processing script: (This is actually routed through an index page that starts the session, includes config and library files, page formatting, and includes the requested file, which is the login processing form in this case.) <?php session_start(); if (isset($_SESSION["sess_id"])) { // remove any existing sessions for this user unset($_SESSION["sess_id"]); unset($_SESSION["sess_name"]); } $sql = "SELECT * FROM Users WHERE Username='". addslashes($_GET["username"]) ."' AND Password='". addslashes($_GET["password"]) ."'"; $result = mysql_query($sql); if (!$result || (mysql_num_rows($result) < 1)) { // redirect to failed login prompt } else { $row = mysql_fetch_array($result); $_SESSION["sess_id"] = $row["ID"]; $_SESSION["sess_name"] = $_GET["username"]; // redirect to main page after setting the session echo "<script language=\"JavaScript\">window.location='index.php'</script>"; } ?> As explained above, that does not work on all servers. Doing the exact same thing but with $HTTP_SESSION_VARS in place of $_SESSION and not using unset() on the session variables does however work. Surely I'm not misunderstanding how sessions should work in this example? Thanks, Dan ------------------------------------------------------------------------ [2002-05-30 18:06:03] mfischer@php.net 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. ------------------------------------------------------------------------ [2002-05-30 15:54:38] n.ponsich@netcourrier.com sorry for the mistake my post is for the "Bug #17441 session register" ------------------------------------------------------------------------ [2002-05-30 15:36:07] n.ponsich@netcourrier.com 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] dan@abledesign.com 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 ------------------------------------------------------------------------ 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/17512 -- Edit this bug report at http://bugs.php.net/?id=17512&edit=1