@rory2 thanks for letting me know! Can you DM me your tenant name?
I still l have this issue!
Clearing cookies fixed it
This is the correct step.
This was caused by an AWS load balancer sending more than one cookie - they resolved this issue, but you may still both cookies and the only way to fix is to clear them.
I’m having the same trouble described above.
The console is telling me: WebSocket connection failed: Error during WebSocket handshake: Unexpected response code: 400.
Clearing cookies or using incognito mode did not fix it. Tested in Chrome, Firefox and Safari.
I’m using the latest MFA widget (Version 1.4) from the CDN server on a hosted Guardian login page. Any ideas?
I am also getting this error in Mac Safari Browser, clearing cache doesn’t resolve the issue.
WE CANNOT CONNECT TO REAL TIME CHANNEL.
I still get this error in Safari
as mentioned in an earlier post - if it would be possible to capture a HAR file of the MFA enrollment process and forward it over to me so we can take a look. At this time, I wouldn’t be aware of any issues.
This is still a HUGE problem.
As per your documentation: https://auth0.com/docs/cross-origin-authentication we are using universal login and custom domain. This causes MFA to fail EVERY time when third party cookies are disabled/not allowed. It does not matter if its Chrome, Edge, Sarari, Brave etc.
If we DISABLE our custom domain the MFA works.
Could you please explain why your recommendations BREAK MFA with third party cookies disabled when your documentation explicitly states that custom domain is the SOLUTION to the third party cookies problem?
Telling our users to enable third party cookies or not using MFA is not a possibility. Blocking third party cookies and using MFA is a absolute must for our users.
So could you please advise on how to fix this.
Edit: Its clear, that the MFA fails because it tries to set at cookie from ourdomain.guardian.eu.auth0.com.
Maybe im blind, but i cant find anywhere to change where the MFA widget is served from, to get rid of this cookie problem.
I wanted to follow up @Thornton and apologize for the delay in a response on this subject. I was hoping to find out if you are still battling this issue with “WE CANNOT CONNECT TO REAL TIME CHANNEL.”. If you are, Im curious on your test device if you are by chance using an Ad blocker? If you are, can you try disabling it and give it another shot? I’m happy to further dive in and troubleshoot this issue with you. Thanks in advance!
We are experiencing the same problem. I just tried locally with Firefox and blocking third party cookies. On our production environment we get an exception, here we use custom domains. In our testing environment, this does not occur.
When a custom domain is set, is there a way to fix the cookies in order for them to be set from that domain?
Tested with no add block installed.