Error on login: "You have been logged out because your session has expired."

[Frank_Con]

Hi all,

I am having some problems with a sugarCE installation and hope someone can help.

I have a server with several SugarCRM's installed on it, they all share a single php directory and work with no problems. I have just received a copy of a 6.1.0 SugarCRM CE to upgrade to 6.2.1 but receive "You have been logged out because your session has expired." when trying to login.

This error is being shown on the login screen when entering correct details, I never get inside the sugar install.

I must stress that the other Sugar installs are using the same PHP files so I can not see this being a PHP setting issue. I have also stripped the config.php / config_override.php files to be identical to a clean 6.1.0 install (excluding server details) so I do not believe it to be a setting in these files causing the problem.

Facts:
Permissions are set to full control on the directory.
Windows Server 2008 R2
MSSQL 2005 Express
FastCGI / PHP 5.3.6
This is the same setup as the other installs which are working perfectly.

Has anyone got any suggestions?

Thank you

[robertbmirth]

I can't remember the exact fix, but if you're looking for a place to start, this is usually an apache and/or file permissions issue. Sorry I can't be more specific, its been a while since I've run into it on the forums, but its around.

[Angel]

Check the session_dir setting in your config files. Make sure it is a directory that exists on the current server and is accessible to IIS user.

[Frank_Con]

I spent a lot of time trying to debug this problem and ended up working backwards through the code base until I found the solution.

As expected this was a bit more complicated than permissions and config settings so I will try to explain my findings in case anyone else experiences the same problem. However, I do believe this runs back to 6.1 issues which have been fixed previously.

Background.

It seems at some point in time the way queries were stored internally changed, an array which stores the various queries was created (or modified) so that an index id was passed around rather than a string.

At the same time, the handling of the authentication procedure seemed to have a condition to check for empty strings being sent, this also failed if it was passed a zero.

Typically speaking by the time the process is initiated several queries will be stored in the cache array so that the index being passed will be higher than zero. However in my instance the cache array wasn't operating correctly and as such the index ID was still at zero when the authentication process was called.

This meant the legacy condition checking for a zero was conflicting with a non incremented cache array ID which was blocking the login.

The reasoning behind the lack of incrementation of the cache array was due to the IIS caching configuration which had been introduced on the server. The issue didn't exist on their live server due to the caching configuration being corrupted and not running at all.

Note. I noticed in the 6.2 release this whole system was modified and the issue no longer existed.
---

Once this problem was found, reconfiguring the server caching and running the upgrade procedure to 6.2.1 worked perfectly.

[toledo12]

Just installed 6.2.4 and get this. I have read what you wrote.... Any "idiots" guide to how to fix this?

Cheers

t