We have an aggregate verifier set up successfully (called grappa-social) with several users logging/signing up every day. We onboarded a user today who had a very hard time logging in:
The user select his social account, and was redirected to cyan.openlogin.com
The screen loaded for more than a minute, afterwards we saw the Unable to detect login share from the Auth Network error on the users device (the one with slow internet connection or vpn being enabled)
After several attempts, we started getting the recovery email flow to get a backup phrase (and we have mfaLevel set to none)
The user got his backup phrase but had trouble logging back in
@shahbaz we’ve updated all packages to the latest version, however we are not able to reproduce this so I can’t tell if this will occur again.
Do you mind providing us with an explanation of what happened:
Are there any other instances where we’ll see the error we saw? Like timeouts in background API calls?
Why did the user see the MFA prompt although we opted out of it?
The specific user who encountered the issuer eventually enabled MFA, can we disable it for this user? Will he see this screen every time he logs in? Will he see it when logging in from a new device?
Our customer base are not the average consumer, we can’t really afford this happening on a regular basis and need to get to the bottom of it every time so your help here will be very appreciated
It’s possible that those users had previously enabled MFA when the option was available. It’s likely that it was an option from the start, but perhaps it was later disabled.
10x for the help @shahbaz, I elaborated more on Discord but in short:
We can’t see the error message, with the redirects it’s not something we can track ourselves and refactored the auth mechanism isn’t realistic for us at all.
This is the first deployment of the system and project, that user has never signed in before (to my knowledge at least). We deployed with mfaLevel: 'none' from day one
When this error originally happened, it was affecting only that user. So most of the troubleshooting articles pointing to the code/verifier configuration are probably irrelevant
I’ll emphasize again - for the last week we’ve been encountering errors on a daily basis, usually with one or two users signing in for the first time and sessions being reset after a couple of hours (instead of a week like we set it). We need something better than a retroactive investigation, so even a face to face with you guys so we would know how to act better when this happens will be of great help
I will pass this along to the product team. In the meantime, could you please provide me with the client Id for the project? Kindly send me an email with the information at `shahbaz@web3auth.io.
