在使用窗体身份验证“slidingExpiration”

相关联的缺点

假设我用这样的事情在web.config在使用窗体身份验证“slidingExpiration”

<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指出该票证已过期并将用户重定向到登录页面。

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

谢谢

来源

2012-04-12 freebird

您是否在问'slidingExpiration =“true”'的缺点或缺点？ – Abel 2012-04-12 10:50:00

@Abel当它为真 – freebird 2012-04-12 10:50:57

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

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

“让解析-cookie的日期是其当天的日日，月，年，小时，分钟和秒（在UTC）是某一天的月 - 值，月份值，年份值，小时值，分钟值和第二个值。“

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

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

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

来源

2012-04-12 11:08:41 sisve

为cookie劫持+1，好点。 – Abel 2012-04-12 12:26:28

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

来源

2013-08-05 07:14:33 Fooker

在使用窗体身份验证“slidingExpiration”

回答

相关问题