开发者问题收集

我可以使用 Chrome declarativeNetRequest 完全替代 Chrome webRequest 吗?

2021-03-10
8346

我发现 chrome.declarativeNetRequest 仅支持静态规则,我想要的是在重定向/请求等操作之前调用一些自定义方法。到目前为止我还没有找到解决方案。我不确定我是否仍然可以在 Manifest V3 下执行此操作。

我的扩展有两个用例。

  1. 在重定向之前,我需要执行自定义方法。
    chrome.webRequest.onBeforeRequest.addListener(
        function(requestDetails) {
            //
            // I can get id from requestDetails.url,
            // then do some custom business logic.
            //
            custom_function(requestDetails.url);
            return {redirectUrl:"javascript:"};
        },
        {urls: [ "url_pattern?id=*" ]},
        ["blocking"]
    );
  1. 在某些请求之前,我想根据用户的浏览器添加/修改 requestHeaders。
chrome.webRequest.onBeforeSendHeaders.addListener(
    function (details) {
        details.requestHeaders.push({
            "name": "User-Agent",
            "value": navigator.userAgent + "version_1.0.0"
        });
        return {requestHeaders: details.requestHeaders};
    },
    {
        urls: ["*://url_pattern"],
        types: ["xmlhttprequest"]
    },
    ["blocking", "requestHeaders"]
);

@wOxxOm 非常感谢您的耐心回答!
我更喜欢 spinner.html。但是我还有另一个问题。

我无法将 regexSubstitution 设置为扩展程序地址,
我可以使用 extensionPath,但是相应的捕获组在这里不起作用。

"regexFilter": "google.com*"

以下都是错误的:

无法使用相应的捕获组。
"extensionPath": "/spinner.html?url=\\0"

无法使用扩展程序的地址。
"regexSubstitution": "spinner.html?url=\\0"

我的配置不正确吗?

1个回答
  • 添加/删除标头只能接受静态值,如 官方示例 所示。

  • 根据响应标头有条件地添加/删除/修改标头,请参阅 https://crbug.com/1141166

  • 超出文档中列出的操作功能的非平凡转换自然无法重新实现。

  • https://crbug.com/1262147 已修复,我们将能够定义一个 declarativeNetRequest 规则,通过 regexSubstitutionextensionPath 重定向到扩展程序内的页面,并将原始 URL 作为参数附加。该页面将充当 插页 ,它将显示某种 UI 或简单的进度微调器,处理 URL 参数,并将当前选项卡重定向到另一个 URL。

    在许多情况下,这种方法会在插页显示短暂时引入闪烁和不必要的视觉混乱,从而使用户感到沮丧,他们可能会完全放弃使用此类扩展程序。从事扩展工作的 Chromium 团队成员似乎认为这种粗暴的解决方法是可以接受的,因此他们很可能会接受它,另请参阅 https://crbug.com/1013582

  • 使用观察性 webRequest(不带 'blocking' 参数)和 chrome.tabs.update 重定向选项卡。缺点是原始请求将被发送到远程服务器。这种方法显然不适用于 iframe,要重定向这些 iframe,您必须注入/声明内容脚本,您的 webRequest 侦听器将向其发送带有 frameId 参数的消息。

  • 保留一个带有扩展程序的 html 页面的可见选项卡,并在其脚本中使用阻塞 chrome.webRequest。当然,这是一个糟糕的用户体验,尽管得到了 Chromium 扩展团队的认可,但由于许多扩展都使用了这个临时解决方案,用户的浏览器将不得不保持大量此类选项卡打开。

附注:通过策略强制安装的扩展仍可使用阻止 webRequest,但大多数用户都不愿意使用它。

woxxom
2021-03-10