使用通配符映射时 ASP.NET 表单身份验证超时的最佳解决方法是什么？
我的团队正在开发一个蹩脚的旧网站，大部分页面仍然是 ASP 经典。 不过，我们最近迁移到使用 ASP.NET 和通配符映射的表单身份验证。 除了一件事之外，一切都出奇地顺利：登录的用户超时得太快。 查看日志后，人们似乎在 20 分钟后超时（这是由于不活动而指定的超时）。
因此，我们的假设是 ASP 经典页面不会触发表单身份验证框架中重置不活动计时器的任何机制。 我已经用谷歌搜索过，甚至阅读了大古的通配符映射帖子，但仍然找不到其他遇到此问题的人。 那么，1）你见过这个问题吗？ 2）最好的解决方法是什么？ （除了在后台加载愚蠢的 .NET 页面的每个卡顿 ASP 页面中手动放置隐藏框架之外）
更新：slidingExpiration 设置为 true
另外：我们不能使用永久会话，因为我们需要应用程序在 20 分钟不活动后超时。 另外，这个糟糕的网站是这样编写的，因此界面通常存储在页面中。 没有一段简单的界面代码可以让我将 JavaScript 放入其中。 我们尝试将一些 js 放入包含文件中，该文件被大约 80% 的页面调用，但它导致了文件下载缓冲区的一些深奥问题，因此我们可能不得不尝试不同的策略。 谢谢。
My team is working on a crappy old website and most of the pages are still ASP classic. However, we've recently migrated to forms authentication using ASP.NET and wildcard mapping. Everything works surprisingly well except for one thing: logged in users are timing out too quickly. After looking in the logs it appears people are timing out exactly after 20 minutes (which is the specified timeout due to inactivity).
So, our hypothesis is that the ASP classic pages are not tripping whatever mechanism in the forms authentication framework that resets the inactivity timer. I've googled around and even read the wildcard mapping post by the Great Gu but still can't find anyone else who is having this problem. So, 1) Have you ever seen this problem? and 2) What's the best workaround? (other than manually placing a hidden frame in every janky ASP page that loads a dumb .NET page in the background)
Update: slidingExpiration is set to true
Also: We can't use perpetual sessions because we need the application to time out after 20 minutes of inactivity. Also, this terrible site was written so that the interface is usually stored in the page. There's no simple piece of interface code I could slip the JavaScript into. We tried to put some js into an include file that was called by about 80% of our pages but it's caused some esoteric problems with file download buffers so we may have to try a different tack. Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
创建一个永久会话。
本质上，您最终会在母版页或导航用户控件（无论您使用什么来实现一致的导航）中发出一些 JavaScript 和图像标记。 此 JavaScript 在某个时间间隔将图像标记的源更改为 http 处理程序端点（某些 .aspx、.ashx），该端点返回 1x1 像素清晰的 gif 作为图像的响应。 持续的请求可确保空闲页面使会话保持活动状态。
只要浏览器窗口打开您的页面，您的 ASP.NET 会话就永远不会超时。
JavaScript 通常会在请求中附加一个随机数，以便浏览器不会缓存该请求。
此处提供了不错的演练。
Create a perpetual session.
Essentially you end up emitting some JavaScript and an image tag in your master page or navigation users controls (whatever you're using for consistent navigation). This JavaScript on some interval changes the source of the image tag to an http handler endpoint (some .aspx, .ashx) which returns a 1x1 pix clear gif as a response for the image. The constant request ensures that idle pages will keep the session alive.
As long as a browser window is open to your page your ASP.NET session will never time out.
Often the JavaScript will tack on a random number to the request so that the browser doesn't cache the request.
A decent walkthrough is available here.
我假设您已经手动创建了 cookie，在这种情况下，代码中的超时值可能会覆盖配置中的超时值。
首先，如果可能的话（也可能不是）不要手动创建 cookie，它不仅可以让您避免这个头痛，还可以避免其他许多麻烦。
如果您必须手动创建 cookie，请确保您使用的超时实际上是读取您在配置文件中设置的超时值，并且滑动过期设置为 true（正如您所说的那样）。
也就是说，当手动创建 cookie 时，我们仍然偶尔会遇到奇怪的超时问题。 在我工作的地方，我们实施了一个解决方案，允许自动创建 cookie，并且超时不再是问题； 然而，它确实产生了其他问题，我们被迫切换回来。
I am assuming that you have manually created the cookie, in which case your timeout value in code is probably overriding your timeout value in the configuration.
First, if possible (which it probably isn't) don't create the cookie manually, it will save you from not only this headache but dozens of others.
If you must manually create the cookie, make sure that the timeout you are using is actually reading the timeout value that you have set in the configuration file and that sliding expiration is set to true (which you have said it was).
That said, we still have ocassional strange timeout problems when the cookies are manually created. Where I work we implemented a solution which allowed the cookies to be created automatically and timeouts were no longer a problem; however, it did create other issues and we were forced to switch back.