浏览器对后续请求重复发送旧Authorization请求头问题排查

核心原因：浏览器的Basic认证凭证存储逻辑 #

• 浏览器收到WWW-Authenticate: Basic realm="production site"响应后，会把用户输入的凭证（用户名+密码经Base64编码）存在浏览器内置的凭证管理器里，这和普通缓存、Cookie不是一个存储区域。
• 你清缓存、删Cookie甚至重启浏览器，都清不掉这些凭证——只有手动在浏览器的密码/凭证管理里删掉对应条目才行。
• 只要浏览器识别到请求的URI和之前的realm一致，就会自动带上存储的旧Authorization头，哪怕服务端的会话已经销毁。

验证步骤 #

• 打开浏览器的凭证管理：Chrome找「设置→隐私和安全→密码管理器」，Firefox找「设置→隐私与安全→已保存的密码」，搜production site对应的条目，肯定能找到旧凭证。
• 删除这个条目后再发请求，浏览器会重新弹出认证窗口，不会自动带旧头了。

解决办法 #

1. 换用Cookie会话认证（最推荐） #

• 别再依赖浏览器的Basic自动认证了，改成用户登录时提交表单，服务端验证通过后设会话Cookie，后续请求靠Cookie识别用户，彻底绕开Authorization头的问题。
• 如果必须用Basic认证，登出时服务端返回带WWW-Authenticate: Basic realm="production site", error="invalid_token"的401响应，部分浏览器会触发清除对应凭证（不是所有浏览器都支持）。

2. 修改认证域强制重新认证 #

• 会话销毁后返回401时，把realm改成不一样的，比如从"production site"改成"production site - reauth"，浏览器会认为是新的认证域，就不会带旧凭证，会重新弹认证窗口。
• 缺点是用户每次会话销毁后看到的认证提示会变，体验有点小影响，但能快速解决问题。

3. 引导用户手动清凭证 #

• 在登出提示或者帮助文档里告诉用户怎么删浏览器里的对应认证凭证，适合临时排查或者小众场景。

内容的提问来源于stack exchange，提问作者Venkat