Reputation: 43
I am building a Chrome extension for a client that utilizes the Google OAuth2. The extension is highly customized for his company and is meant to be used internally and for security reasons I am supposed to just send him the .crx file, so no Chrome Web store or hosting or similar. I have registered the extension on Google Dev Console and hard coded the received client ID and API key for OAuth access into the app. As such, naturally, the extension works properly in the development. However, when I sent the packaged .crx file to the client and he installed it in his Chrome he receives the following error:
- That’s an error.
Error: origin_mismatch
A native application: HipLead Extension
You can email the developer of this application at: [email protected]
Request Details proxy=oauth2relay755552705 immediate=false scope=https://www.google.com/m8/feeds origin=chrome-extension://hajhlcbhmjjihnbjhjabojkmonelialo response_type=token redirect_uri=postmessage state=515453249|0.4168528853 client_id=898271548842-dhmt34v9rnu3mvbc0sgvobunnjj3qciv.apps.googleusercontent.com include_granted_scopes=true That’s all we know.
I understand that this is the error originating from the fact that, when he installs the extension on his end, his local copy has a different id. Registering that id in the console also wouldn't work as that would require me to insert the new client id into the hard code and then repackage the ext, sending it to him, which would generate a third yet id etc not solving anything. I cannot use the web store or online servers and I would like to avoid making a 'configuration' pane in the extension for him to enter the client id if I can. Is there a way to predict the id and hard code it before packaging and sending the finished extension?
Upvotes: 1
Views: 669
Reputation: 77521
Installing an extension via a CRX file by simply dragging it to Extensions page is not supported anymore: [1] [2], at least on Windows and OS X.
There are two methods left, unpacked install and enterprise install.
Unpacked install means just extracting the extension to a folder and then loading it as you would for development. Then, indeed, the ID would change; but there is a way to pin it down by providing a "key"
field in the manifest. See more details in this FAQ entry.
In a serious enterprise environment though, such a method is quite unacceptable. The "golden standard" method is Enterprise Policy install. This will allow keeping the CRX file on some internal server and auto-update from there. Your client needs to seriously consider this plan.
Upvotes: 1