GET 请求使用 Basic Auth 从 Postman 工作，而不是从浏览器工作

Question

我正在使用 odata api，当我使用邮递员执行 GET 请求时，工作完美，我得到了预期的响应。

但是当我使用来自我的 React 应用程序的获取请求时，该请求会抛出 401，使用与我之前在 Postman 中使用的相同的标头。它说 Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access. The response had HTTP status code 401.

关于如何解决此请求的任何想法？谢谢！

 fetch('https://api4.successfactors.com/odata/v2/', {
  method: 'GET',
  headers: {
    authorization: `Basic ${auth}`, //auth is the encoded base64 username:password
  },
})
  .then(response => response.json())
  .then((response) => {
    console.log('in response: ', response);
  })
  .catch((error) => {
    console.log('in fetchJobs error: ', error);
  });

这是我收到的 401 ….

原文由 JC Garcia 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

这很可能是因为 Postman 可能没有在您的 — 之前发送预检 GET Options 请求，并且在收到 GET 任何响应后cors 检查（因为无论如何它都没有意义）。

另一方面，当从您的网页运行代码时，Chrome 会执行预检 Options 以确定它允许发送到远程服务器的跨域请求参数并检查是否响应 Options req 具有适当的 Access-Control-Allow-Origin 标头以授权您的 origin （即您正在发出请求的页面的域）。

通常，预检 Options 由浏览器发送到服务器，询问服务器是否允许执行它即将执行的操作 - 在您的情况下， GET 。如果远程（跨域）服务器没有响应 prelight Options 请求，并在响应中使用正确的标头授权你的 GET 那么浏览器将不会发送一个。但是，您甚至还没有走那么远，因为对您的 Options 请求的响应本身甚至没有通过 cors origin 检查。

如果您控制服务器，则需要通过在响应中设置 Options 标头来 Access-Control-Allow-Origin 请求以包含请求页面的 origin 还要设置 Access-Control-Allow-Methods 包括 GET （可能还有 OPTIONS ）。如果您不控制远程服务器，则很可能任何普通的 api 服务（例如您尝试访问的服务）在其后端都有一些配置，您可以在某处设置以授权您的 origin 。

您可以 在此处 阅读有关 cors 行为的更多信息

原文由 Rhys 发布，翻译遵循 CC BY-SA 3.0 许可协议