Go HTTP跨域重定向的认证头保留策略

Go 的 http.Client 遇到 3xx 会自动跟随重定向，但认证头并不是“永远跟着请求走”。默认实现会把 Authorization、WWW-Authenticate 和 Cookie 视为敏感头：目标主机与初始主机不相同、也不是子域名匹配时，客户端会移除它们。真正需要控制跨域重定向时，应把目标 scheme、主机和跳转历史放进 CheckRedirect 的信任判断里，而不是在每次请求前盲目复制 token。

一、Go 默认如何处理重定向里的认证头

先看清默认行为，才能解释为什么“第一次请求有 token，第二跳却没有”。Go 会根据初始 URL 与新 URL 的主机关系决定是否复制敏感头；example.com 到自身通常保留，到 api.example.com 这样的子域也可能保留，而跳到完全无关的 other.example 则会移除。

这里还有两个容易混淆的点：不同 scheme 但仍是同一主机时，Go 的行为比浏览器 Fetch 标准更宽松；有 CookieJar 时，Cookie 还会受到每一跳响应中 Set-Cookie 的影响。因此，不能只用“有没有跨域”四个字判断结果。

二、用 CheckRedirect 把信任判断放在客户端层

CheckRedirect 会在客户端准备跟随下一跳前收到新请求 req 和历史请求切片 via。生产代码可以先限制跳转次数，再检查 scheme 与主机是否在允许集合中；不满足条件就返回错误，让调用方拿到 *url.Error，而不是继续把请求交给未知目标。

allowedHosts := map[string]bool{
	"login.example.com": true,
	"api.example.com":   true,
}

client := &http.Client{
	CheckRedirect: func(req *http.Request, via []*http.Request) error {
		// 防止服务端配置错误造成过长的跳转链。
		if len(via) >= 5 {
			return fmt.Errorf("redirect chain is too long")
		}
		// 只允许 HTTPS 和明确登记的目标主机。
		if req.URL.Scheme != "https" || !allowedHosts[req.URL.Hostname()] {
			return fmt.Errorf("untrusted redirect target: %s", req.URL.Host)
		}
		return nil // 通过策略检查，交给 Client 继续处理默认头复制规则。
	},
}

这个回调只负责“是否允许去那里”，不会把被 Go 移除的 Authorization 自动恢复。若业务确实需要给受控网关补发凭据，应在严格的主机白名单内创建目标服务专用凭据，避免把初始用户 token 原样扩散。

三、受控跨服务场景的认证头处理方案

常见场景是登录服务把请求导向 API 网关，或者旧域名迁移到新域名。最稳妥的做法是让网关完成服务端认证交换，客户端只携带短时、受众明确的凭据；如果必须由客户端继续发送头，至少同时满足 HTTPS、固定主机、固定端口和明确的业务跳转关系。

• 不要在 CheckRedirect 中对任意 req.URL.Host 调用 Header.Set("Authorization", token)。
• 不要把 Cookie Jar 当成跨站授权器，Cookie 的域、路径和响应变更都要单独审查。
• 对 301、302、303 与 307、308 分开考虑：前几类可能改变方法并丢弃请求体，后两类更可能保留原方法和 body。

四、上线前的重定向认证检查清单

把下面几项放进集成测试或配置评审：初始 URL 与所有 Location 的 scheme 是否稳定；目标主机是否来自固定配置而非用户输入；跳转链是否有上限；是否使用 CookieJar；失败时调用方是否能区分策略拒绝与网络错误；最后检查日志中是否意外记录了完整 Authorization 值。

相关问题

为什么跳到子域名后 Authorization 还在？

Go 的默认规则把同域和子域匹配视为较可信的目标，这与浏览器 Fetch 的严格同源处理并不完全相同。需要更窄边界时，用 CheckRedirect 明确列出允许主机。

返回 ErrUseLastResponse 能保留原响应吗？

可以。它用于停止跟随并让调用方处理当前响应，但仍要按普通响应流程关闭或读取 Body。

如何避免重定向泄露用户 token？

默认不要手工补发敏感头；限制 HTTPS、固定目标和跳转次数，跨服务认证优先改成服务端凭据交换。