Odd scenario.
We have a single app fronted up by Auth0. First time users go to the app, get redirected to Auth0, enter their email address and reset their password. When they then logon they are prompted to register for Guardian MFA.
This works fine for 99% of users but we have a handful who never get the Guardian enrollment option and get the ‘Looks like something went wrong’ error instead. If I follow the above process for their accounts as a test (on my PC) everything works fine.
The last logged entry for their account is the password reset.
All affected users are from the same 3rd party company so the assumption is that that company has something ‘local’ that is breaking something - maybe a firewall, maybe a browser lockdown policy etc.
I know that above is vague - but hoping someone may recognize the symptoms…
Hey there @alistair.packard!
Indeed it’s quite an odd scenario. I’ve passed it through toi our developer support team for more insights as maybe they experienced or solved something similar in the past. Will get back to you as soon as I know something more!
Guardian uses WebSockets to talk to the server. While this is mostly OK with most firewalls nowadays, it might be possible that some policy is actively preventing this communication.
I would check if WebSockets are available in their network. An affected user can record a .HAR file and send it to you to post here (remember to delete any visible password in the .HAR file) or directly use the browser’s developer tools to check if some connection is being blocked when doing the MFA flow.
1 Like
Thanks very much.
One thing that may look like the cause is capitalization in the email address when used as the logon username - is this case sensitive (but maybe not when resetting passwords?)? It can be hard to perform proper diagnosis with non-technical users via email but this has seeminly fixed it for one reported user.
Capitals did not solve the issue for the other users. I have seen some mention of websockets being corrupted by some ISP’s - I assume because they are proxying\caching content etc - if this is the issue, and we cannot get the user to change their ISP! - is there any fix possible?
Hi. We have got a HAR file for a failed session.
We can see the MFA widget downloading, then nothing:-
If I ran a similar trace on my PC the next request is a HTTP 201 that creates a websocket connection - {“state_transport”:“socket”} so def looks websocket related; does this mean the client PC does not support websocket (OS\browser)?
[Update]
Hi - any suggestions for this? Does this look like a client build issue?
Hey @alistair.packard!
When it comes to those 404s in terms of getting Gravatar data it’s like the resource under this link that the request is looking for is broken or the link might be dead which as far as you’ve described the case is quite impossible.
When it comes to the websockets it seems like it is a client build issue and as Nico suggested lack of support probably from the browser of the client. @nicolas_sabena do you have any other suggestions on that?
Can you DM me the .HAR file @alistair.packard?
Hey Community Developers! We’ll provide you with the solution to this thread once we establish a solution based on the HAR file that we’re looking into in DM. Thanks for co-operation!
Hi @alistair.packard. A quick update on this in case you missed the DM or if it helps other users.
I’ve reviewed the .HAR file, and from the HTTP perspective it’s like the actual MFA transaction is never started from the browser (the https://{tenant}.guardian.eu.auth0.com/api/start-flow request is missing).
Unless the .HAR recording was interrupted (I don’t think that’s the case), this suggests some kind of failure on the browser itself.It might be helpful to you check if there’s any error displayed in the JavaScript console.
Another possibility is that the https://{tenant}.guardian.eu.auth0.com domain is not reachable from the browser, but I would expect some kind of error in the .HAR file if that were the case.
There’s still the possibility that some kind of firewall policy is restricting the socket communication but, again, I would expect some kind of error either in the HTTP traffic (in the .HAR file) or in the Javascript console.
If you have access to these users, can you have them try to browse directly to https://{tenant}.guardian.eu.auth0.com/api/start-flow (should return 404 ) and https://{tenant}.guardian.eu.auth0.com/socket.io/ (should return 400 with {"code":0,"message":"Transport unknown"} ).
