为什么我的提取请求失败并出现'跨源请求被阻止”错误，如何使用 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中文网其他相关文章！