Distributing my self hosted extension throughout my org?

[Fresh]

Hello, I just want to know if this is even possible anymore, as I'm getting many conflicting advice searching online.

I have a self hosted chrome extension hosted on a site and would simply like to distribute it throughout my Windows based organization. Many docs have suggested that this can be done if you set the ExtensionInstallAllowlist and the ExtensionInstallSources policies properly. In our case we'd be doing it via some Azure AD service that manages policies on everyone's connected machine.

The problem is, those have been set properly, and navigating to the custom .crx url gives a CRX_REQUIRED_PROOF_MISSING error, not allowing the user to install via one click. My question is, is this expected behavior? Has self hosted extensions been blocked entirely on windows machines even on organization managed policies? Or is it only impossible to install via link, and an ExtensionInstallForcelist property needs to be set?

[Pavel Aronovich]

It is better to use the ExtensionSettings policy.

The extension will be installed automatically without user intervention.

суббота, 4 мая 2024 г. в 16:20:40 UTC+3, Fresh:

[Oliver Dunk]

My understanding is that this should still be possible, at the very least for a device which is enrolled in an active directory.

If you'd like to try it out, you might want to consider using the extension update testing tool: https://github.com/GoogleChromeLabs/extension-update-testing-tool

If you put a hello world extension (or your own) there, it will give you the registry commands needed to install via policy on Windows. Once that policy is set you will be able to click an install button in the tool and see the install flow triggered.

Hope that helps,

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

--
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/c238d896-cb3a-4b7f-9df1-3b1666693de8n%40chromium.org.

[Fresh]

Thank you for the tool. It did indeed work as intended when I click the extension install button with the proper registry settings for localhost. 

However, I decided to add another registry entry so that the ID and source URL matches my currently hosted live extension, and instead of prompting for an install for that url it simply tries to download it.

In fact, simply pasting the url into the header even for the 'working' localhost url (localhost:8080/extension.crx) also fails to prompt for install, instead just downloading. Only the button on the tool actually works.

Is this intended or am I missing something simple?

[Fresh]

Could you clarify the difference between using ExtensionSettings and the more "traditional" policy entries of ExtensionInstallAllowlist and  ExtensionInstallSources?

And in that same vein, which keys are required? I presume just update_url, install_sources, and installation_mode? Or is allowed_types required as well for a self hosted app? Would that be the 'hosted_app' value?

[Oliver Dunk]

There's nothing special about the tool (it isn't explicitly allow-listed) so using your own domain should work.

I believe the URL needs to match the page you are installing from, not the page the extension is hosted at. Could this be the problem?

If you'd like to share some details about where you are hosting the extension, where you are clicking the button and what your policies look like, I'm happy to take a look.

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

[Fresh]

The extension is hosted on an Azure Static Web App that serves a 'chrome-extension.crx' url and 'updates.xml' url. I believe I've set these up correctly along with the manifest.json accessible from the same base url. 

I did do a test and replaced the 'href' in the inspect editor to point to my live extension instead of the local '/extension.crx' and it prompts for install as expected, and was able to check that the installed extension has the expected app id.

My current policies for chrome are simply as set by the tool, with the app id replaced by mine and the url replaced by my domain with a wildcard (https://<site>.net/*).

It's just when I paste the extension's url into the browser instead of using a button href (whether I'm pasting localhost url or the live extension url) it tries to download the file instead of installing it, which makes testing very confusing because how else am I meant to test if my extension url is working with my local policies? 

[Oliver Dunk]

It's just when I paste the extension's url into the browser instead of using a button href (whether I'm pasting localhost url or the live extension url) it tries to download the file instead of installing it, which makes testing very confusing because how else am I meant to test if my extension url is working with my local policies?

Hmm, I'm not sure I understand the question - isn't updating the href of the button a good test?

I'm not sure about all of the nuances for downloads from the address bar but I could see that not working and don't think that would be unexpected necessarily.

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

[Fresh]

Apologies, for the clarity. If I were distributing my extension through a custom built web store via a button, this wouldn't really be an issue, and having it work (locally at least) with the button is promising.

However I don't think there's a way for me to know that triggering a one-click install is only possible via href (or some other nuance), and that I would for some reason need to built a rudimentary html page to test it instead of more naturally just pasting it into the bar?

I've yet to test deployment on my organization machines (I don't manage the policies), but this has been a bit of a headache despite being fairly simple. We have set the allow list and sources and using the url had given us the crx proof error, so we just thought our policy configurations were still wrong. I'm gonna try and get the forceinstall policy so that it just installs it hopefully.

[Oliver Dunk]

Ah, got it. That's completely understandable - I definitely think there is room to make the documentation clearer here and help to set expectations about what is and isn't possible.

I don't think it matters too much in this case, but in case you're curious, I expect the reason this doesn't work is that you are only adding certain sites to the list of install sources. When you paste a URL into the address bar, it isn't being installed from anywhere in particular, so there isn't a URL to check against. Note that we are checking the origin that triggered the install, not the origin you are installing from.

One other piece of context is that we've seen a lot of abuse in the past where policies like this are used to install extensions the user doesn't want. So the conditions required for it to work are quite strict and constantly evolving, trying to find a balance between supporting the good use cases while making it harder to deploy outside of those.

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

[Fresh]

Thanks, I appreciate the technical explanation. It makes sense, and I get that extensions are incredibly difficult to distribute without presenting serious security risks to the end user, so they have to be implemented strictly. For that I am glad there is still an option to distribute a self hosted extension at all.

That said I strongly agree about the documentation. If the restrictions are going to be so strict they should be well explained, little caveats like this and all. The current documentation has most of this done very well, but I think my experience with this is a good example of a pain point that could be polished. Stuff that might be logical for an experienced developer, but docs are often read by people who are new to framework they're working in.

On topic of the original question, the ForceInstall policy worked and we've been able to test the extension on our systems for deployment. The biggest hurdle was indeed in our misunderstanding of how we were 'supposed' to be able to locally test whether the extension install policy was working. It also didn't help that when searching the issue online, it seemed like the 'rules' for self hosted extensions seemed to change a lot over time, so many answers were outdated as, like you said, the requirements are constantly evolving. For a good reason, but it just makes it more difficult as a developer to keep track of what's 'correct' which definitely needs to be offset with crystal clear docs.

But, yes, thank you, this has helped me understand the whole process much better, and I'm just glad it works and wasn't as complicated (if finnicky) as I thought.