How to remove "origin" request header in manifest v3 ?

[卓易儒（Steven Cho）]

Because we want to send requests to selenium server version 4 through chrome extension, but selenium server does not accept origin request header (chrome-extension://*), so we want to block origin request header.

In manifest v2, we have achieved this with chrome.webRequest.onBeforeSendHeaders.addListener and webRequestBlocking, but now we have to migerate to manifest v3.

This picture is that we use  chrome.webRequest.onBeforeSendHeaders and webRequestBlocking to block the origin header.

I have tried to use chrome.declarativeNetRequest for implementation, but I have been unable to achieve my goal. I don’t know if it is because there is an error in the settings of rules.json, or because v3 cannot remove the origin header.

This picture is the setting of rules.json.

Please give me some suggestions.

Thank you

Best Regards,

Steven Cho

[PhistucK]

>  I don’t know if it is because there is an error in the settings of rules.json

Easy to check, try to remove a different header (maybe a header that you added yourself, for example).

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/bba30ed3-a1a3-4619-bf62-b6f0ca9d66fdn%40chromium.org.

[wOxxOm]

Your "urlFilter" is incorrect. As the name suggests its purpose is to match the URL, which is a property of a network request and not of its header that contains arbitrary values.

declarativeNetRequest doesn't provide a way to match requests based on the value of a request header. You can open a new issue in https://crbug.com suggesting to implement it. Currently I see only issues about conditional handling of response headers.

Assuming these requests are made by a script running in the extension process (i.e. not a content script) like the background/popup/options script, the workaround is to use initiatorDomains to strip the header on all requests made by the extension.

If your extension id is pinned to a constant value, you can do it in rules.json:

[{

  "id": 1,
  "action": {
    "type": "modifyHeaders",
    "requestHeaders": [{ "header": "Origin", "operation": "remove" }]
  },
  "condition": {
    "initiatorDomains": ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"],
    "requestMethods": ["post"],
    "resourceTypes": ["xmlhttprequest"]
  }
}]

Otherwise this must be done in the extension script like the background script using chrome.declarativeNetRequest.updateDynamicRules and not inside rules.json because json doesn't provide a placeholder for the current extension id.

chrome.runtime.onInstalled.addListener(async () => {
  const rules = [{
    id: 1,
    action: {
      type: 'modifyHeaders',
      requestHeaders: [{ header: 'Origin', operation: 'remove' }],
    },
    condition: {
      initiatorDomains: [chrome.runtime.id],
      requestMethods: ['post'],
      resourceTypes: ['xmlhttprequest'],
    },
  }];
  await chrome.declarativeNetRequest.updateDynamicRules({
    removeRuleIds: rules.map(r => r.id),
    addRules: rules,
  });
});

Another workaround is to force-install it via policies so that it can keep using webRequestBlocking with the old MV2 code.

[Yi Ju Cho (Steven Cho)]

Thanks for your advice.

I'll try the solution you provided first.

wOxxOm 在 2022年12月20日 星期二晚上10:39:11 [UTC+8] 的信中寫道：