访问控制允许原点等于原点，但浏览器仍然拒绝访问...为什么？

提问者：小点点

访问控制允许原点等于原点，但浏览器仍然拒绝访问...为什么？

我有一个应用程序(React SPA ),它调用应用程序域的不同子域上的一组服务器，即:

< Li > web应用程序位于< code>foo.bar.com， < li >并与< code>api.foo.bar.com和< code>media.foo.bar.com对话。

当访问< code>api.foo.bar.com时，我从浏览器(无论是Edge、Chrome还是Firefox)得到一个错误，告诉我origin (foo.bar.com)与< code > Access-Control-Allow-Origin 响应头的值不同。然而，通过检查响应，它们是相同的:

（不幸的是，我不得不混淆地址。）

这些应用程序托管在Kubernetes上；入口是NGINX，它不提供cors(支持CORS的注释是假的)。两个应用程序(< code>api和< code>media)都是快速应用程序，并且都具有相同的CORS配置，允许特定的来源。

我想知道这是否与重定向有关-调用媒体endpoint返回一个重定向（302），其位置是一个api地址。

除此之外，我不知道可能出了什么问题。有些事情是肯定的，因为所有浏览器都同意我的请求应该被阻止（由于来源）。

在所有情况下，我都多次检查了地址中的拼写错误、结尾斜线等。我已经用cURL和Postman在那些endpoint上调用了< code>OPTIONS,使用了所有的头或者仅仅几个头。他们总是回答正确的地址。

根据要求提供的其他信息：

OPTIONS /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: GET
Access-Control-Request-Headers: feedurl
Referer: https://aiXXXXXXXXXXXXXXXX.com/
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

HTTP/2 204 No Content
date: Fri, 08 Oct 2021 13:33:10 GMT
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXXXX.com
vary: Origin
access-control-allow-credentials: true
access-control-allow-methods: GET,HEAD,PUT,PATCH,POST,DELETE
access-control-allow-headers: Content-Type, feedUrl
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2

预检通过，浏览器启动“外部测试”请求：

GET /media/1.0.0/rtsp/hls?feedUrl=https%3A%2F%2Flive.monuv.com.br%2Fa1%2F14298.stream%2Fstr27%2Fchunklist.m3u8%3Fm_hash%3DkhV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%253D HTTP/2
Host: media.aiXXXXXXXXXXXXXXXXXXXXX.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
feedUrl: https://live.monuv.com.br/a1/14298.stream/str27/chunklist.m3u8?m_hash=khV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%3D
Origin: https://aiXXXXXXXXXXXXXXXX.com
DNT: 1
Connection: keep-alive
Referer: https://aiXXXXXXXXXXXXXXXXX.com/
Cookie: ory_kratos_session=MTYzMzYzODY1OHxEdi1CQkFFQ180SUFBUkFCRUFBQVJfLUNBQUVHYzNSeWFXNW5EQThBRFhObGMzTnBiXXXXXXXXXXXXYVc1bkRDSUFJSHBtUWxsaWFsVlJhWGRTVGxSMmIzZHRkbTFqYm5CUlRWVkdkelpPWkRoWnXXXTyqwgK-0Pe0qtZHjNhfU-YoASjg3istMZi672swQ==
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
Pragma: no-cache
Cache-Control: no-cache
TE: trailers

HTTP/2 302 Found
date: Fri, 08 Oct 2021 13:33:10 GMT
content-type: text/plain; charset=utf-8
content-length: 129
location: https://api.aiXXXXXXXXXXXXXXXXXX.com/media/1.0.0/hls/streams/19dd149d-f551-4093-b2aa-e5558388d545/hls.m3u8
x-powered-by: Express
access-control-allow-origin: https://aiXXXXXXXXXXXXXXXX.com
vary: Origin, Accept
access-control-allow-credentials: true
strict-transport-security: max-age=15724800; includeSubDomains
X-Firefox-Spdy: h2

在这个响应中，浏览器失败，指出< code>origin与< code > access-control-allow-origin 不匹配。

（第一张图片来自Edge，因为日志更清晰；此日志来自Firefox）

共1个答案

匿名用户

来自浏览器的错误消息（我在下面使用虚拟 URL 和来源）可能有点令人困惑：

从来源“https://example.com”访问位于“https://api.example.com/”的XMLHttpRequest(从“https://media.example.com/”重定向)已被CORS策略阻止:对预检请求的响应未通过访问控制检查:“Access-Control-Allow-Origin”头的值“https://example.com”不等于提供的来源。

这里的关键是，正如sideshowbarker在他的评论中暗示的那样，因为您对https://media.example.com/的第一个预处理请求以跨域重定向响应到https://api.example.com/，浏览器对该资源执行另一个完整的CORS访问控制检查。然而，因为第一个预处理请求产生的重定向恰好是跨域的，浏览器将第二个预处理请求的源（错误消息将其称为“提供的源”）设置为不是https://example.com，而是null源！

以下是可能发生的事情的概要：

因为< code > https://API . example . com 很可能不会(也不应该！)允许< code>null，第二次访问控制检查失败，您会得到那个烦人的CORS错误。

抵制允许 https://api.example.com/ 无效来源的诱惑，因为这样做会产生严重的安全后果：这相当于使同源策略提供的保护无效。

相反，您应该从中删除该重定向https://media.example.com/到https://api.example.com/并使您的前端请求https://api.example.com/直接使用资源。

或者，如果您无法完全摆脱重定向，但可以更改其目标，则使其成为同源重定向(从某处< code > https://media . example . org 到< code > https://media . example . org 上的其他地方)。