与使用表单身份验证相关的缺点 "slidingExpiration"

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 服务器托管在遵守夏令时的区域设置中）。考虑一下，对于一个 ASP.NET 网站，在 DST 开始时间（即凌晨 2：00）附近过期 30 分钟会发生什么情况。想象一下，访问者在 2008 年 3 月 11 日凌晨 1：55 登录该网站。这将生成一个表单身份验证票证，该票证将于 2008 年 3 月 11 日凌晨 2：25（将来 30 分钟）过期。但是，一旦凌晨 2：00 滚动，时钟就会跳到凌晨 3：00，因为 DST。当用户在登录六分钟后（凌晨 3：01）加载新页面时，FormsAuthenticationModule 会注意到票证已过期，并将用户重定向到登录页。

这是可能会导致问题的情况。谁能指出这种方法的任何此类缺点。我很想知道它。

谢谢

Answer 1

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

Cookie 根据 RFC 6265 第 5.1.1 节使用到期日期的 UTC 时间。

"让解析的 cookie 日期是其月中的某天、月、年、小时、分钟和秒（UTC 格式）是月份中的某天值、月值、年值、小时值、分钟值和第二值。

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

只要用户处于活动状态，滑动过期将允许无限期登录。这意味着第三方可以在途中抓取cookie，并在同样不确定的时间内以用户身份进行身份验证。

绝对过期不会阻止这种情况，但需要定期重新进行身份验证，从而限制第三方可以使用 cookie 的时间窗口。

Answer 2

表单身份验证处理始终采用 UTC。