為什麼我的提取請求失敗並出現「跨來源請求被阻止」錯誤，如何使用 CORS 修復它？

跨域請求被阻止：了解CORS 和Fetch 語法

在跨域請求領域，瀏覽器阻止腳本訪問出於安全原因，開發人員經常遇到可怕的「No 'Access-Control-Allow-Origin' header is present on請求的資源」錯誤。要解決此問題，必須理解 CORS（跨域資源共享）的概念及其對 Fetch 語法的影響。

CORS 難題

CORS是一種瀏覽器強制機制，可保護使用者免受其他網站上運行的惡意程式碼存取本地儲存的敏感資訊的影響。預設情況下，瀏覽器會阻止來自 JavaScript 程式碼的跨來源請求，但它們提供了一種放寬此限制的方法，即向伺服器的回應新增 Access-Control-Allow-Origin 標頭。此標頭指定允許哪些來源存取該資源。

解碼語法錯誤

在指定的程式碼片段中，開發者嘗試使用模式：'no Fetch 物件中的 -cors 屬性可停用 CORS。然而，這種方法從根本上來說是有缺陷的，因為 mode: 'no-cors' 有效地指示瀏覽器阻止對回應標頭和正文的任何​​存取。因此，即使伺服器傳送帶有適當 Access-Control-Allow-Origin 標頭的回應，瀏覽器也會忽略它，導致 fetch 呼叫中出現語法錯誤。

mode: 'no-cors' 的陷阱

一般不建議使用mode: 'no-cors'，因為它可以在瀏覽器處理回應時產生意想不到的限制。具體來說，此模式會阻止瀏覽器顯示回應的內容和標頭，這通常是正確處理 JavaScript 程式碼中的資料所必需的。

代理解決方案

為了在不影響瀏覽器安全的情況下規避 CORS 限制，我們可以使用 CORS 代理。代理充當中介，代表客戶端發出跨域請求，並在回應中添加必要的 CORS 標頭，然後將其傳回原始請求者。

Postman 與瀏覽器

需要注意的是，雖然流行的 HTTP 請求測試工具 Postman 預設不強制執行 CORS 限制，但瀏覽器會執行。這種差異源於這樣一個事實：Postman 是一個旨在測試 API 端點的調試工具，而瀏覽器則優先考慮用戶安全性。

總結

總之，模式：「no-cors」僅應在需要不透明反應的有限情況下使用。 CORS 代理程式為跨域請求提供了有價值的解決方案，同時保護瀏覽器安全。了解 CORS 的複雜性並應用適當的技術對於實現網站及其資源之間的安全、無縫通訊至關重要。

以上是為什麼我的提取請求失敗並出現「跨來源請求被阻止」錯誤，如何使用 CORS 修復它？的詳細內容。更多資訊請關注PHP中文網其他相關文章！