I am trying to implement a Google+ sign in option as part of a chrome extension using the one-time code flow as described here.
While making a request using the javascript Google API package a popup opens with an "origin_mismatch" error. This is obviously since I need to add my origin to the relevant Client Id on the Google API console.
My origin is : chrome-extension://<my extension id> however when trying to add that on the API console I get an error saying "Invalid URI: chrome-extension://..." which probably means this scheme is not supported.
Any idea what I can do instead?
I've faced the same problem. I think Google has changed the validation for javascript origins and doesn't allow origins from chrome-extension any more. Google gives you the Chrome Identity API instead (https://developer.chrome.com/apps/app_identity)
But there is a workaround. If you already have at least one chrome-extension://[ext_id] origin in your client ID and you have for example the older version of your extension with this extension ID, you can:
install this extension
go to C:\Users\username\AppData\Local\Google\Chrome\User Data\Default\Extensions (for windows)
find your extension there and open the manifest.json
copy the line "key":"[your_key]" and paste it into your developed manifest
and after next build you should get the extension with the same id as it was in the working one. Also it won't change any more.
Related
I'm trying to use the auth0-chrome package to authenticate my users. I've followed their "Using the Library" section (set up a new native type application in my tenant and configured the Allowed Callback URLs and Allowed Origins). When emitting my authenticate event to my background script and calling the authenticate() method on the new Auth0Chrome instance, I get the error
Authorization page could not be loaded
My current theory is that since the allowed origin's format in the example is https://<extension-id>.chromiumapps.org and I can't currently access that page. Is there a certain visibility level for a Chrome extension to have a valid URL (e.g. atm for a privately published extension, the *.chromiumapp.org URL is invalid).
I thought a code example is not needed, since I'm literally using the default example's code with my extension ID replaced.
I have double checked and my ID is the same for the auth0 application config, my unpacked extension in my browser and for the configured code. I'm using a manifest key to persist the extension ID if that's of any value.
So turns out the documentation lists the callback url example as https://<yourchromeappid>.chromiumapps.org/auth0, but it should be https://<yourchromeappid>.chromiumapp.org/auth0 - without the s at the end of chromiumapp.
That was the only change required to making it work. I've proposed an update for their documentation as well.
I use U2F to authenticate users to the web service.
When I deploy U2F with a single-facet AppID in the form of "https://example.com" everything works great. However, when I try providing multi-facet AppID to Chrome browser during the Yubico key registration or authentication, Chrome rejects the AppID immediately (I'm getting error code #2) instead of downloading the JSON file.
Question: is support for multi-facet AppID included in the current Chrome U2F extension (v0.9.6)?
It seems like Chrome is not supporting the standardized way of listing facets (but instead supports another similar way). See this bug report for more information.
A fix has been merged into Chromium:
https://code.google.com/p/chromium/issues/detail?id=471522
The fix will be available in Chrome 43.
I am working on a Chrome extension that needs to call a native application.
As per Google documentation, we are using the chrome.runtime.connectNative method.
However in our extension, it seems that the chrome.runtime object has no method 'connectNative'. When we display the list of methods of the chrome.runtime object, we get the following list (printed by console.log("" + Object.getOwnPropertyNames(chrome.runtime));
getManifest,getURL,reload,requestUpdateCheck,connect,sendMessage,onConnect,onMessage,id
We are using Chrome 31.0.1650.63 on MacOS X 10.8.5 . We have also tried with Chrome Canary (version 34.0.1767.0 canary), we have the same error, with a slightly different list of methods for chrome.runtime:
getManifest,getURL,setUninstallUrl,reload,requestUpdateCheck,connect,sendMessage,onConnect,onMessage,id
So, in both cases (regular Chrome and Chrome Canary), we don't have the 'connectNative' method.
This does not seem to be a permissions problem, our extension manifest does have "nativeMessaging" in the permissions attribute. When we click on the permissions link in the Chrome extension settings, we can see that the extension can "communicate with cooperating native applications".
(sorry I couldn't post screenshots or the full manifest, StackOverflow won't let me paste things that even remotely look like I'm posting an image since I don't have enough reputation....)
Are we missing something ?
The list of properties of chrome.runtime you are getting indicates that your code is running as a content script. Most chrome.* APIs are not available to content scripts. They can only be used from background or event pages, popups, or other extension views you define. So you can use regular extension messaging from your content script to a background or event page, which in its turn can call your native app.
I have developed a Google Chrome extensions that uses YouTube Data API v2. My permission field in the manifest looks like this, because the script is injected in pages under youtube.com and I also need access to tabs:
"permissions": ["tabs", "*://*.youtube.com/*"]
This also works when I do a request to YouTube Data API v2 because the request is done to http://gdata.youtube.com/, so it is the same domain. But now I am migrating to YouTube Data API v3, and the requests must be done to http://www.googleapis.com/youtube/v3/ (note HTTPS instead of HTTP also). However, surprisingly, my requests are working perfectly without adding any new permission.
I know, I am asking something that doesn't seem to be a problem, but personally I consider any behavior that I don't understand in my software a problem. Why does this happen? Am I not supposed to add a permission such as "*://*.googleapis.com/*" in order for my XMLHttpRequest requests to the API to work?
I also have some king of guess about this: HTTP Access Control headers. My requests do send a Origin header with value chrome-extension://myExtensionId. And the answer from the API also contains the following header:
Access-Control-Allow-Origin: chrome-extension://myExtensionId
But could this be the reason Chrome is allowing me to do a cross-origin XMLHttpRequest without any extra permission defined in the manifest? Not sure, and apparently this is not documented anywhere in Google APIs, YouTube Data API v3 or Chrome Extensions developer documentation.
If Chrome does not find the permission in the manifest, it treats a request as a normal request. This means that a request will still succeed when the right CORS headers are set. Otherwise, a request will fail because of the same origin policy.
The Google API JavaScript library explicitly mentions support for CORS:
Making a request: Option 3
Google APIs support CORS. Please visit the CORS page for more information on using CORS to make requests.
If possible, I still recommend adding the permission to the manifest file. For simple requests, this does not bring any advantages. For non-simple requests, this will half the number of requests: Non-simple requests are always preceeded by a preflight (OPTIONS) request which checks if the client is permitted to access the source.
By adding the permission to the manifest file, Chrome will not fall back to CORS, and always use one network request to complete the request. Great!
However... you might think again if you're the author of an already-deployed extension. When new origin permissions are added to the manifest file, the extension will be disabled until the user approves the extension. The dialog box shows "Remove extension" and "Enable" next to each other, so there's a chance of loosing the user.
If you wish, you can overcome this problem by using an optional permission, activated at the options page. Clearly explain in layman language that the option will improve the speed of the extension, and don't forget to mention that additional permissions will be requested.
The Heroku app i'm trying to get to work (code here):
https://github.com/heroku/facebook-template-nodejs
"Unsafe Javascript attempt to access frame with URL" errors occur when the page is loaded in chrome.
The login button takes you to facebook but does not actually log you into the app and gives the same errors.
Has anyone got this app to work on Chrome or can anyone advise as to how to patch it up?
P.S. it seems to work fine on Mozilla.
Almost certain this is a cross domain policy issue, as stated above. Generally speaking, you just need to add the correct header info to the response.
Access-Control-Allow-Origin: *
In Node, I think it is just a matter of adding it as another header in the response, using
response.writeHead
See http://nodejs.org/api/http.html#http_response_writehead_statuscode_reasonphrase_headers
Oh, and there's explicit instructions on how to do it if you're using Express. I see no reason why it can't work using plain old node then.
http://enable-cors.org/server_expressjs.html
So I looked at your link, in your case I think you just have to enter the header info prior to using any other express app methods.
As to why it works in Firefox and not Chrome, not sure. Both support CORS many versions back. Maybe you have some Chrome extension that's interfering.