JavaWeb 會話管理全解析：Session、Cookie 與 URL 重寫實戰

JavaWeb 會話管理全解析：Session、Cookie 與 URL 重寫實戰

HTTP 無狀態特性導致伺服器無法識別同一用戶的多次請求。會話跟蹤技術透過 SessionId 建立客戶端與伺服器的 1 對 1 關聯。本文通過完整 Servlet 實例，演示 Session 生命週期、Cookie 依賴、URL 重寫降級方案及常見陷阱。

核心機制

• SessionId：會話唯一標識，預存在客戶端 Cookie JSESSIONID 中
• 流程：首次請求 → 伺服器建立 Session 並下發 Cookie → 後續請求攜帶 Cookie → 伺服器識別 Session
• 禁用 Cookie 時：需啟用 URL 重寫，將 jsessionid 附加在 URL 路徑參數中

完整實戰代碼結構

關鍵代碼片段

// LoginServlet - 獲取/建立 Session 並打印狀態
HttpSession session = request.getSession();
out.println("會話狀態: " + (session.isNew() ? "新會話" : "舊會話"));
out.println("SessionId: " + session.getId());
out.println("創建時間: " + new Date(session.getCreationTime()));

// LoginChkServlet - 登入驗證成功寫入 Session
if (validUser) {
    HttpSession session = request.getSession();
    session.setAttribute("username", userName);
    response.sendRedirect("welcome");
}

// URL 重寫適配（禁用 Cookie 時必須）
response.sendRedirect(response.encodeRedirectURL("login"));
// 表單 action 也需重寫
out.println("<form action='" + response.encodeURL("loginchk") + "' method=post>");

web.xml 會話超時配置

<session-config>
    <session-timeout>10</session-timeout> <!-- 分鐘 -->
</session-config>

實測現象與分析

1. 首次訪問：顯示「新會話」，MaxInactiveInterval=600 秒（10 分鐘）
2. F5 刷新：變為「舊會話」，SessionId 不變
3. 登入後：Session 綁定用戶名，Welcome 頁顯示歡迎信息
4. 同瀏覽器二次登入：SessionId 相同，用戶名被覆蓋（Session 覆蓋問題）
5. 不同瀏覽器 (IE/Chrome)：SessionId 不同，互不干擾
6. 禁用 Cookie：無法登入，每次請求都是新 Session
7. 啟用 URL 重寫：URL 帶 ;jsessionid=xxx，恢復正常會話跟蹤

進階知識點

• 關閉瀏覽器不銷毀 Session：只要未超時，重新打開仍為舊會話（Cookie 存內存）
• Cookie 名稱固定為 JSESSIONID，存儲於瀏覽器進程內存，進程間不共享
• Session 固化攻擊防範：登入成功後調用 request.changeSessionId()（Servlet 3.1+）
• 分佈式 Session：生產環境建議 Redis 共享 Session，而非單機內存

最佳實踐總結

1. 優先使用 Cookie 跟蹤，配置 HttpOnly、Secure 屬性
2. 關鍵業務頁面強制檢查 Session 屬性，未登入重導登入頁
3. 登出必須調用 invalidate() 銷毀伺服器端 Session
4. 預留 URL 重寫代碼路徑，應對客戶端禁用 Cookie 場景
5. 集群環境採用外部化 Session 存儲（Redis/Memcached/DB）