我想访问由在其他域上运行的CAS保护的REST服务。这意味着我需要向CAS登录端点发出请求，并将其重定向到目标服务。关于为什么 CORS重定向失败，这里有很多问题，但是我还没有找到关于如何使其真正发挥作用的答案。
我发现了一些W3C guidance for dealing with CORS，其中包括专门用于该主题的内容：
要使通过简单请求访问的启用CORS的资源的透明移动成为可能，需要服务器的工作和协调。例如，https://old.example.com/resource处的资源可能会以credentals响应CORS请求，并重定向到https://new.example.com/resource?originalOrigin=...&credential= ...这将承载在URL参数（而非Cookie和Origin）中访问资源的权限标头。在https://new.example.com处的服务器将需要自定义逻辑来识别和验证这些参数并执行适当的授权，然后再将Access-Control-Allow-标头返回给用户代理。
我同时控制了服务和客户端代码的容器，因此我应该能够做到（对吗？），但是我认为该文档中所描述的内容实际上是不可能的。登录端点已经可以使用一次性凭证令牌进行重定向（这就是CAS的工作方式），因此应该很容易。
如文字所述，重定向器（上述的old.example.com）应带有凭证。但是，如果我呼叫fetch(url, {credentials:"include"})，则在重定向后（上面的new.example.com）也将包含凭据。因为我要告诉fetch包含凭据，所以浏览器加载的最终URL必须发送匹配的ACA-Origin标头，但是由于它是重定向的目标，因此第二个请求的来源将是{{1 }}。
要使建议使用W3C的工作流成为可能，我需要能够告诉浏览器将凭证发送到null，但是一旦它将您重定向到old.example.com，则在没有凭证/ in的情况下请求它无心跳模式。据我所知这是不可能的-初始请求和随后的所有重定向都具有相同的提取选项。我想念什么吗？还有另一种方法可以做到这一点吗？
答案 0 :(得分：1)
您什么都不丢失。如果您不希望在新位置上允许凭证请求，则需要更新所有呼叫者。