JS跨域Fetch请求带认证的重定向链接A遇CORS，如何获取目标下载链接B

完全可以通过编程方式获取重定向后的链接B，不需要依赖用户手动操作，也无需修改目标服务器配置。核心是匹配A服务器的请求识别规则，在不触发文件自动下载的前提下，捕获302重定向响应中的目标地址。

• 直接用fetch请求A时，A的服务器识别到这是跨域XHR类请求，会直接拒绝返回合规的CORS响应头，根本不执行后续的认证、重定向逻辑，直接抛出跨域错误
• 直接通过地址栏、静默窗口导航到A时，A的服务器会正常识别为合法用户导航请求，返回302跳转到B；但跨域的窗口/iframe会受同源策略限制，无法通过JS读取当前页面的实际URL
• B的响应默认携带Content-Disposition: attachment头，导航到B时浏览器会直接接管下载流程，不会让页面停留在B的地址上，进一步导致无法捕获跳转目标

通过同源部署的Service Worker做请求拦截，完整实现流程：

1. 注册同源Service Worker
   在主应用中注册和自身域名同源的Service Worker，这一步完全符合浏览器安全规则，不存在跨域问题。Service Worker的权限是可以拦截应用上下文中发起的所有类型请求，包括导航类请求、跨域请求，也能读取响应中的重定向头信息。
2. 构造合法的导航请求触发A的重定向逻辑
   不使用fetch请求A，而是通过完全不可见的隐藏iframe，将iframe的src设置为拼接好用户名、密码认证参数的链接A。这个请求的发起上下文和用户手动在地址栏访问A完全一致，A的服务器会正常执行认证校验，返回标准的302重定向响应到B。
3. 在Service Worker层捕获重定向目标
   拦截导航请求的流程中，Service Worker在接收到A返回的302响应时，不需要等浏览器继续发起对B的请求，就可以直接从响应头中读取到Location字段的值，也就是完整的临时链接B。
4. 中断导航流程避免自动下载
   拿到B的地址后，Service Worker可以直接中断本次导航的后续流程，返回一个空的204响应给浏览器，整个流程不会触发B对应的文件下载动作。
5. 回传B链接完成后续请求
   Service Worker通过postMessage将拿到的B链接回传给主应用页面，主应用直接对B发起常规fetch请求即可——因为B本身不存在CORS限制，可正常读取文本文件内容。

• 不要尝试对A使用fetch(linkA, { redirect: 'manual' })来获取重定向地址：一方面A的服务器会直接识别为跨域fetch请求抛出CORS错误，另一方面即便服务器返回302，浏览器也会返回opaque类型的响应，不会向普通JS上下文暴露Location头信息
• 所有跨域导航的重定向信息只会暴露给同源的Service Worker，普通页面JS、跨域iframe、跨域弹出窗口的上下文都没有权限读取，这是浏览器的安全限制
• 构造带认证参数的A链接时，不要将用户名密码持久化存储，临时拼接URL后及时清理，避免信息泄露
• 隐藏iframe要设置为完全不可见（宽高为0、脱离视口），不要让用户感知到导航动作

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