前言:在ASP.NET中,常用的就是Forms驗證,最重要的原因就是靈活。因為Forms驗證細細的談起來也確實不少,而且我也不想草草的說完了事,那對大家和自己都不負責任的。
本篇的話題如下:
Forms驗證的工作原理
Forms驗證中的API
Forms驗證的工作原理
我們知道,Forms驗證主要是基於cookie的,說白一點就是:把用戶信息保存在cookie中,然後發送到客戶端;再就是解析客戶端的發送了的cookie信息,進行解析,然後進行驗證。關於cookieless的工作原理和方法,我這裡不贅述,大家可以參看我的另外的一片文章:淺談ASP.NET內部機制(一)。
當匿名用戶請求一個需要驗證後才能訪問的資源和頁面的時候,那麼如果采用了Forms驗證,那麼URL授權模塊就會把用戶重定向到登錄頁面。而之前請求的URL就會被保存起來,等到用戶正確的登錄後,就再次轉向之前要請求的頁面。我想這點,大家應該都用過。
下面我們就看看登錄的時候發生了什麼,看看登錄的具體的流程?也請大家注意我使用的一些術語,因為這些術語再Forms中都有特定的對象,大家之後就可以看到的,很重要。
1.再浏覽器中有個登錄窗體,要輸入用戶名和密碼等憑證,通過提交給服務器的ASP.NET網站來審核,檢查憑證是否正確。
2.如果憑證正確,那麼就會再服務器端就會創建一個"身份驗證票據"。身份驗證票據中含有了經過加密的用戶信息。
3.這個票據再服務器端被寫入cookie中,然後發送到客戶端。
4.然後用戶就被重定向到他們最初請求的URL中。
注:大家可能會有疑問:最初請求的URL到底保存在哪裡?不要擔心,現在只要明白上面的流程就OK。
5.上面第4步就是要轉向最初請求的URL,假設最初的請求頁面是Default.aspx,那麼現在就是從登錄的頁面Login.aspx轉向到Default.aspx 頁面,此時因為身份驗證的票據cookie已經存在於客戶端的浏覽器中了,此時的轉向Default.aspx頁面時,實際是再次向服務器端發起了請求,所以正如我們之前所談到的:每個請求都要從ASP.NET管道中一級級的向後傳,要經歷ASP.NET的的生命周期:Application_BeginRequest,Application_AuthenticateRequest.....。(希望大家明白)
但是這次的請求就和第一次我們發起的請求步同了,為什麼?
第一次我們請求Default.aspx頁面的時候,我們根本就沒有提供任何的表明我們身份的票據,但是這次我們已經登錄了,而且我們的浏覽器中已經有了我們的身份驗證的票據的cookie,此時在Application_AuthenticateRequest事件中,Forms驗證模塊就獲取表明我們身份cookie,然後就利用cookie中信息填充Context.User。
驗證模塊處理完之後就是授權模塊起作用了。其實URL授權模塊就會利用我們之前填充在Context.User中的信息來驗證用戶是否被批准訪問所請求的資源或者頁面。
Forms驗證中的API
實現Forms身份驗證之前,我們看看組成Forms驗證的API以及相關的類:
FormsAuthenticationModule:對每個請求進行驗證的HTTP模塊
FormsAuthentication:包含在Forms驗證中我們常用的方法和屬性(很重要的)
FormsIdentity:Forms驗證標識。
FormsAuthenticationTicket:身份驗證的票據,對用戶的信息進行加密後的產物,我們一般把它寫如cookie中,之前我們談過了的。
上面的類在System.Web.Security下。