如何阻止CORB阻塞对用CORS报头响应的数据资源的请求？

Question

我正在开发一个Chrome扩展，从某些网站向API I控件提出请求。直到Chrome 73，这个扩展都能正常工作。升级到Chrome 73后，我开始得到以下错误:

跨源读取阻塞(CORB)阻塞的跨源响应http://localhost:3000/api/users/1，其MIME类型为application/json

根据Chrome's关于CORB的文档，如果以下所有情况均为真，CORB将阻止对请求的响应:

>

服务器使用 头进行响应，或者如果省略了该头，Chrome在检查文件时会检测到内容类型是HTML，XML或JSON之一 options:nosniff>

CORS不显式允许访问资源

此外，根据“Spectre和Meltdown的教训”（Google I/O 2018），在 调用中添加 似乎很重要，例如， 。

为了解决这个问题，我做了以下更改:

首先，我向来自我的API的所有响应添加了以下头:

Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: Content-Type
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Origin: https://www.example.com

其次，我将扩展上的 调用更新为如下所示:

fetch(url, { credentials: 'include', mode: 'cors' })

然而，这些改变并不奏效。我可以改变什么来使我的请求不被CORB阻止？

Answer 1

临时解决方案:使用run command browser 禁用CORB

Linux上的运行命令示例。

对于Chrome:

对于铬:

类似的问题。

消息来源。

Answer 2

见https://www.chromium.org/home/chromium-security/extension-content-script-fetches

为了提高安全性，Chrome扩展中的内容脚本将很快被禁止跨源获取。这样的请求可以改为从扩展后台页面发出，并在需要时中继到内容脚本。

你可以这样做以避免交叉起源。

旧的内容脚本，进行跨源提取:

var itemId = 12345;
var url = "https://another-site.com/price-query?itemId=" +
         encodeURIComponent(request.itemId);
fetch(url)
  .then(response => response.text())
  .then(text => parsePrice(text))
  .then(price => ...)
  .catch(error => ...)

新的内容脚本，要求其后台页面取而代之地获取数据:

chrome.runtime.sendMessage(
    {contentScriptQuery: "queryPrice", itemId: 12345},
    price => ...);

新的扩展后台页面，从已知URL获取并中继数据:

chrome.runtime.onMessage.addListener(
  function(request, sender, sendResponse) {
    if (request.contentScriptQuery == "queryPrice") {
      var url = "https://another-site.com/price-query?itemId=" +
              encodeURIComponent(request.itemId);
      fetch(url)
          .then(response => response.text())
          .then(text => parsePrice(text))
          .then(price => sendResponse(price))
          .catch(error => ...)
      return true;  // Will respond asynchronously.
    }
  });

Answer 3

null

// contentScript.js
function fetchResource(input, init) {
  return new Promise((resolve, reject) => {
    chrome.runtime.sendMessage({input, init}, messageResponse => {
      const [response, error] = messageResponse;
      if (response === null) {
        reject(error);
      } else {
        // Use undefined on a 204 - No Content
        const body = response.body ? new Blob([response.body]) : undefined;
        resolve(new Response(body, {
          status: response.status,
          statusText: response.statusText,
        }));
      }
    });
  });
}

// background.js
chrome.runtime.onMessage.addListener(function(request, sender, sendResponse) {
  fetch(request.input, request.init).then(function(response) {
    return response.text().then(function(text) {
      sendResponse([{
        body: text,
        status: response.status,
        statusText: response.statusText,
      }, null]);
    });
  }, function(error) {
    sendResponse([null, error]);
  });
  return true;
});

这是我对我的应用程序所做的最小的一组修改，可以修复这个问题。（注意，扩展和后台页面只能在它们之间传递JSON-serializable对象，因此我们不能简单地将Fetch API响应对象从后台页面传递给扩展。）

后台页面不受CORS或CORB的影响，因此浏览器不再阻挡来自API的响应。