用户一段时间不活动后 JavaScript 被禁用
我为我们公司的用户构建了一个内部应用程序。用户不活动后不会出现超时,我们也不希望出现超时。用户抱怨说,在闲置一段时间(例如 30 分钟)后,如果再次开始使用该网络应用程序,它就会开始表现得很奇怪。按钮不起作用,组合框不会下拉,日期选择器坏了。在我看来,很明显 JavaScript 在用户不活动一段时间后就会被禁用。
有人遇到过这种行为吗?如果有,我该如何预防?
该 Web 应用程序是一个 ASP.NET MVC 3.0 应用程序,使用 Telerik MVC 扩展,其中包括编写一些客户端 Ajax。它在 Windows Server 2003 标准版上的 IIS 6.0 上运行。
I have built an internal application for our company's users. There is no timeout after user inactivity nor do we want one. Users are complaining that after a certain amount of time (like 30 minutes) of inactivity, the web app starts acting strange if the start to use it again. Buttons don't work, combo boxes will not drop down, datepickers are broke. It seems very clear to me that the Javascript is getting disabled after period of user inactivity.
Has anybody come across this behavior and if so, how do I prevent it?
The web app is an ASP.NET MVC 3.0 app, using the Telerik MVC Extensions, which includes writing some client side Ajax. It is running on IIS 6.0 on Windows Server 2003 Standard Edition.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
检查脚本是否设置了 TTL 值约为 30 分钟的 cookie。
Check if the script is setting any cookies with a ~30 minute TTL value.
我认为这与会话超时有关。由于用户丢失了自己的会话值,ajax 与服务器的集成将不会被服务器接受,从而导致用户认为站点停止工作。
根据描述,如果网站在 30 分钟后停止工作,并且用户使用刷新按钮完全重新加载页面,则用户将不得不重新登录,因为会话值丢失。
对此有几种解决方案。
您必须创建一个隐藏的 iframe,它每 10 分钟重新加载一次
或
将会话超时时间延长超过 30 分钟(1800 秒)
或
定期向服务器发送 ajax 请求以保持连接。
I think it is related to the session timeout. Since user lost its own session value, ajax integration with server will not be accepted by server, which in return user thinks the site stopped working.
Based on the description, if site stops working after 30 min, and user completely reloads the page with refresh button, the user would have to re-login again because the session value is lost.
There are several solutions to this.
You would have to create a hidden iframe which it reloads itself every 10 minutes
Or
Extends the session timeout time more than 30 minutes(1800 seconds)
Or
Periodically send ajax request to the server to keep the connection.
这可能是错误的——但有时内存泄漏可能会导致这种行为。我用gmail就遇到了这个问题。在后台运行的脚本可以做到这一点。您能确定发生这种情况时浏览器使用了多少内存吗?
This might be offbase- but sometimes there is a memory leak which can cause this kind of behavior. I run into this problem with gmail. Scripts running in the background can do it. Can you determine how much memory usage the browser is using when this happens?
首先,我尝试以给定的时间间隔触发一个事件,看看 JavaScript 是否真的开始滞后,或者是否像其他人建议的那样出现会话超时。
将此功能添加到文档正文中的某处:
打开控制台,并在使页面处于非活动状态一段时间后进行监视。如果它继续无限期地每 15 秒触发一次,则 javascript 并未被禁用,也不太可能是您的 javascript 代码出现问题。那时,我会开始调查这是否可能是会话问题。如果您确实注意到日志消息开始滞后(或停止),则说明您的 javascript 中某处存在内存泄漏。
First I'd try firing an event at a given interval to see whether javascript is actually starting to lag, or if it a session timeout as others are suggesting.
Add this function in the body of your document somewhere:
Open up your console, and monitor that after leaving the page inactive for a while. If it continues to fire every 15 seconds indefinitely, javascript isn't disabled, nor is it likely to be a problem with your javascript code. At that point, I'd start to look into whether it might be a session issue. If you do notice the log messages starting to lag (or stop) you've got a memory leak in your javascript somewhere.
JavaScript 并没有停止运行;您的会话在某处超时。您站点的动态组件向服务器发出的请求失败,因为它们的会话 cookie 不再有效;您需要找到最初设置会话的位置,并增加会话过期时间。
Javascript isn't stopping functioning; your session is timing out somewhere. The dynamic components of your site are failing in their requests to the servers because their session cookies are no longer valid; you need to find where the session is initially being set, and increase the session expiration time.
等一下。我刚刚让这些用户使用我的开发服务器测试了这一点。他们根本不存在这个问题。我发现我的开发服务器上有什么区别。我们正在考虑要求客户证书。我们将 IIS 中的客户端证书设置设置为“接受客户端证书”。这导致了很多奇怪的客户端行为,并且它取决于浏览器、操作系统组合。将其设置回“忽略客户端证书”,似乎完全消除了这个问题。
Wait a minute. I just had these users test this with my dev server. They don't have this problem at all. I found out what the difference was on my dev server. We were toying with requiring client certificates. We set the Client Certificates setting in IIS to "Accept Client Certificates". This caused a lot of weird client side behavior and it depended on brower, OS combinations. Setting this back to "Ignore client certificates", seems to have removed this problem entirely.