我没有遇到这个问题，到目前为止，但我看你似乎没有已经覆盖但两个可能的原因：

1. 您可以查看 setExpire（）除了setIdle（）在auth类的方法。



2. 有可能是同一台服务器上运行的其他基于PHP应用程序/脚本，使用同一个会话存储目录具有较低超时。按照的session.gc_maxlifetime文档：

   
     

   如果不同的脚本具有不同
     的session.gc_maxlifetime值，但
     共享相同的地方，用于存储
     会话数据，则与剧本
     最小值将是清洁
     数据。在这种情况下，使用该指令
     连同 session.save_path的。

   
   块引用>

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.

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.