Cookie 實現「記住我」自動登錄完整方案：從基礎到安全加固

核心需求

用戶首次登錄後，在有效期內（如 2 小時）再次訪問無需輸入賬號密碼，直接進入系統主頁。關鍵在於服務端識別用戶身份，Cookie 是最簡單的持久化標識方案。

方案演進四階段

階段 1：僅用 Cookie 存用戶名（極不安全）

// 登錄成功後
Cookie cookie = new Cookie("username", username);
cookie.setMaxAge(365 * 24 * 3600); // 1年
cookie.setPath("/");
response.addCookie(cookie);

再次訪問時檢查 Cookie 存在即放行。**缺陷**：用戶名可被竄改、偽造，無任何安全性。

階段 2：引入 Session 服務端驗證（安全性提升）

// 登錄成功
HttpSession session = request.getSession();
session.setAttribute("user", userObject);
session.setMaxInactiveInterval(2 * 3600); // 2小時

// 再次訪問
Cookie[] cookies = request.getCookies();
for (Cookie c : cookies) {
    if ("username".equals(c.getName())) {
        if (session.getAttribute("user") != null) {
            // 自動登錄成功
        }
    }
}

**缺陷**：Session 依賴 JSESSIONID Cookie，默認是會話級 Cookie（瀏覽器關閉即失效），無法滿足「關閉瀏覽器後仍自動登錄」的需求。

階段 3：持久化 JSESSIONID 實現真正的「記住我」

HttpSession session = request.getSession();
session.setAttribute("user", userObject);
session.setMaxInactiveInterval(2 * 3600); // 服務端 Session 存活 2h

// 關鍵：手動創建持久化 JSESSIONID Cookie
Cookie jsessionCookie = new Cookie("JSESSIONID", session.getId());
jsessionCookie.setMaxAge(2 * 3600); // 客戶端 Cookie 也存活 2h
jsessionCookie.setPath("/");
response.addCookie(jsessionCookie);

此時即使瀏覽器關閉重啟，只要在有效期內，JSESSIONID 仍隨請求發送，服務端能找到對應 Session，實現自動登錄。

階段 4：安全加固——簽名 Token 替代明文標識（生產級方案）

上述方案仍有風險：JSESSIONID 被竊取即可劫持會話。生產環境建議：

1. 登錄成功生成隨機 Token（UUID/JWT），存入 Redis/數據庫，映射用戶 ID，設置過期時間。
2. 將 Token 以 HttpOnly; Secure; SameSite=Strict 屬性寫入 Cookie。
3. 再次訪問時校驗 Token 有效性、綁定 IP/UA、刷新過期時間。
4. 敏感操作需二次驗證（短信/郵箱/密碼）。

Cookie 同名覆蓋規則補充

• 響應頭中出現多個同名 Cookie（同 name、path、domain），最後一個覆蓋前面。
• path 不同時視為不同 Cookie（如 /web1 vs /web2）。

總結

從「Cookie 存用戶名」到「持久化 JSESSIONID」再到「簽名 Token + Redis」，是自動登錄方案的標準演進路徑。切記：永不在 Cookie 存放敏感明文，服務端狀態才是權威來源。