在运行时覆盖 wicket 中的会话超时
如何在运行时覆盖会话超时间隔。基本上在登录时，用户可以选择是否想在特定时间登录（例如（7））。
因此，一旦用户通过身份验证，我所做的就是在会话中设置最大 inactiveInterval 。
WebRequest 请求 = (WebRequest) WebRequestCycle.get().getRequest(); request.getHttpServletRequest().getSession().setMaxInactiveInterval(HOURS * 60);
但这似乎不起作用。该时间之后用户仍然登录。
谢谢！
普拉蒂克
How can I override session timeout interval during the runtime. Basically at the time of login, user is given an option if wants to be logged in for specific hours say(7).
So what I did once user is authenticated , set the max inactiveInterval at the session.
WebRequest request = (WebRequest)
WebRequestCycle.get().getRequest();
request.getHttpServletRequest().getSession().setMaxInactiveInterval(HOURS * 60);
but this doesn't seems to work . User is still logged on after that time.
Thanks!
Pratik
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我相信该方法的名称不言而喻。 setMaxInactiveInterval() 肯定会在最后一次响应后等待一段时间，然后会话才会过期，因此您的会话在最后一次响应后会保持活动状态 7 小时？
至于答案，您可能正在查看页面内或会话内的某些内容，以检查预定义的时间以查看其是否比预定义的时间段长。
希望这有帮助。
I believe the name of the method would speak for itself. setMaxInactiveInterval() would surely wait for a period of time after the last response before expiring the session, so your session would have been kept alive for 7 hours after the last response?
As for the answer, you're probably looking at something either within the page or within the session that checks against a pre-defined time to see if its longer than the pre-defined period.
Hope this helps.
该方法需要几秒钟而不是几分钟，但这并不能解释这种现象。
也许您可以验证浏览器上 cookie 中的会话 ID 如果发生变化？我曾经遇到过这样的情况：会话处理非常“强大”，创建了一个全新的会话，除非浏览器页面收到会话已终止的通知，否则它只会创建一个新会话。现在我承认那是在我的 Perl 时代，并且容器管理会话极不可能发生这种情况
The method takes seconds instead of minutes, but that does not explain the phenomenon.
Maybe you can verify the session id in the cookie on your browser if it changes? I have had situation where the session handling was so "robust" a brand new session was created that unless the browser pages were notified that the session was terminated, it would simply create a new one. Now I admit that was back in my perl days and that this is extremely unlikely to happen with container manages sessions