Question

假设我在web.config

中使用了类似的东西

<authentication mode="Forms">
<forms

      loginUrl ="~/HomeLogin.aspx"
      cookieless= "AutoDetect" 
      slidingExpiration="true"
      timeout="10"
       protection ="All"

/>
</authentication>

如果slidingExpiration设置为true（默认值），则每次FormsAuthenticationModule对用户进行身份验证时，都会更新故障单的到期日期。如果设置为false，则不会在每个请求上更新到期时间，从而导致故障单到期时确切地超过首次创建故障单时的超时分钟数。

注意： 存储在身份验证票证中的到期日期是绝对日期和时间值，如2008年8月2日上午11:34。此外，日期和时间是相对于Web服务器的本地时间。此设计决策可能会在夏令时（DST）周围产生一些有趣的副作用，即美国的时钟向前移动一小时（假设Web服务器托管在观察夏令时的区域）。考虑一下在DST开始时（即凌晨2:00）附近有30分钟到期的ASP.NET网站会发生什么。想象一下，访客于2008年3月11日凌晨1点55分登录该网站。这将生成一张表单身份验证票证，该票证将于2008年3月11日凌晨2:25（将来30分钟）到期。但是，一旦凌晨2点左右，由于夏令时，时钟会跳到凌晨3点。当用户在登录后6分钟（上午3:01）加载新页面时，FormsAuthenticationModule会注意到故障单已过期并将用户重定向到登录页面。

这是一个可能导致问题的实例。任何人都可以指出这种方法的任何缺点。我有兴趣了解它。

由于

Answer 1

FormsAuthentication使用UTC时间进行计算。您需要转到源代码（或Reflector）才能看到这一点，所有使用UTC-date的属性/方法都是内部的。

Cookie根据RFC 6265, section 5.1.1使用UTC时间作为过期日期。

“让解析后的cookie日期为其日期，月份，年，小时，分钟和秒（以UTC为单位）是日期 - 价值，月份价值，年份价值，小时价值，分钟值和第二个值。“

这意味着DST不会成为问题。

只要用户处于活动状态，滑动到期将允许无限期登录。这意味着第三方可以获取cookie路由并作为用户进行同等无限期的身份验证。

绝对过期不会停止，但需要定期重新验证，限制第三方可以使用cookie的时间窗口。

Answer 2

表单身份验证协议始终以UTC格式。

使用表单身份验证“slidingExpiration”相关的缺点

2 个答案: