When implementing WebAuthn authenticator registration on my site, I ran into the issue that during the attestation / registration process, Safari returns a modal saying "The operation cannot be completed" after I attest using one of my devices. The process works on other browsers, but fails on Safari.
The Error Message
This is because Safari fails WebAuthn registration for any attestation request asking for an additional attestation statement via the attestation conveyance.
I couldn't find this documented anywhere, but I played around with the Auth0 WebAuthn registration debugger and came to the conclusion that the "attestation" field was what was causing this popup. I would assume that Safari is being super defensive against any additional data being given about WebAuthn enabled devices via the protocol?
But in summary, ensuring:
navigator.credentials.create({
...
attestation: 'none',
});
worked to prevent the popup for me.
Related
After scouring the web for an answer to this question, it's still unclear to me whether electron supports authenticating users via public key credentials and the WebAuthn specification.
Since v4+ (Chromium 69), electron has had support for both navigator.credentials API and the PublicKeyCredential interface. However, attempting to create a new credential using navigator.credentials.create() results in the request timing out (if PublicKeyCredentialCreationOptions.timeout is set). Additionally, PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() resolves to false which indicates that platform authenticators such as Windows Hello and TouchID are not supported in electron.
In Chrome and other supported browsers, the call to navigator.credentials.create() results in an authorization prompt where the user can enter their security key (eg. biometric scanner or physical usb device). Has anyone had success in implementing similar behaviour an electron app?
can not login itunesconnect
The page give the warning 'Failed to verify your identity, Try again'.
Do somebody face the same problem?
If you are connecting with a VPN, try changing it or try connecting without any VPN.
I couldn't login to anything apple in a web browser: appstoreconnect, developer, icloud, or apple.com. I could install new apps on my iPhone, and edit account settings using the iPhone and my password.
I tried logging in from different browsers, OSes, devices, IPs. I tried browsers with temporary profile (cleared cache/history/everything). Didn't make a difference. The same error popped up: Failed to verify your identity. Try again. The browser inspector tools said a 409 and 401where occurring when trying to get the 2FA after correct credentials entered.
I tried another apple id and without a hitch it asked for the 2FA code.
I turned on 2FA using my iPhone. Didn't make a difference for logging in via web browser to apple sites.
I had to contact apple. The second representative and I agreed that it most likely was a server side issue. He escalated it to engineering. The next morning, all my apple site browser sessions had "forgotten" my apple id. I was able to login now and enter my 2FA code as expected.
Finally, without no reason, I can login.
Had same issue. Ultimately what made it work was that I unlocked my iPhone and then on my laptop I tried itunesconnect again. This time the 2-factor authentication kicked in, and my iPhone showed a popup asking me to verify my laptop. Then it all worked.
It would appear that the new Safari cross-site tracking functionality is interfering with Google's OAuth2 implementation (at least in google sign-in for websites). I'm experiencing this issue with a project I'm currently developing, and would appreciate advice from anyone who has ran into the same problem.
Further details:
With all cache/cookies cleared, the sign-in flow works properly on first login.
Upon refreshing, entering the sign-in flow recognizes you are already authenticated with the OAuth provider, opens a popup and immediately closes it (this is expected behaviour for already allowed sources).
after the popup closes, the finality of the auth flow is broken, and silently fails with no errors thrown inside the code, and no logged in user returned.
Unchecking the "prevent cross-site tracking" option allows the sign-in flow to behave as intended.
Unfortunately, I experienced the same problem with Safari.
In my case, as others reported on the issue you created on GitHub, I was using the redirect flow.
In a recent attempt, I changed the ux_mode to "popup", and it worked.
It is really bad that Google left this abandoned for two years.
We are setting up a web app which serves as a wi-fi hotspot using coova chilli and the Javascript Facebook SDK.
The app has a "login with facebook" button that, once clicked, calls the FB.login() function, which opens a pop-up window where the user can insert his credentials and log in.
This solution is working correctly in desktop browsers but it's not working in mobile devices.
These are the problems I encountered:
Android device - When I connect to the wifi network, the system prompts a notification who says "Sign in to wifi network". Once clicked, the captive page opens up correctly. But when I click the fb login button, I am redirected to the url "http://m.facebook.com/v2.8/auth ..." which is correct, but then the windows freezes and I can see only a wsod.
IOS device - same as before, the cna triggers, the redirect to the fb login page works, but once I insert my credentials, the only thing I can see is a wsod.
Both issues can be bypassed by including apple.com, google.com and other domains used for auth in the hotspot walled garden, and then the user can log in to the network by using the device's browser - Safari or Chrome, it works - as pointed out in this discussion Facebook login on Apple CNA.
The thing is, we want to make it work on the "normal" workflow, that is, to make the app work correctly within the IOS captive network assistant and the Android "sign in to wi fi" functionality.
Do you have any idea how can we solve this? We searched far and wide without any success. Thank you.
EDIT
Solved by using PHP SDK instead of javascript. By generating a login link as explained here. This works also on mobile captive portal assistants such as ios and android ones because the fb login page is opened in the same window and not in popup/iframe. I hope this helps others that may encounter the same problem.
We are developing applications for different platforms including ones with no browser interaction support. And we have decided to emulate browser from our application. So is it ok with Facebook's TOS?
This theme have been mentioned already in this topic (the last post):
http://facebook.stackoverflow.com/questions/4000896/logging-into-facebook-without-a-browser#comment4285566_4000963
By emulation of browser I mean following:
We are getting the user login HTML form and fill it with information that user supplied. Then we are sending it.
When we are receiving the authentication page we are asking the user to authorize the Facebook application to post messages.
If user agrees then we are sending authentication form and then get access token.