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.
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'm working on a ionic project and api made in nodejs with sails. Login api is uses the waterlock authentication and send the cookie in header that saved on machine and next time when i hit any other api it will authenticate me using that cookie.
Issue 1:- But i'm facing the issue on safari that safari does not allow me to save the cookie. for allow the cookie i need to change the safari settings after that it's working fine.
Issue 2:- As i said i'm working on ionic 3 app so i'm using tough-cookie in the app to handle the cookie thing and it's working fine on android and browser but it does not working in ios. it does not allow me to save the cookie.
Does anyone have the solution for this? Please help me!!!
that is a known problem of the wkwebview, but there is a solution using the following plugin, you can read more about this in the github thread.
https://github.com/ionic-team/cordova-plugin-ionic-webview/issues/22#issuecomment-398036017
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.
I'm using MVC4 c# and have incorporated a home grown security token service (STS). The user calls the actual web address, and they're passively redirected to the STS login. When they successfully authenticate they're redirected to where they're supposed to go, which was all urlencoded in the URL on the redirect to the sts.
Upon logout, we call:
this.Session.Abandon();
this.Response.Cache.SetCacheability(HttpCacheability.NoCache);
this.Response.ClearContent();
// expires the claims
FederatedAuthentication.SessionAuthenticationModule.SignOut();
FederatedAuthentication.SessionAuthenticationModule.CookieHandler.Delete();
WSFederationAuthenticationModule authModule = FederatedAuthentication.WSFederationAuthenticationModule
Response.Redirect(WSFederationAuthenticationModule.GetFederationPassiveSignOutUrl(authModule.Issuer, authModule.Realm, null));
Everything seems to work great on the desktop version of our app. The user is back at the STS login page, and the URL shows wlogin1 (and lots of other stuff) and will allow the user to login again without issue. The url is exactly the same as when they first were redirected to the STS. Perfect, and this is what I want.
Now, when on mobile, which by the way uses the exact same domain/controller/Methods, it just uses jQueryMobile and different partial views, the logout appears to work and the user is brought back to the STS login. This time, however, the URL only shows the Domain/Controller/Method that was actually called from the mobile actionLink used for Logout. When the user tries to login again, the login is always unsuccessful because this link isn't appropriate for an sts login.
Thoughts on how to fix this, or what's wrong? Please let me know if you require any clarification. Thanks!
I was able to fix this!!
Looking at the headers for the mobile site it showed:
X-Requested-With: XMLHttpRequest
So, my logout was attempted with ajax and something wasn't working. This was the only difference between the desktop and mobile headers (besides user-agent, obviously). Started poking around this as the issue.
Within one of my mobile-specific scripts I added the following within the mobileinit. BINGO! Wow, what an easy solution for such a confusion problem.
$(document).bind("mobileinit", function (event) {
$.mobile.ajaxEnabled = false;});
Make sure that you correctly load your libraries too!
I have loaded my jquery libraries in this order:
jquery
mobile jquery init file (the stuff above)
jquerymobile
jquery validation
everything else
We're using the following jQuery libraries:
jquery 1.9.1
jquery-ui 1.10.3
jquery.mobile 1.3.1
jquery.validate
Hope this helps others!
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.