無Cookie會話的實現是怎樣的

這期內容當中小編將會給大家帶來有關無Cookie會話的實現是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

無Cookie會話

在 ASP.NET 中，無需使用 Cookie，就可以有選擇地建立必要的會話-用戶聯系。非常有趣的是，除了以下配置設置以外，您無需在 ASP.NET 應用程序中更改任何內容即可啟用無 Cookie 會話。

< sessionState cookieless="true" />

ASP.NET 會話狀態的默認設置是在 machine.config 文件中定義的，并且可以在應用程序根文件夾中的 web.config 文件中重寫。通過確保上述行出現在根 web.config 文件中，您可以啟用無 Cookie 會話。就是這樣 — 簡單而有效！

< sessionState>節點還可以用于配置會話狀態管理的其他方面，包括存儲介質和連接字符串。但是，就 Cookie 而言，只需您將 cookieless 屬性設置為 true（默認設置為 false）。

請注意，會話設置是應用程序范圍的設置。換句話說，您站點中的頁要么都將使用要么都將不使用 Cookie 來存儲會話 ID。

當不使用 Cookie 時，ASP.NET 在哪里存儲會話 ID 呢？在這種情況下，會話 ID 插入到 URL 內的特定位置中。下圖顯示一個使用無 Cookie 會話的真實站點的快照。

圖 1. 使用無Cookie會話的 MapPoint

假設您請求了一個類似于 http://yourserver/folder/default.aspx 的頁。正如您可以從 MapPoint 快照中看到的那樣，資源名稱前面的相鄰斜杠進行了擴展，以便包含在內部填充了會話 ID 的括號，如下所示。

http://yourserver/folder/(session ID here)/default.aspx

會話 ID 嵌入到 URL 中，并且無需在其他任何地方持久保存它。唔，并不完全是這樣。請考慮以下方案。

您訪問了一個頁，并且被分配了一個會話 ID。接下來，您清除了同一瀏覽器示例的地址欄，轉到另一個應用程序并且開始工作。然后，您重新鍵入了上一個應用程序的 URL，并且（猜猜看）在您進入的過程中檢索會話值。

如果您使用無 Cookie 會話，那么當您第二次訪問該應用程序時，您將被分配一個不同的會話 ID，并且丟失以前的所有狀態。這是無 Cookie 會話的一個典型的副作用。為了了解其原因，讓我們進一步探討無 Cookie 會話的實現。

無Cookie對話的實現

無Cookie會話的實現得益于下列兩個運行時模塊的努力：一個名為 SessionStateModule 的標準會話 HTTP 模塊，以及一個名為 aspnet_filter.dll 的可執行文件。后者是一小段 Win32 代碼，它充當 ISAPI 篩選器。HTTP 模塊和 ISAPI 篩選器實現了相同的思想，不同之處在于 HTTP 模塊由托管代碼組成，并且需要 ASP.NET 和 CLR 觸發才能工作。像 aspnet_filter.dll 這樣的傳統 ISAPI 篩選器是由 Internet 信息服務 (IIS) 調用的。二者都截獲在請求處理過程中激發的 IIS 事件。

當新瀏覽器會話的第一個請求進入時，會話狀態模塊讀取 web.config 文件中有關 Cookie 支持的設置。如果 節的 cookieless 屬性設置為 true，則該模塊生成一個新的會話 ID，通過將該會話 ID 填充到資源名稱前面的相鄰位置來分割 URL，并且使用 HTTP 302 命令將瀏覽器重定向到新的 URL。

當每個請求到達 IIS 入口時（遠遠早于它被移交給 ASP.NET），aspnet_filter.dll 獲得了一個查看它的機會。如果該 URL 將會話 ID 嵌入到括號中，則會提取該會話 ID 并將其復制到一個名為 AspFilterSessionId 的請求標頭中。然后，重寫該 URL 以使其看起來像原來請求的資源，并且將其釋放。這一次，ASP.NET 會話狀態模塊從請求標頭中檢索會話 ID，并且通過會話-狀態綁定繼續工作。

只要該 URL 包含可用來獲取會話 ID 的信息，無 Cookie 機制就可以很好地工作。不過，這會造成一些使用限制。

上述就是小編為大家分享的無Cookie會話的實現是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。