前言：在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下。
