views:

53

answers:

3

This is really bugging me. Has been for years. No matter what I do with core.php or php.ini, my logins timeout after about an hour - usually. Some deployments of identical code and configuration timeout after a respectable amount of time.

This is what I have at the moment on one site - timed out after about an hour:

session.gc_divisor  1000
session.gc_maxlifetime  86400
session.gc_probability  1

Configure::write('Session.timeout', '28800');
Configure::write('Session.checkAgent', false);
Configure::write('Security.level', 'medium');

And another - lasted all night:

session.gc_divisor  100
session.gc_maxlifetime  14400
session.gc_probability  0

Configure::write('Session.timeout', '315360000');
Configure::write('Session.checkAgent', false);
Configure::write('Security.level', 'medium');

Now, before you get excited and say, "Well, the answer is there in the Session.timeout value", let me tell you that this site usually times out after about twenty minutes!

+2  A: 

I don't think this is a Cake-specific thing; I've seen it when no frameworks were involved - it's most likely an issue with your PHP config settings.

Things you should check/do to fix the issue:

  1. Specify a dedicated path to store sessions in session.save_path if you don't already do so. Don't store them in /tmp - some other process may come along and wipe them for you.

  2. Make sure (and I mean really sure) that the value of session.gc_maxlifetime is what you think it is (86400 if you want your logins to time out after 24 hrs of inactivity, etc.). Same with session.gc_divisor and session.gc_probability. Even though the PHP Manual specifies that session settings can be set on any level, depending on the dodginess of your PHP build (they're all slightly buggy in their subtle ways :)) you may find they don't actually take effect unless set in the global php.ini file as opposed to in the code, .htaccess, etc. Just output them in your actual app to be sure they are applied.

  3. Also, depending on your environment, check if the PHP CLI build is using the same php.ini file as the default PHP build - if the CLI build is using another config file and you have cron jobs using the CLI build, the cron job scripts could be invoking the session cleanup procedure.

Rowlf
1. This is something I'll try - I've seen elsewhere that shared hosting can be a bit naughty like that.2. The values in my original Q are output by phpinfo.3. Presumably 1. would avoid this?
Leo
2. phpinfo() gives you values applicable to the virtual host you're running - what about the actual app that's using Cake? Not likely, but something could be overwriting your php.ini settings.3. No, it's a separate issue. Run `php --ini` on the command line and compare it with phpinfo() output to make the CLI version uses the same config file as the one you're modifying.
Rowlf
2. I'm pretty sure nothing is overwriting the php.ini settings.3. I don't have any cron jobs, but the CLI is using a different ini.
Leo
A: 

Hello Leo,

Maybe adjusting

session.gc_maxlifetime = 1440

where 1440 seconds = 24 minutes, could be relevant.

Kind regards, Benjamin.

benjamin
Thanks, but as you can see in my Q, I've already tinkered with those values.
Leo
A: 

Somewhere I read that on shared hosting, other applications can reset the session by clearing the php-defined session directory. This was alluded to by Rowlf in his answer.

CakePHP offers the option to configure the way sessions are handled. In core.php I changed this to 'cake' (by default it is 'php'):

/**
 * The preferred session handling method. Valid values:
 *
 * 'php'            Uses settings defined in your php.ini.
 * 'cake'       Saves session files in CakePHP's /tmp directory.
 * 'database'   Uses CakePHP's database sessions.
 */
Configure::write('Session.save', 'cake');

I also ensured that the session timeout and the corresponding php.ini values are the same:

/**
 * Session time out time (in seconds).
 * Actual value depends on 'Security.level' setting.
 */
Configure::write('Session.timeout', '86400');

So far, the system hasn't logged out.

Leo
Now, about a week later, it still seems to be working well. Colleagues also report that it now behaves as expected.
Leo