在使用窗體身份驗證「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」

回答

相關問題