网站后台,延长session失效时间从24分钟到4小时

网站后台,延长session失效时间从24分钟到4小时

在博客上写文章最后提交的那一刻网站后台，有时会出现“认证错误”的信息，提示你重新登录，无法“返回”到你的页面刚刚编辑。结果，刚才的辛苦都白费了，好痛！

原因是因为php session有一个GC功能，就是Garbage Collector。当 GC 启动时，它会清除那些“超时”的会话。它的工作原理是这样的：

用户访问并登录网站。这时候后台会调用session_start尝试生成session（如果已经有session，就相当于一个有效的session请求）

对于每一个有效的会话请求（Request），apache的php模块都会根据会话相关的全局变量gc_probability/gc_divisor =>计算启动GC的概率，并用这个概率来决定是否启动GC这个请求。 GC 应该开始。例如 session.gc_probability 的默认值为 1，session.gc_divisor 的默认值为 100网站后台，启动“垃圾收集器”的概率为 1%，也就是说每 100 个请求中，就有可能清理结束一个过期的会话

如果GC启动，GC会扫描当前会话所在路径（session.save_path）下的所有会话文件，根据另一个全局变量session.gc_maxlifetime（“当前时间”和”” session文件的”atime or mtime”之差大于gc_maxlifetime: expired)，删除这些过期的session

如果你在长时间没有任何交互的情况下启动会话（例如，不断输入、不提交或保存为草稿），那么你保存在后台的会话文件将没有机会被修改或访问，在gc_maxlifetime的时间（默认1440秒=24分钟）之后，可能会因为失效而被清理，如果稍后再次提交，会因为会话失败而报错

可以看出gc_maxlifetime设置为24分钟，对于写一些文章是不够的。这也是一个原因，另外，linux上session.save_path的默认路径是/tmp，很少有程序会修改这个设置。如果此服务器上有多个虚拟主机，那么 /tmp 目录中将存储许多具有不同 session_name 的会话文件。不好的是php的GC不区分session所有权网站后台,延长session失效时间从24分钟到4小时网站后台,延长session失效时间从24分钟到4小时，它会根据得到的gc_maxlifetime来清理这个目录下所有过期的session文件。

根据上面的分析，解决方案是：在.htaccess文件中添加语句将session.gc_maxlifetime的本地值扩展为14400（4小时），后台设置session.save_path为/tmp/utblog , 这样utblog的session文件就不会被其他网站干扰了，而且4小时的过期时间我觉得反正应该够用了。

经过测试，一切如我所愿。

另外，如果你直接更改/etc/php.ini，你当然可以。如果你没有权限修改php.ini或者apache的conf文件，并且禁止.htaccess，那么直接修改plog sessionmanager.class.php文件，在session_start前加上ini_alter(“session.gc_maxlifetime”, 1440<@ line0)还有。plog结构不错，只有这个地方调用了session_start，所以这里是唯一需要修改的地方。