Web 服務器 Digest 鑒權：為何錯誤提示延遲至三次失敗後？

現象解析

使用 WWW-Authenticate: Digest 進行 HTTP 摘要認證時，用戶輸入錯誤憑證，瀏覽器不會即時顯示錯誤，而是允許重試三次，第三次失敗後才彈出錯誤頁面。

協議機制原因

1. 三次握手流程：
   1) 客戶端請求 → 401 + WWW-Authenticate: Digest nonce=...
   2) 客戶端攜帶 Authorization: Digest response=... 重試
   3) 服務器驗證失敗 → 再次 401 + 新 nonce → 客戶端再試
   瀏覽器內建重試邏輯，通常允許 3 次，第三次仍失敗才交給頁面處理。
2. 無狀態特性：Digest 旨在防重放攻擊，每次挑戰用新 nonce，服務器不記錄嘗試次數，由客戶端（瀏覽器）控制重試。

無法在服務端即時攔截單次失敗

服務端只能返回 401，無法強制瀏覽器在第一次失敗就彈出自定義錯誤。瀏覽器的原生認證對話框不支援自定義錯誤文案。

替代方案：改用表單登錄 + Session/JWT

// 登錄頁 POST /login
if (valid(username, password)) {
    session.setAttribute("user", user);
    return "redirect:/dashboard";
} else {
    model.addAttribute("error", "用戶名或密碼錯誤");
    return "login"; // 即時顯示錯誤
}

• 完全可控的錯誤提示、驗證碼、鎖定策略。
• 支援 HTTPS 傳輸加密，安全性不遜於 Digest。
• 可結合 Spring Security、Shiro 等框架快速實現。

若必須保留 Digest（如舊設備對接）

• 前端自定義彈窗收集憑證，JS 計算 Digest 响應並發送 Ajax，失敗即時提示（需實現 Digest 算法）。
• 或在反向代理（Nginx）層面做限流與自定義錯誤頁。

Digest 認證的瀏覽器原生重試機制導致錯誤提示延遲，現代 Web 應用建議改用表單登錄 + Session/JWT 以獲得即時、可控的用戶體驗。