Can't publish a manifest V2 extension for an enterprise usage (And V3 limitations)

[Olivier GINIAUX]

I am developing a chrome extension for my company. In this chrome F.A.Q., it is said that: "However, for complex, dynamic request blocking is still supported."enterprise (or education) use cases"

Unfortunaly, it seems to be false because despite trying to publish to a private usage (company only), I get this error message: "You can no longer publish new Manifest V2 extensions. Try converting your extension to Manifest V3"

This is a problem because my chrome extension don't work with the limitations of chrome manifest V3, this is why I had to switch back to V2. The usecase is very simple, yet I couldn't achieve it. It simply consists in injecting in outgoing requests a new random W3C traceparent header which is a common thing to do (this basically enables us to debug our backend). Because rules must now be set with static values, I can't set a new random guid on every request. I tried changing the guid on every request with updateDynamicRules however it does not seems to handle well requests being concurrent.

It is possible to allow V2 extensions for enterprise usage or -even better- help me cover this basic usecase with manifest V3 ?

Thanks in advance

Here is the manifest V3 code attempt if you are interested:
​function updateRules() {

  // Generate random trace parent

  const traceId = genRanHex(32);

  const spanId = genRanHex(16);

  // Rule that add W3C trace headers

  const rules = [{

    id: 123,

    priority: 1,

    action: {

    type: 'modifyHeaders',

    requestHeaders: [

    {

      operation: 'set',

      header: 'traceparent',

      value: `00-${traceId}-${spanId}-01`,

    }

    ]

    },

    condition: {

      "urlFilter": "*://*.mycompany.com/*",

​      "resourceTypes": ["main_frame", "sub_frame", "xmlhttprequest"]

    }

  }];

  // Update the rules

  let premise = chrome.declarativeNetRequest.updateDynamicRules({

    "addRules": rules,

    "removeRuleIds": [123] // Removing previous rule

  });

  return premise.then(() => {

    return traceId;

  });

}

// Listen for outgoing requests

chrome.webRequest.onBeforeRequest.addListener((details) => {

  let premise = updateRules();

  return premise.then((traceId) => {

  console.log(`> Outgoing request to: ${url.pathname}, with trace id: ${traceId}`);

},

{

  urls: [

    "*://*.mycompany.com/*"

  ]

});

[Bilal Aktekin]

Türkçeye çevir

iPhone’umdan gönderildi

Olivier GINIAUX <ogin...@smartadserver.com> şunları yazdı (29 Haz 2023 17:19):

I am developing a chrome extension for my company. In this chrome F.A.Q., it is said that: "However, for complex, dynamic request blocking is still supported."enterprise (or education) use cases"

--
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/b0a2d6a8-f0b6-43fd-acb5-35499e28c275n%40chromium.org.

[Oliver Dunk]

Hi Olivier,

The quote you saw is actually referring to the fact that for extensions force-installed by policy, you can use the webRequest API with the blocking option in Manifest V3. Knowing that, do you think publishing an MV3 extension would work for you?

It's no longer possible to submit new Manifest V2 items to the store which is why you were seeing that particular error.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--

[Olivier GINIAUX]

Hi Oliver,

I tried making the extension work with MV3 but It seems the static rules are too restrictive to be able to change the headers on each outgoing request. I hope there is a workaround, but so far I don't see any (it seems the rules don't update synchronously as they're set, but I couldn't find documentation material on this)

[Simeon Vincent]

You're correct that dynamic and session Declarative Net Request rules do not update synchronously. Similarly, modifications to DNR static rulesets are not performed synchronously. To the best of my knowledge the only ways to modify a request in flight are with the Web Request API or by using the Debugger API and Chrome DevTools Protocol.

To reiterate Oliver's point, Manifest V3 extensions that are force-installed via enterprise policies (for example, ExtensionSettings) can continue to use the "webRequestBlocking" permission and event listeners registered with the "blocking" option in the extraInfoSpec array in Manifest V3. Testing these extensions is a bit cumbersome, though, as it requires you to manually pack the extension, host it, and set up Chrome policies to install it.

Simeon - @dotproto

incremental.software

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/d1f9f483-d547-4287-880f-a48665191b9en%40chromium.org.

[Oliver Dunk]

Thanks Simeon - ++ to everything he said!

The recently released extension update testing tool is a good option for this: https://github.com/GoogleChromeLabs/extension-update-testing-tool. If you create an MV3 extension which requests the webRequest and webRequestBlocking permissions, and host it using that tool, following the steps to "install via. policy" should give you an extension which can access chrome.webRequest and make use of the "blocking" option.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[wOxxOm]

To test webRequestBlocking conveniently, exit chrome and start it with a command lie switch --allowlisted-extension-id=ID

where ID is the id of your unpacked extension.

[Olivier GINIAUX]

Unfortunately we are not looking for force-installing this extension. It is simply a tool that our developers are free to install and use. We do not have an on-premise chrome web store, the extension is uploaded to the chrome web store but simply private to our organization. The Chrome devtools protocol seems very overkill for this simple usecase 😕

[Oliver Dunk]

Thanks for the extra information, that makes sense.

I would actually say that the chrome.debugger API seems reasonable here. It does show some additional UI, but I think that disclosure that the requests the site is making are being handled differently could be useful to developers.

I do appreciate that this is a little bit clunky. Long term, I'd personally love to see some sort of basic scripting language where you can do some basic things (like generating random IDs) in DNR.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB