Access-Control-Allow-Origin等于origin但瀏覽器仍然拒絕訪問......為什么？

我有一個應用程式（React SPA），它在應用程式域的不同子域上呼叫一堆服務器，即：

• Web 應用程式位于foo.bar.com,
• 和會談api.foo.bar.com和media.foo.bar.com。

訪問 時api.foo.bar.com，我收到來自瀏覽器（Edge、Chrome 或 Firefox）的錯誤訊息，告訴我來源 ( foo.bar.com) 與Access-Control-Allow-Origin回應標頭的值不同。但是，通過檢查回應，它們是相同的：

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

這些應用程式托管在 Kubernetes 上；入口是 NGINX，它不提供 CORS（啟用 cors 的注釋是假的）。這兩個應用程式（api和media）都是 Express 應用程式，并且都具有相同的 CORS 配置，允許特定的來源。

我想知道這是否與重定向有關 - 對media...端點的呼叫回傳一個重定向（302），其位置是一個api...地址。

除此之外，我不知道有什么問題。有些事情是肯定的，因為所有瀏覽器都同意應該阻止我的請求（由于來源）。

在所有情況下，我都多次檢查地址是否有拼寫錯誤、結束正斜杠等。我OPTIONS使用 cURL 和 Postman呼叫了這些端點，使用了所有標頭或僅使用了幾個標頭。他們總是回答正確的地址。

應要求提供的其他資訊：

預檢請求：

OPTIONS /media/1.0.0/rtsp/hls?feedUrl=https://live.monuv.com.br/a1/14298.stream/str27/chunklist.m3u8?m_hash=khV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%3D 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://live.monuv.com.br/a1/14298.stream/str27/chunklist.m3u8?m_hash=khV_hCnKG3nhaNCFaYZxBnoMz-99idQVHiQh80ADW78%3D 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=
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

At this response, the browser fails saying that the origin don't match the access-control-allow-origin.

(the first image was from Edge, since the log was more clear; this log is from Firefox)

uj5u.com熱心網友回復：

問題

來自瀏覽器的錯誤訊息（我使用的是下面的虛擬 URL 和來源）可能有點令人困惑：

CORS 政策已阻止從源“https://example.com”訪問“https://api.example.com/”（從“https://media.example.com/”重定向）的 XMLHttpRequest：對預檢請求的回應未通過訪問控制檢查：“Access-Control-Allow-Origin”標頭的值“https://example.com”不等于提供的來源。

這里的關鍵是，正如 sideshowbarker 在他的評論中暗示的那樣，因為您的第一個預檢請求以跨源重定向https://media.example.com/回應，瀏覽器對該資源執行另一個完整的 CORS 訪問控制檢查。但是，由于第一個預檢請求導致的重定向恰好是跨域的，瀏覽器將第二個預檢請求的源（錯誤訊息稱為“提供的源”）設定為，而不是作為，而是作為源！https://api.example.com/https://example.comnull

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

因為https://api.example.com可能不允許（也不應該！）允許null，第二次訪問控制檢查失敗，并且您會遇到煩人的 CORS 錯誤。

Solution

Resist the temptation to allow the null origin on https://api.example.com/, as doing so has serious security ramifications: it amount to voiding the protection that the Same-Origin Policy provides.

Instead, you should get rid of that redirect from https://api.example.com/ to https://api.example.com/ and make your frontend request the https://api.example.com/ resource directly.

Alternatively, if you cannot completely get rid of the redirect but you can change its destination, make it a same-origin redirect (from somewhere https://media.example.org to elsewhere on https://media.example.org).

標籤：redirect null cors preflight

上一篇：父/子/子頁面的add_rewrite_rule()問題

下一篇：表格行中的按鈕重定向到另一個頁面，其中包含Laravel中該行的資料