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

Pri*_*tel 3 asp.net forms-authentication

假设我在web.config中使用这样的东西

<authentication mode="Forms">
<forms

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

/>
</authentication>
Run Code Online (Sandbox Code Playgroud)

如果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会注意到故障单已过期并将用户重定向到登录页面.

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

谢谢

sis*_*sve 5

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

根据RFC 6265第5.1.1节, Cookie使用UTC时间作为到期日期.

"让解析后的cookie日期为其日,月,年,小时,分钟和秒(以UTC为单位)的日期,即月日值,月份值,年份 - 值,小时值,分钟值和秒值."

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

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

绝对过期不会阻止这种情况,但需要定期重新验证,限制第三方可以使用cookie的时间窗口.