Seen on @Mehman97's account. The yubikey check failed, then after clicking the refresh button it worked.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
Step 1
Created an account: T393327YubikeyTest
Step 2
Added the user to the oathauth-tester global group (on testwiki).
mwscript-k8s --comment="T393327" --follow -- extensions/CentralAuth/maintenance/addToGlobalGroup.php --wiki=testwiki --reason "Testing T393327" T393327YubikeyTest oathauth-tester
Step 3
Verified on testwiki that the user was added to oathauth-tester group, which enables them to use 2FA.
Step 4
Added the security key via a YubiKey, and it just worked (on first try) with no errors!
 |  |
Step 5
Logged out and logged in with the credentials. Verified that the login also triggered a 2FA on the shared domain (which works).
Step 6
Cleaned up the test account (disabled 2FA) and removed this user from the group added in step 2.
mwscript-k8s --comment="T393327" --follow -- extensions/CentralAuth/maintenance/addToGlobalGroup.php --wiki=testwiki --remove --reason "cleanup: Done testing T393327" T393327YubikeyTest oathauth-tester
Conclusion
It appears that the feature is working as expected. Perhaps a random error occurred with the request that caused an error on the first attempt? In that case, we may need to either locate the exact request in Logstash and determine what happened (if anything) or wait for a similar situation to occur again, allowing us to identify the cause. But at the moment, this seems to work as expected. If this were a persistent real problem, we would likely have had multiple users reporting it.
Comment Actions
What was failing (sometimes) was login, not adding the key (probably because the login 2FA check happens close to page load time but adding the key doesn't). Anyway, if it was caused by T393256 we have every reason to believe it is fixed, and if it was caused by something else then we'd need someone to reproduce it and provide more information (this is a frontend error and frontend error logging is not that reliable, so there's probably no Logstash entry), so the task is not actionable. Let's just assume it's fixed by @matmarex's patch (which seems likely) and if it's not and someone runs into it, they can just file a new task.
Comment Actions
I guess there's one potentially actionable thing - maybe WebAuthn should log API errors. (That's what we think happened here: mw.config ended up with the wrong API URL so the API request was a 404.) Filed that as T406581: WebAuthn JS code should log frontend API errors.