From: anachronist+php at gmail dot com
Operating system: RedHat Linux
PHP version: 4.4.2
PHP Bug Type: Session related
Bug description: All web clients behind NAT firewall/router get the same
$_SESSION id
Description:
------------
After several days of experimenting, I must conclude that this is a php
bug concerning $_SESSION. I hope I'm wrong.
My local network has a single, static IP address with a NAT
firewall/router, which connects several computers to my DSL service. I'm
sitting in front of these computers, testing my web site that's hosted
remotely at my ISP's server. My web site requires all users to log in. I
try to log in as different users on different machines.
The server uses the same session ID for ALL machines on my network. The
session id appears to be generated solely from the IP address (which is
the IP address of my NAT), and not from any unique identifying data from
my browser clients.
Reproduce code:
---------------
All of my php scripts, without exception, start out like this:
session_save_path("/home/mydomain/public_html/lists");
session_name('login_settings');
session_start();
Then each php script checks what type of user is logged on the web site by
calling this function:
function isLoggedOn()
{
if (isset($_SESSION['superuser']))
return 'superuser';
if (isset($_SESSION['customer']))
return 'customer';
if (isset($_SESSION['user']))
return 'user';
return NULL; // unregistered or not logged in
}
Upon receiving the return value from isLoggedOn(), the script behaves
exactly the way it should depending on what type of user is logged in.
The value of $_SESSION['user'], $_SESSION['customer'], and
$_SESSION['superuser'] is the user's ID in the MySQL table for that user
type; the value is set by a login.php script.
I have three login.php scripts: for normal users, customers, and
superuser. Each login.php script queries the appropriate database for
user ID and password, and sets some $_SESSION values, and ensures that any
$_SESSION values for other user types are unset. Here, for example, is what
happens with $_SESSION when a normal user logs in:
$userid = $sql->GetValue('id');
if ($userid) {
$_SESSION['user'] = $userid;
if (isset($_SESSION['customer']))
unset($_SESSION['customer']);
if (isset($_SESSION['superuser']))
unset($_SESSION['superuser']);
header("Location: http://www.example.com/userindex.php";);
} else header("Location: http://www.example.com/login.php?error=1";)
Logging off deletes all $_SESSION data, deletes the session cookie, and
finally calls session_destroy(). I have verified that the following
excerpt from my logout.php works fine:
$CookieInfo = session_get_cookie_params();
$_SESSION = array(); // unset all session values
setcookie(session_name(), '', time()-3600, $CookieInfo['path']);
unset($_COOKIE[session_name()]);
session_destroy();
If the problem I describe isn't a bug, what is going on?
Expected result:
----------------
Each web client accessing my site should correspond to a different session
on the web server -- even if they're all behind a NAT router that has a
single IP address. That is, any modification of $_SESSION resulting from
the actions of one client shouldn't affect other clients, because all
should have unique sessions.
Actual result:
--------------
What actually happens:
Whenever another client on my local network logs in to the web site, the
same session is used. A new login event might change the value for
$_SESSION['user'], or maybe add a new value $_SESSION['superuser'] --
resulting in all clients acting in accordance with the most recent login
(or logout). If one client on my network logs out, then ALL clients
behave as if logged out when attempting further activity on the web site.
It doesn't seem to matter if the session cookie is deleted or not; what
seems to matter instead is what the server stores as session data; when
one user logs off, the session data is deleted and then all web browsers
on my network act like they're logged off.
--
Edit bug report at http://bugs.php.net/?id=38260&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38260&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38260&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38260&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38260&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38260&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38260&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=38260&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=38260&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38260&r=support
Expected behavior: http://bugs.php.net/fix.php?id=38260&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38260&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38260&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38260&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38260&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38260&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=38260&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38260&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38260&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38260&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=38260&r=mysqlcfg
