views:

657

answers:

1

This issue has been driving me insane. On two separate projects (both of which use PEAR as libraries but are written on completely different custom frameworks) I am using PEAR Auth for authentication which uses the session.

After logging in, users are logged out within an hour or so of being idle. I don't have the exact time, but it's very short.

I have tried the following with no success. All attempts to extend the session to one day, just to nail the point home.

<?php
// Tried built-in methods to extend the idle time, called after Auth is initialised
$auth->setIdle( 86400 );

// Tried increasing the sesion timeout (before auth is called)
ini_set( 'session.gc_maxlifetime', 86400 );

// Tried increasing the cookie timeout (where the phpsession is held, before auth is called)
session_set_cookie_params( 86400 );

// Tried all of the above
?>

Has anyone else had this issue? If so, is it possible to extend the idle time?

I'm just about ready to sod PEAR and write my own cookie based auth class, but I don't really have the time.

+1  A: 

I did not encounter this issue so far, but I see two possible reasons that you do not seem to have covered yet:

  1. You could check the setExpire() method of the auth class in addition to setIdle().
  2. There might be other php based apps/scripts running on the same server, using the same session storage directory with a lower timeout. According to the session.gc_maxlifetime docs:

    If different scripts have different values of session.gc_maxlifetime but share the same place for storing the session data then the script with the minimum value will be cleaning the data. In this case, use this directive together with session.save_path.

Henrik Opel
Thanks! I'll give these a try and let you know how it goes.
scape279
Tried the setExpire() in addition to setIdle() as advised, but this doesn't seem to have made any difference.The server is a cloud server, so I'm not entirely sure how sessions are stored handled - there could well be interference from other scripts.Do you think using a different session.save_path for the web app in question would help?
scape279
Yes, you should definitely try it. If it's a cloud server, chances are high that there are more php apps running on it, so this could well be the culprit. If the path is unspecified, it defaults to '/tmp' on *nix servers, so setting it to something like '/tmp/[yourAppName]' (or better yet, '/tmp/[hash of yourAppName]') might solve your problem (at least it would rule out another possible reason ;)
Henrik Opel
Oh, and be aware that all the settings you tried so far work together, so you still need to set the PEAR values as well as the `gc_maxlifetime`.
Henrik Opel
And another one: Before changing the save path, you could check the current situation with `session_save_path()`. This would give you a hint if the server uses some non default directory already. If so, you should probably use a subdirectory in there.
Henrik Opel
Excellent! Changing session.save_path to a unique directory seems to have done the trick. Many thanks :)
scape279