You are hereSugarCRM; Problem With Browser Showing A Random User as Logged In, After A Different User Logs Out

SugarCRM; Problem With Browser Showing A Random User as Logged In, After A Different User Logs Out


By steve - Posted on 08 August 2008

I've been developing with SugarCRM since Fall of 2006, so I've gotten pretty familiar with the internals. One system I've had in production since February 2008 had been having strange, intermittent problems with users logging off, then the browser immediately showing a different user as logged in. This was particularly evident with users that use Windows CE's browser (we have warehouse barcode scanner guns running Windows CE and laser scanning barcodes using the browser).

This became an even bigger problem when, for security reasons, we shortened the "automatic log off" period in php.ini so that the user gets kicked out after 5 minutes of inactivity.

It took quite awhile to figure out what was happening...

As background, PHP has functions that handle session management and store session information in the user's cookie. SugarCRM uses these functions to handle session management in Logout.php, Login.php, and index.php. Functions used include setcookie(), session_destroy(), session_id(), and session_start(). Variables used include $_SESSION[] and $_COOKIE[].

The specific problem I was having was that a user would be in SugarCRM, they would logout, then a different user's page (all logged in and everything) would suddenly appear. That user hadn't been logged into the device at all. Clearing the cache and clearing cookies on the device didn't help. We also forced a static IP address in DHCP for the device and set a host name, but neither made a difference.

The first indication of what was really going wrong was when I was monitoring the sugarcrm.log and while the logged off user was processing index.php (after processing logout.php) the user having the problem logged "****Starting Application for session deleted". This meant that a new session wasn't being created and that php was processing a session called 'deleted' instead of the long hex string that should have been there.

I found in /var/lib/php5 that there was a session file called sess_deleted. After a little googling, I found some developers that had run into a similar situation. The sess_deleted file was assumed to be the legitimate session file.

I think the reason for this is that the browser was sending back "deleted" for the session ID, after being told by php to clear the cookie. This only seemed to be a problem with Windows CE's browser, but might be a problem with other or older browsers.

The solution was to add a session_regenerate_id(true) statement in the code that detected a session ID (around about line 220 in my index.php), but only if the session_id was equal to "deleted":

if(isset($_REQUEST['PHPSESSID'])) {
	$GLOBALS['log']->debug("****Starting Application for  session "
          . $_REQUEST['PHPSESSID'] . " session_name of " . session_name());
	// My new code is here...
	if (session_id() == "deleted") {
		$GLOBALS['log']->debug("****  session deleted, regenerating");
		session_regenerate_id(true);
	} // end new code
} else {
	$GLOBALS['log']->debug("****Starting Application for new session");
}

After doing this, sess_deleted no longer appeared in the /var/lib/php5 folder, the "regenerating" note shows up in sugarcrm.log quite frequently, and we haven't had problems since!

Tags


Sponsors



Apple Store


Apple Online Store











TigerDirect


Windows Vista Memory








Shop4Tech





Official PayPal Seal