ASP.NET 3.5核心編程學習筆記（35）：工作階段狀態的自訂管理

　　綜合各方面考慮，有3種工作階段狀態管理的自訂方案：

　　1. 保留預設的會話模組，但編寫自訂的狀態供應器來更改儲存介質。這樣，我們還有機會重寫一些用於在儲存與Session之間運載會話資料的輔助類。

　　2. 保留預設的會話模組，但替換會話ID產生器。

　　3. 將預設的工作階段狀態模組替換成自己的。這種方法提供了最好的靈活性，但也最為複雜，建議僅當的確必要且知道確切的實現方法才使用這種方案。

構建自定的工作階段狀態提供者

　　工作階段狀態提供者是一種組件，負責為當前會話資料進行服務。當請求需要狀態資訊時，該組件便會被調用，從給定的儲存介質中擷取資料，並返回給主調模組。在請求結束時，也會被調用，以便將提供的資料寫入儲存層。

　　ASP.NET支援三種狀態供應器，下表對其作了說明：

　　我們還可以編寫自己的狀態供應器類，使其應用自選的儲存介質。

定義工作階段狀態儲存

　　狀態供應器是一種繼承於SessionStateStoreProviderBase的類，下表列出了其介面的主要方法：

　　繼承SessionStateStoreProviderBase類，並保留預設的ASP.NET工作階段狀態模組，這種方案只能更改工作階段狀態資料存放區和資料恢複這部分功能，其他功能不能更改。

鎖定與到期

　　狀態供應器必須實現會話連續訪問的鎖定機制。工作階段狀態模組能夠判斷請求需要的是工作階段狀態的唯讀訪問還是可讀/寫訪問，根據判斷結果，它會調用GetItem或GetItemExclusive。在這兩個方法的實現中，提供者的編寫者應建立讀取會話/寫入會話的鎖定機制，允許多個並發的讀取操作，但要阻止向鎖定的會話寫入資料。

　　另一個問題是，要使工作階段狀態模組知道給定會話的到期時間。若global.asax定義了Session_End事件的處理常式，工作階段狀態模組會調用SetItemExpireCallback。通過該方法，狀態供應器會得到一個回呼函數，其原型如下：

public delegate void SessionStateItemExpireCallback(string sessionID, SessionStateStoreData item);

　　會話模組要將返回的委託在內部儲存，在給定會話逾時時調用。對到期回調的支援是可選的，事實上，只有InProc真正支援它。如果不希望自訂提供者支援到期回調，應指示SetItemExpireCallback方法返回false。

　　如果要支援無Cookie會話的提供者，還必須實現CreateUninitialized方法，以便向資料存放區中寫入空的會話項。確切地講，空的會話項是一種完整的資料項目，但不包含實際的資料。也就是說，會話項應包含會話ID和建立時間（可能還包含鎖的ID），但不包含資料。對於ASP.NET 2.0，在無Cookie模式下，只要在會話到期後發出請求，就會產生新的ID。工作階段狀態模式會產生新的ID，並使瀏覽器重新導向。若未初始化的會話項沒有被分配新的ID，那麼新的請求仍會被看作是到期會話中的請求。

會話資料字典的替換

　　SessionStateStoreData是代表會話項的類（一種包含與會話有關的所有資料的資料結構）。事實上，GetItem和GetItemExclusive返回的就是該類的執行個體。該類有3個屬性：Items、StaticObjects和Tiemout。

　　Items最終用於為頁面對象Session屬性中的鍵/值集合提供資料。StaticObjects中包含的是隸屬於當前會話的靜態對象（如在global.asax中聲明，且在會話範圍中可見的對象）。Timeout是工作階段狀態的有效時間（以分為單位），預設值得為20分鐘。

　　一旦工作階段狀態模組為請求獲得工作階段狀態，該模組會將Items集合的內容寫入HttpSessionStateContainer類的新執行個體。該對象之後被傳給HttpSessionState類的建構函式，成為Session屬性幕後的資料容器。

　　對於會話模組和狀態供應器來說，會話項的容器只不過是實現ISessionStateItemCollection介面的類。預設情況下，執行個體使用的類為SessionStateItemCollection。只要自訂的類實現了上述介面，就可以替代SessionStateItemCollection類。

　　若要編寫狀態供應器，SessionStateUtility類會非常有用，該類包含序列化和還原序列化會話項的方法，以便將其儲存到某介質中，或將其讀出。此外，該類還有有些方法，可以從會話中抽取資料字典並將其添加到HTTP上下文和Session屬性。

自訂工作階段狀態提供者的註冊

　　為使應用程式能夠使用自訂的工作階段狀態提供者，我們需要在web.config檔案中註冊它。假設有一個叫SampleSessionStaeProvider的提供者類，被編譯為MyLib程式集：

<system.web>
<sessionState mode="Custom"
        customProvider="SampleSessionProvider">
<providers>
<add name="SampleSessionProvider"
                type="SampleSessionStateProvider, MyLib" />
</providers>
</sessionState>
</system.web>

自訂會話ID的產生

　　為產生會話ID，ASP.NET 2.0使用了名為SessionIDManager的組件。該類既不是HTTP模組也不是提供者，它只是一個繼承於System.Object且實現ISessionIDManager介面的類。只要實現ISessionIDManager介面，自訂的類就可以替換該組件。

預設的行為

　　預設的會話ID模組以位元組數組的形式產生會話ID，並帶有15個值的強隨機序列進行加密。該資料之後會被編碼為包含24個字元的字串，且每個字元都符合URL的標準，系統會將其用途會話ID。

　　會話ID可通過HTTP Cookie或修改的URL在伺服器與用戶端間傳輸，具體方式取決於<sessionState>中cookieless屬性的值。注意，若使用無cookie會話，會話ID模組要負責將ID添加到URL中，並對瀏覽器進行重新導向。預設的產生器會將瀏覽器重新導向到下面的虛URL：

　　http://www.contoso.com/test/(S(session_id))/page.aspx

　　這種URL發出的請求如何被正確處理呢？在無Cookie會話情況下，會話ID模組會利用一個輕型的ISAPI篩選器（aspnet_filter.dll）將傳入的URL動態重寫為實現資源的URL。請求會被正確處理，但地址欄中的路徑不會改變。檢測到的會話ID會被置於一個叫AspFilterSessionId的標題中。

自製的會話ID管理器

　　會話ID管理器是一個實現ISessionIDManager介面的類，因而我們有兩種方案來構建它：

　　1. 建立一個類，並使其實現該介面。

　　2. 從SessionIDManager派生出一個類，並重寫其中的兩個虛方法（CreateSessionID和Validate），以實現某些特殊的邏輯。

　　ISessionIDManager介面的方法見下表：

　　如果打算使用完全自訂的會話ID產生器，應注意以下幾點：

　　1. 產生ID的演算法非常關鍵。如果不實現強隨機加密過程，當某些會話處於活動狀態時，惡意使用者可能會猜到有效ID。為此，產生全域唯標識符（GUID）是一個不錯的選擇。

　　2. 我們可以選擇是否支援無Cookie的會話。如果添加這種支援，則必須使該組件能從HTTP請求中抽取會話ID，並對瀏覽器進行重新導向。為此，可能需要ISAPI篩選器或HTTP模組，對請求進行預先處理並對其做適當的修改。

　　建立好會話ID模組後，便可將其在設定檔中註冊：

<sessionState sessionIDManagerType="Samples.MyIDManager, MyLib" >
</sessionState>