In my scenario, I have a Chrome extension that is self hosted, and would like to specify the update_url outside of the extensions for flexibility.
Is there a way to specify the update URL outside of the manifest, or even outside of the extension (for example, in the registry, or chrome storage area)?
You can't.
According to documentation, you have to provide an update URl on the manifest, and that manifest can't be altered in runtime for security reasons.
What you can do is provide an update url that and change de target XML as you need on your server. It can also be a redirect link, for example.
Related
We'd like to develop a Google Chrome extension that is managed centrally, e.g. by MS Active Directory Group Policies.
How do we centrally distribute domain/customer specific configuration for such an extension?
Our users are mostly Windows users in the same domain, but we can not assume that they're logged in to any particular G-Suite organisation.
It does seem possible to create Active Directory Group Policies to install a particular extension for all users. That same article does however say:
Unfortunately I was not able to come up with a solution concerning the centralized management of Chrome extension settings. Some extensions, for example The Great Suspender, come with additional options for the user to configure. As said, I was not able to find a way how to manage or configure these centrally.
So now that the extension is installed, how do we configure it?
Since it is our own extension, there is more freedom. I'm thinking with a Group Policy, one could install C:\some\extension-file.json and then run
google-chrome --headless file:///some/extension-file.json
If the extension intercepts that (as e.g. ViolentMonkey does) but only if it is a file:// URL, I guess that could be brought to work. But I'm hoping: Can you come up with something more elegant?
How do we centrally distribute domain/customer specific configuration for such an extension?
chrome.storage.managed is the specific answer for that need. Quoting the docs:
Enterprise policies configured by the administrator for the extension can be read (using storage.managed with a schema).
With that in mind, you have to do the following:
Provide a schema for the storage via the storage.managed_schema key in the manifest. An example is given in the documentation.
Present values expected by the schema via GPO / registry as described in admin docs.
You can verify that the policy-mandated values are loaded by observing chrome://policy.
You can then use chrome.storage.managed as you would any other chrome.storage (though it is read-only), including watching for changes with onChanged.
We have created a Chrome Extension that is a companion to web sites that we host for our customers. These web sites are hosted under our domain name and interact with the extension using external messaging and relying on the sites being configured in the manifest similar to the following (abcdefg.com is a ficticious domain name):
"externally_connectable": {
"matches": [ "http://*.abcdefg.com/*", "https://*.abcdefg.com/*"]
}
This works great in these cases. However, we have a subset of customers that prefer to host the website themselves under their own domain. The problem is that we do not want to update the extension manifest for the published extension to include all of these sites.
Is there any option of distributing a version of the extension (on Windows) where the "externally_connectable" site list can be set upon installation?
Thanks to kzahel for highlighting the obstacles I was facing and thanks to wOxxOm for providing a solution that will work.
Rather than trying to find a way to override the "externally_connectable" matches configuration upon installation, we found the easiest alternative was to avoid external messaging and use messaging via a content script instead.
The following is a copy of the solution posted above by wOxxOm:
chrome extension - alternative to externally_connectable?
Unfortunately there's no way to do this. You'll need to create a custom extension for every customer with their own domain name. Luckily, there is an API for updating the extension, so you would be able to at least update multiple extensions without too much difficulty. However, the 20 extension limit per account would be a little annoying. I think you can get more extension allowed per account by creating a publishing group and assigning the extensions there.
You could if you are willing to have customers install this in developer mode. That would bypass the 20-extension limit.
So I've built the main functionality for an extension already, and have it uploaded as a web page on my server. I'd like to have it interact with any page a visitor goes to though and not just my page on the server. It's just the HTML/CSS/Javascript and jQuery.
I've been reading the documentation, and it says/implies I need to use a content script. I do have this script included as a content script as well though, however I'm probably doing it wrong. Mainly looking for some guidance/direction as to where to go on this.
The extension is to be one that removes all images from a page.
The site is http://199.127.226.221/testsites/chromeapp/
This is the manifest file: http://199.127.226.221/testsites/chromeapp/manifest.json
This is the .crx file: http://199.127.226.221/testsites/chromeapp/chromeapp3.crx
You should supply the extension as a .crx file.
Also it seems you should specify desired urls for content scripts in permissions of manifest
I'm making an extension for Google Chrome and I use code for autoupdating. This is because the extension isn't yet in Google Chrome webstore. But in a few days I will upload it to the Webstore and Google says you can use the Webstores autoupdating. But if I don't want to use that, will my app still update by my own server, like the way it does now?
Thanks in advance!!
I agree that docs are not very clear about this:
If you publish your extension using the Chrome Developer Dashboard,
you can ignore this page. You can use the dashboard to release updated
versions of your extension to users, as well as to the Chrome Web
Store.
But, I've tested it myself and your update_url setting in manifest.json will be overridden when you publish your extension via Chrome Web Store (CWS). In other words, publishing to CWS means that you can't use self hosted autoupdating anymore.
The reasons for that, that I could think of, may be as follows:
CWS wants to keep track of each extension stats (i.e. number of users using each extension)
privacy concerns (people don't want you to track them when they update extension)
security concerns (each extension update must go through CWS verification process)
If you want to track people (please don't) use Google Analytics on i.e. background page of your extension.
I have a popular Chrome extension that is being targeted by a specific site and they are messing with our extensions functionality and telling visitors to uninstall our extension. They are detecting we are running in the browser by checking for our manifest file via looking for the URL chrome-extension://our-app-id/manifest.json. Is there anyway I can prevent this?
I tried using content-security-policy but that seems to only help with cross-scripting. If not seems like a security hole on google's part; I don't want sites knowing what extensions I am running in my browser.
Manifest version 2 that is tentatively scheduled for version 18 should fix this.
[...] today, all the resources inside your extension (e.g., images)
are visible to web pages. We're changing the default to "not visible"
and then adding a manifest attribute to let you whitelist the
resources that you want to be accessible to web pages.