Hi,

I've just submitted a case to sugar regarding the tracker tables incorrectly recording active session times if sessions time out rather than having the user log off. Below is the text from the case submission, but if anyone has any suggestions, it'd be very welcome.

Cheers:

We have issues with the way the tracker (and so tracker reports) records user sessions. Specifically, it does not properly record the time active when a user's session expires and they do not close the browser.

This happened in 5.1.0 pro and is still evident in 6.2.0 pro. We implemented a simple 'hack' to get around this in 5.1.0 but the same hack causes incorrect user warnings in 6.2.0.

What happens:

When a user logs on, the session details are stored in the tracker_sessions table and related events are stored in the tracker table. The tracker_sessions record's end time is updated with each event - and the time elapsed between the session start field and this end field is used in reports.

When a user logs off, the session is destroyed. This works fine.

To replicate the issue, if the browser is left open and unused, the session expires (php settings - and the session file is deleted from the server). However, if the user then subsequently uses sugar from the same browser window, the session id is retained within the browser connection - so when the browser is redirected to "module=Users&action=Login", this session id is processed and the old defunct record in the tracker_sessions table is updated with the end time set to the time the Login page was opened. THEN the session variables are properly killed off and a new session is started. So if someone logs on at 5.55pm; does 5 minutes work before going home without logging off; comes back in the next days and is forced to log on again, they show they have been working with an open session for 24 hours 5 minutes.

It's easy to identify by adding the code;

Code:
var_dump($_COOKIE[session_name()]);
right at the start of modules/Users/Login.php


We got around this under 5.1.0 by - in the same location - adding the code:

Code:
//SWC fix to clear sessions (like Logout.php) after a PHP session timeout
foreach($_SESSION as $key => $val) {
$_SESSION[$key] = ''; // cannot just overwrite session data, causes segfaults in some versions of PHP
}
session_destroy();
if(isset($_COOKIE[session_name()])) {
setcookie(session_name(), '', time()-42000, '/');
}
//SWC end
But if we do the same under 6.2.0, then every time you go to the login page, you are presented with the session expiry warning, even if it didn't. This was the only custom code, so the Login code for 6.2.0 that exhibits this is still vanilla.

For info, I've confirmed that the server is correctly killing off the session, and the process inactive sessions scheduled job is running too.

To replicate quickly - rather than waiting for the session to expire - you can just go to the appropriate session directory on the web server (eg. /var/lib/php5) and deleted the related session file after identifying the session id from the tracker_sessions table.

Thanks,
Steve