Java Web應用程序的會話管理崩潰會涉及到以下幾點：一般流程、Cookie使用情況、URL重寫和會話銷毀。
本文將介紹在Java Web app中會話管理的工作原理。為了了解流程的工作原理，先從下面這個圖開始：
1. 用戶提交一個網頁請求。
2. 瀏覽器將請求發送到Web服務器。
3. 服務器識別到請求中沒有“會話相關信息/標識符”。所以它創建了一個新的會話(和一個新的會話標識符-JSESSIONID)。
4. 服務器將JSESSIONID發送回客戶端。
5. 這時，服務器和客戶端都具有與它們相同的會話標識符(JSESSIONID)。
6. 從這里開始，當瀏覽器向服務器發送附加請求時，必須將會話標識符(JSESSIONID)作為請求的一部分發送。(注意：每當瀏覽器向Web服務器發送請求時，同一服務器設置的所有Cookie將自動發送到請求中，因此JSESSIONID cookie也會自動發送到服務器上)
7. 當服務器獲得請求時，它會檢查瀏覽器是否將會話標識符作為請求的一部分發送。如果是，則服務器將請求視為同一會話的一部分。
8. 這種關聯關系會持續進行，直到會話被破壞(或直到它到期)為止。
如果Cookie被阻截怎么辦?
有時，用戶/瀏覽器可能不接受某些服務器的Cookie(出于安全/隱私的原因)。為了處理這種情況，Web服務器還支持在URL中傳遞會話標識符(URL重寫)：
1. 當服務器創建會話時，它“必須”以某種方式將會話標識符發送給客戶端(以便客戶端可以在后續請求期間將其發送回服務器)。
2. 最初，服務器不知道客戶端是否已經阻截了cookie。所以它以兩種方式將JSESSIONID發送給客戶端：
A. 在一個cookie中
B. 作為網址參數(例如http：//www.abc.com; jsessionid = 123xyz)。
3. 當服務器從同一客戶端獲取后續請求時：
A. 如果請求包含了JSESSIONID cookie，則表示客戶端確實接受了Cookie。因此，服務器可以依靠Cookie進行會話管理并繼續。
B. 如果沒有，服務器就會知道Cookie被阻截了，并繼續使用URL參數方法(“URL重寫”)。
會話是如何被摧毀的?
1. 超時：如果服務器在一段時間內沒有收到給定會話的任何請求，則將使會話無效。當用戶關閉瀏覽器或將其打開而沒有任何活動時，就會發生這種情況。
2. 顯式注銷頁面：Servlets / JSP可以使用session.invalidate()使會話無效。
瀏覽器關閉時會發生什么?
1. Cookie方法：JSESSIONID Cookie是一個“僅限會話”的Cookie，因此瀏覽器關閉后瀏覽器會將其刪除。因此，如果您打開另一個窗口并訪問相同的Web應用程序，則服務器將該請求視為不屬于任何會話的全新請求。
2. URL重寫方法：如果您使用JSESSIONID復制URL，請關閉瀏覽器，打開一個新的瀏覽器窗口并使用復制的URL。前提是會話沒有超時。但這也帶來安全風險(JSESSIONID的完整URL被盜用)。這就是為什么Cookie優先于URL重寫的原因之一。
京公網安備 11010502049343號