在 web.config 中,我将 sessionState 中的超时设置为 20 分钟。根据 MSDN,此超时指定会话在被放弃之前可以空闲的分钟数。在 IIS 7 中,DefaultWebSite->会话状态 - > Cookie 设置 - >超时自动填充 web.config 中设置的超时值,在我的情况下为 20 分钟。此外,应用程序池 - > DefaultAppPool->高级设置 - > idleTimeout,我将其设置为 10 分钟。
然后我做了两个测试:第一次测试:我在 3:45pm 登录我的网络应用程序,闲置 10 分钟。在 3:55pm,我试图使用我的应用程序,我被踢了出去。我认为 idleTimeout 正在发挥作用。
第二次测试:我在 4:00pm 登录了我的网络应用程序,在 4:05pm,4:10pm,4:15pm 和 4:20pm 上玩应用程序。我预计会在 4:20pm 被踢出局。但我不是。我认为 IIS 7 中的会话状态超时(20 分钟)是在 Web 代理向用户提出挑战之前用户会话可以处于活动状态的最长时间。显然,从这个测试,它不是。任何人都可以向我解释一下吗?另外,我如何设置上述情况的超时?
1 回答
Session time-out 是一个滑动 time-out,每次访问服务器时,都会为用户重置为配置的值。
如果在这段时间内没有向您的应用程序发出请求,应用程序空闲 time-out 将启动。
因此通常的情况是:
如果用户 A 在 12:22 之后返回该站点,他们将有一个全新的会话,并且您之前存储的任何值都将丢失。
确保会话在应用程序重新启动时持续存在的唯一方法是配置 SessionState 服务或 SQL 会话状态,并确保您配置 machine.key以便每次服务器重新启动时都不是 AutoGenerated。
如果您使用标准 ASP.NET 机制进行身份验证,那么 ASP.NET 将向每个用户发出两个 cookie:
身份验证令牌:由认证 time-out设置控制,允许用户自动登录到您的站点,如果 cookie 未过期,可以修复或滑动,默认为 30 分钟,这意味着他们的身份验证令牌可以应对比他们的会话更长的“闲置”时期。
会话令牌:由 Session Time-out 设置控制,允许您的应用程序在访问的生命周期内存储和访问 per-user 值。
这两个 cookie 都使用 MachineKey 加密 - 因此,如果您的应用程序回收并生成新密钥,则这些令牌都不能被解密,要求用户登录并创建新会话。
回应评论:
20 分钟会话 time-out 与您使用
Session.Add(string, object)
方法放置在用户会话对象(HttpSessionState)中的项目相关。那要看。如果您正确配置 machine.key,身份验证令牌仍然有效,如果您的会话不再是“InProc”,这些也会在应用程序重新启动后继续存在并且仍然可读 - 请参阅上面的说明。