即使会话文件完好无损,我的 PHP 会话也会超时

发布于 2024-09-16 14:15:43 字数 426 浏览 5 评论 0原文

我已经阅读了数十种解决方案,并尝试了几乎每一种,但我的会话很快就超时了。我使用的是 Debian 安装,并将 /usr/lib/php5/maxlifetime 中的 max 变量设置为 86400。我还在 php.ini 中设置了 session.gc_maxlifetime = 86400。我已将会话 cookie 的有效期设置为一小时,每次重新加载页面时,我都会将其更新一小时。我尝试设置 ini_set("session.gc_maxlifetime", "86400");在我的前端控制器中。然而没有任何帮助。如果我登录我的网站并等待大约 20 分钟,下次单击页面上的链接时我将被注销。会话 cookie 仍然有效,并且 /var/lib/php5 中的会话文件仍然存在。我就是不明白。我还应该提到,我在系统上使用 Parallels PLESK,它对标准 Debian 安装进行了大量修改,但我不认为这就是问题所在。有人吗?

I have read dozens of solutions to this and tried almost every one of them, but my sessions times out quickly anyway. I'm using a Debian installation and have set max variable in /usr/lib/php5/maxlifetime to 86400. I've also set session.gc_maxlifetime = 86400 in php.ini. I've made the session cookie valid for one hour and every time I reload the page I update it with another hour. I have tried setting ini_set("session.gc_maxlifetime", "86400"); in my front controller. However nothing helps. If I login to my site and wait about 20 minutes the next time I click a link on the page I will be logged out. The session cookie is still valid and the session file in /var/lib/php5 still exists. I just don't get it. I should also mention that I use Parallels PLESK on the system and it has made a lot of modifications to the standard Debian install, but I don't think that's the problem. Anyone?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

够钟 2024-09-23 14:15:43

完全有可能加载了多个 .ini,并且您对会话进行更改的 .ini 被链中稍后加载的 .ini 覆盖。转储会话验证/登录代码所在的 phpinfo() 并查看会话设置是什么。部分输出还将是已加载的 .ini 文件的列表。

It's entirely possible there's more than one .ini being loaded and where the one you made your session changes to is being overridden by one loaded later in the chain. Dump out a phpinfo() where your session validation/login code are and see what the session settings are. Part of the output will also be a list of the .ini files that were loaded.

沙沙粒小 2024-09-23 14:15:43

.htaccess 是否有可能与其他内容冲突?并且您确定没有在代码或某些自定义 php.ini 中的其他位置设置此值吗?
每当我遇到这样的问题时,我终于意识到我忘记了一个地方。

Is it possible you have something a .htaccess conflicting with everything else? And are you sure you do not set this somewhere else in your code or some custom php.ini?
Everytime I have such problems I finally realise I forgot ONE place.

み格子的夏天 2024-09-23 14:15:43

php -i | 是否grep session.cookie_lifetime (在控制台)或 phpinfo() (在脚本中)验证您对 cookie 生命周期参数的更改?

如果您使用 Firefox,请尝试安装 Web 开发人员工具栏和 Firebug 以检查 cookie 和网络活动。当我调查会话 cookie 的哈希值发生变化的问题时,这对我来说是一个非常有用的组合。

也有可能在代码或库中的某个地方调用 session_set_cookie_params() 这使您的预期行为超载。您可以使用上述任一扩展来检查 cookie,以验证其过期情况。

Does php -i | grep session.cookie_lifetime (at console) or phpinfo() (in script) verify your change to the cookie lifetime parameter?

If you use Firefox, try installing the Web Developer Toolbar and Firebug to inspect the cookies and network activity. This is a very useful combination for me when investigating issues where the hash value of a session cookie changes.

It's also possible that somewhere in your code or libraries you have a call to session_set_cookie_params() that's overloading your expected behavior. You can inspect cookies with either of the extensions above to verify their expiration.

私野 2024-09-23 14:15:43

我不确定这是否有帮助,但请确保您同时使用 ob_start() 和 ob_start() 。会话开始();

ob_start();
session_start();

这很奇怪,解决方案可能是使用 cookie 实现“记住我”功能。我知道会话可能非常变化无常,如果您在另一个计算机上登录,或者在同一计算机上但不同的浏览器上登录,则 cookie 可能会被破坏。

另外,会话真的被破坏了吗?或者正在生成一个新会话?

I'm not sure if this will help, but make sure you're using both ob_start() & session_start();

ob_start();
session_start();

That's weird, a solution could be to implement a "Remember Me" feature with cookie. I know sessions can be very fickle, if you log-in on another comp, or the same comp but different browser, the cookie could be destroyed.

Also is the session really getting destroyed? Or is a new session being generated?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文