如何防止 Safari 在遵循同源重定向时删除授权标头？
当遵循同源 301 重定向时，Safari 似乎会删除 Authorization 标头。例如，以下 JS 代码：
fetch("/api/endpoint-that-redirects", { headers: new Headers({ "Authorization": "sometoken" })})
将使用 Authorization 标头触发一个到 /api/endpoint-that-redirects 的 GET，该标头会响应301 w/位置/api/endpoint。浏览器会自动遵循此操作，这意味着它会再次对 /api/endpoint 进行 GET，但这次没有 Authorization 标头。
这似乎是重定向到不同来源时的预期行为，但我不明白如果重定向到同一来源的另一个 URL 时为什么会发生这种情况。
我在 StackOverflow 上看到了很多关于这种行为的在线帖子和问题，但我还没有看到任何明确的解决方案，或者至少没有看到关于这种行为的解释。 其他问题中也不清楚重定向是否到同一主机。
Chrome (98) 和 Firefox (97) 都遵循重定向并在后续 GET 请求中包含 Authorization 标头。
Safari seems to drop the Authorization header when following a same-origin 301 redirect. For example, this JS code:
fetch("/api/endpoint-that-redirects", { headers: new Headers({ "Authorization": "sometoken" })})
will trigger one GET to /api/endpoint-that-redirects with the Authorization header, which responds with a 301 w/ Location /api/endpoint. The browser follows this automatically, meaning it makes another GET to /api/endpoint, but this time without the Authorization header.
This seems to be expected behavior when redirecting to a different origin, but I can't see why this would happen if the redirect is to another URL at the same origin.
I've seen a lot of posts online and questions about this behavior on StackOverflow, but I haven't seen any definitive solution or at least an explanation about this behavior. It's also not clear in other questions if the redirect is to the same host.
Chrome (98) and Firefox (97) both follow the redirect and include the Authorization header in the subsequent GET request.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Safari 15.4+（iOS 15.4、macOS 12.3）用户将不再遇到此
授权下降问题。详细信息：此问题的修复实际上早在 2021 年 10 月就已合并到 WebKit/Safari 代码中 但根据 https://bugs.webkit.org/show_bug.cgi?id=230935#c18< /a> 直到 2022 年 3 月中旬才在 Safari 15.4 中发布。
因此，对于 15.4 之前的 Safari 版本的任何用户（尚未升级到 iOS 15.4 或 macOS 12.3 的用户），此问题将继续发生，但对于当前使用 Safari/iOS/macOS 的用户而言，不会出现此问题。
Safari 15.4+ (iOS 15.4, macOS 12.3) users will no longer experience this
Authorizationdrop.Details: A fix for this was actually merged into the WebKit/Safari code back in October 2021 but per comments at https://bugs.webkit.org/show_bug.cgi?id=230935#c18 didn’t end up shipping until mid-March 2022 in Safari 15.4.
So, this problem will continue to happen for any users of Safari versions prior to to 15.4 — users not upgraded to iOS 15.4 or macOS 12.3 yet — but not for users with current Safari/iOS/macOS.
根据所写的 Fetch 标准，这是一个错误。请参阅 HTTP 网络中的 httpRequest -或缓存获取。每个 HTTP 请求本质上都是从输入请求的克隆开始，其中包括所有开发人员设置的标头。
但是，对于
授权的具体情况，它是一个未解决的问题 是否应跨源包含它。This is a bug per the Fetch Standard as written. See httpRequest in HTTP-network-or-cache fetch. Each HTTP request essentially starts out with a clone from the input request, which includes all developer-set headers.
However, for the specific case of
Authorizationit is an open issue whether it shold be included across origins.