Closed leegarner closed 3 years ago
This change seems to fix the issue, need further testing to rule out unintended consequences.
--- a/private/system/lib-sessions.php
+++ b/private/system/lib-sessions.php
@@ -140,11 +140,10 @@ function SESS_sessionCheck()
if ( $userid == 0 ) {
$row = $db->conn->fetchAssoc(
"SELECT md5_sess_id, start_time FROM `{$_TABLES['sessions']}` WHERE "
- . "(remote_ip = ?) AND (start_time > ?) AND (uid = 1)",
- array($request_ip,$mintime),
- array(Database::STRING,Database::INTEGER)
+ . "(md5_sess_id = ?) AND (remote_ip = ?) AND (start_time > ?) AND (uid = 1)",
+ array($sessid, $request_ip,$mintime),
+ array(Database::STRING,Database::STRING,Database::INTEGER)
);
-
if ($row) {
$sessid = $row['md5_sess_id'];
if ( $row['start_time'] + 60 < time() ) {
Looks like this has been implemented in the develop (2.0) branch.
If multiple clients access glFusion from behind a NAT firewall (not a proxy or CDN), the session handling in lib-session doesn't work correctly for Anonymous users since
$_SERVER['REAL_ADDR']
is the same due to no forwarding headers.The query to get the session ID in SESS_sessionCheck() selects from the gl_sessions table based on remote_ip, start_time and uid which returns the same session as another client but different than the session ID saved in the cookie, resulting in a new session being created and invalidating the other client's session.
A possibility might be to use the cookie's session ID in the query and trust that value as long as it exists in the database as md5_sess_id.