I am a developer looking for the best way to set up different schools with their own custom, private extensions (ie School A should be the only one with access to Extension A). Theoretically, I am aware that there are a few ways to get a custom, private extension pushed out on a domain:
Host the .crx on a server and click "Specify a Custom App" in the management console.
Create a Domain App by uploading a zip to the Chrome Web Store
Upload the extension from my developer account to the Chrome Web Store and publish to a single "trusted tester," or make it unlisted
Option (1), hosting the .crx, has not been working. I am not sure why, but the extension is simply not pushing out. I link directly to the crx file, which has the right ID and MIME type, still, no dice. If anyone has any tips or suggestions for getting this to work, I would love to hear them!
Option (2), having the school create a domain app, seems a bit inefficient because it requires all schools to upload their own zip. So essentially I would have to email a zip file to the school, and have them publish it. All updates to the extension will also require a similar process, so this doesn't seem ideal.
I doubt that option (3) would work. If I published to the admin as a "trusted tester", I don't think that the other people in the domain would be able to access it. If it is unlisted, I do not know how an admin could find it in the Chrome Web Store dialog. Also, I would rather avoid security through obscurity.
Has anyone had success with hosting the extension and using the Specify a Custom App feature? Any other suggestions for getting a Custom Extension pushed out by the management console? Thanks so much!
To get option (1) working from the management console, it is important to specify the correct extension id and a valid update xml url (not a crx).
One useful feature Google offers that you can use is getting the extension id and the version from the update request.
For instance, you can create a update.php file that outputs an xml file specific to each extension and version. See http://developer.chrome.com/extensions/autoupdate.html under "Advanced Usage".
For more info on packaging an app or extension for managed chromebooks, see https://support.google.com/chrome/a/answer/2714278?hl=en.
Related
For internal use in my department I wrote a Chrome extension. It works fine in developer mode and I delivered it to my colleagues by e-mail attaching the .crx-file. They opened chrome://extensions and drag-and-drop it there. The message
drop to install extension
appeared, Chrome installed the extension and it works like a charm.
Nevertheless, on the very first restart of Chrome, a message appears that Chrome deactivates an unsupported extension.
A link to the help page Extensions disabled by Chrome is added to the message, and states:
To protect you while you browse, Chrome only lets you use extensions that have been published on the Chrome Web Store.
While I understand the reason, is there any other way a user can explicitly tell Chrome an extension is safe? Some effort is acceptable as publishing the extension to the webstore is not.
I have no administrative access, so no changes to registry nor active directory are possible.
As noted, you need Active Directory level policies to whitelist / auto-install extensions. See Policy List.
Chrome will use many defense mechanisms to detect and fight other trickery. The stance is simple: anything an unprivileged user can do any other software can do to implant malware.
However, you should consider publishing in CWS.
This can be done unlisted; unless someone has the listing link, the extension won't be discoverable.
This approach will present a risk of a leak of the link, but with your current delivery mechanism crx can leak as well; in general, copy-protecting extensions is basically infeasible.
This can be done with enforced control over accounts; you can publish to a Google Group of "trusted testers", who will be the only ones to see the listing.
Won't work if you're not allowed to sign into your Google accounts in Chrome.
This can be published with enforcing access only to your domain's users - if you use GApps for your work.
All of the above might not work if your extension is somehow questionable by CWS policies; if you can't publish for this exact reason, and can't use AD policies, I'm afraid you're SOL.
There isn't a way without domain level management to make this work. You can't just have the user "say" it is safe, since the user "saying" something could very well be the attacker. Any mechanism put in place to get around this would simply be used by attackers and unthoughtful companies to add more junk into your browser.
I have been developing a chrome extension and now I want to create version 2 with database support. For this I am going to use Firebase.
I need to create a file in my extension where I add the details about the firebase connection, api key and url etc..
After reading this question: Where does Chrome store extensions?
I went to look for mine. and boom there it was. I could open the files for the extensions and see the details I added about my firebase connection.
However, I am unsure as to whether I could see it because I am the developer and its on my machine. I do not like the idea of having my access keys available nor url.
Not that I think anyone would sabotage it, but I would hate to be billed for over usage of my requests etc..
I've prepared and published on my website an installer package with the software I developed. The package is compiled and bundled into .exe file using WiX toolset and contains no viruses or malware. Next when I try to download the file I get a notification from Chrome that it's blocked due to malicious content.
Malicious content warning
I'm really upset that my customers being misinformed with such warning. Any ideas how to get around it?
Google created this page for developers - https://support.google.com/webmasters/answer/3258249.
Even though it doesn't say it on there, almost all auto-detection software will not block software that is digitally signed (and there is no bad reputation associated with the signing certificate).
If it's a simple file, just upload it to Google Drive or DropBox, and generate a public link for it and then share it on your website.
You can also shorten that link, if your application provide this service, or via goo.gl, in order to view clicks' count.
If any developer come across this issue, I manage to resolve it by streaming the downloadable file instead, via different URL (which doesn't have the file name and its extension with file's full path on your hosting).
Doing so by manipulating the response header, will fix the issue.
Here is a useful link about streaming a downloadable via php script
I noticed that in chrome://extensions you can see a "Not from Chrome Web Store" message under extensions that were installed through, e.g. drag and drop into the extensions page. Screenshot of what I am talking about:
I was wondering if there is any way of getting that information from an extension API? I have played with the chrome.extensions.management API, but the only information that gives is the installType field, which is 'normal' for both Web Store and drag and drop installs. - https://developer.chrome.com/extensions/management#type-ExtensionInfo
Am I missing something, or will we just have to wait for an update to the management API?
Could you simply check if the updateUrl property is equal to https://clients2.google.com/service/update2/crx? I believe extensions in the Chrome Web Store must have that update URL, but I'm not sure about the other way around.
Either you install by drag-and-drop or you install form web store, both are called normal install type. Ultimately, you are trying to install the .CRX file, so it means it's a normal install type. Here is the help article. Search for "installType" and read description for "normal" in mentioned article.
I'm working on a Google Drive interface for Emacs. The concept is that Emacs could provide a platform-agnostic way to load, modify and save text documents stored in Google Drive. I've registered my app and can authenticate with OAuth2 and get a file listing with the Docs List API, but when I try to execute an Insert with the Google Drive API, I see an error:
"The authenticated user has not installed the app with client id ..."
Reading further, it seems I need to publish my Emacs application in the Chrome Web Store to get access to the Drive API. That doesn't make sense to me...I noticed that there is a FUSE project in development for Google Drive, which suggests that native development is possible. When I skimmed the code, however, I didn't see a Chrome Web Store component to getting it working.
Am I trying to misuse the API, or is there an route to make this work that makes more sense?
EDIT:
According to Ali Afshar, of the Google Drive team, installation is no longer required to use this API. So what follows may no longer be relevant, but will be left for historical purposes.
So, first off the API does not support application development in the sense that we are both doing it, I wouldn't use the word native though. The good news is I have been doing some research and Google Drive is really just a rebranding of Google Docs. So the Google Docs API could be a good choice as well for the same purposes.
Anyway, here's the steps to solve the error: "The authenticated user has not installed the app with client id ..." Which is a 403 error, for the sake of this answer. These steps assume you have set up an app in the chrome web store as is required, and installed it. I am working on my local machine too, with my project: http://github.com/tom-dignan/gdrive-cli which I have gotten past this error, so I think you should keep plugging away at your emacs version, because I think we can make this work.
a. Open the Google APIs console.
b. Confirm you've already enabled the apis under "API Access" both the API and SDK for Google drive should be enabled. There you get your client secrets/api keys and such. I am almost positive you've done this already, so go ahead to C. (this is here for others who may have missed it)
c. In the left navigation bar, under "Drive SDK" you will need to do the following:
Add a "Support URL" (required)
Add at least a small 16x16 application icon (required)
Add "OAuth Client ID (Required)" under Drive Integration (I was just tinkering and this seems to be the key field.)
Add "Open URL (Required) URL to open for your app from the google drive UI."
Check off "Multiple File Support"
Add some MIME types and file extensions, "text/plain", and txt for example
Add the the auth scopes:
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
Don't bother trying to add the auth scopes for Google Docs here, because it won't work. Google does not want us to use it that way because files that drive apps create should be private to that app. Integration with Google Docs will have to be separate.
Now I know you must be thinking "why do I have to add some of these..." It's because the form makes them required fields. In mine, I put a couple URLs that point to static HTML pages.
Once you've done the above, clean up your state and reinstall your chrome app. Then try your code again, and it should stop giving you a 403.