hi guys i'll see if I can repo. thanks for the continued effort . i've since removed tokens but i'll try to help confirm the resolution.

In T358771#10219152, @matmarex wrote:

@Tonymetz Also, I am having trouble understanding what is the actual workflow that doesn't work for you. Maybe I'm just confused, but you seem to be talking about several different ways to log in.
Can you test things again and write down step-by-step

I'm happy to help test and support this. thanks for giving it some attention. it's been a few months so i'll try to reproduce a better test case.

applying the patch in T358771 could fix a large part of this issue and enable webauthn to work across domains.

thanks for helping provide the context that is helpful. I'm happy to help provide some support on this if there's interest. I've worked on 2FA efforts before, and users require a bit of education and notification to help move adoption forward.

In T358771#10200249, @Reedy wrote:

I imagine the number of people affected is probably pretty low, but not zero. Otherwise we'd probably hear about it from more users.

See also: T376021: Migrate WebAuthn on Wikimedia wikis to central domain

i did another round of testing and the feature still appears to be broken. The issue is likely locking users out of their accounts. There doesn't seem to be telemetry on the issue, so I worry that wikimedia staff is not paying attention to the number of users who are getting locked out.

Let me know if my assessment is correct

the people who want to use webauthn do. What's the point of the feature if it's broken?

a monthly reminder that ...

since most people don't use 2FA in the first place.

Are those related to this task?

what would be helpful would be an estimate.

@taavi are we targeting 2024 or 2025 on this one?

Here's a summary of test case failures I've recorded in T358771

any word on this one? in my personal experience, webauthn is pretty much unusable. I can't return to an existing wiki on another device reliably, and I can't log on a new wiki at all.

thanks for the guidance I may take this one. I'll improve the docs if it's better suited for the tag. I appreciate the guidance.

@Reedy is this still relevant? It seems similar to includes/password/PasswordPolicyChecks.php L95 checkPasswordCannotBeSubstringInUsername()

Webauthn security tokens are not being passed to wikifunctions.org

@taavi any updates on the webauthn tasks merge progress? Are we looking at another 6 weeks?

1. it is a one-line change
2. it is a back-port of code from the webauthn repo
3. reedy & I recorded our testing procedure above with video and code samples

@Aklapper I don't appreciate the dismissive tone being used. I invested a lot of effort working together with Reedy to reproduce, debug & help formulate a fix. At the very least you could help clarify exactly what the next steps are here.

It seems the commit was made Mar 5 so it's been 6 weeks. Can you guess how many more weeks it is going to be?

Reedy and I already got this fixed and he submitted a patch. So we're just waiting for it to get merged. What is blocking that?

Can I ask what the blocker is?

any ETA on this one?

There may be another variant of the issue when logging in on meta.wikipedia.org. It seems that the viable webauthn credential list is being filtered either by site or by login device before being presented to the browser. I get a different experience on different browsers.

during testing for T358771 we discovered that login also fails when logging in on the same wiki using a new device.

what's a good way to track the launch status for this fix? i'm sorry I don't know too much about the deployment process

can I help testing out the change on the test env?

happy to help -- great partnership on this

yep cable works like hybrid

debug session showing how to fix

screenshot evidence. video inbound
{F42406516}

wow it worked!

https://github.com/wikimedia/mediawiki-extensions-WebAuthn/blob/979220702ab45fb4755ed45bd38cbbb05a411c22/resources/login.js#L3 in the repo

I can break into the login phase (using chrome devtools) at https://en.wikipedia.org/w/extensions/WebAuthn/resources/login.js L3 and reproduce the issue.

"windows-pc" -- this one is internal (windows hello / TPM)
"iphone" -- this one is iPhone Passkey (added via QR-code) . I think it's supposed to be "hybrid"

Here's my list of tokens on wikimedia

I believe "HYBRID" is the one that supports the iPhone /passkey based login : https://web.dev/articles/passkey-registration

(i'm a bit new to webauthn) it seems that the site (wikipedia) sends a list of token public keys / token IDs to the browser to initiate token-based authentication.

In T358771#9603441, @Reedy wrote:

That USB popup looks very Windows/Edge specific. I don't think the message is in our code, or anything we bring in via vendor.

this bug is pretty serious. I'd like to disable 2-FA but i also want to help get it fixed. I'll be locked out of my account if something happens to my first login session

I'm blocked by another variant of this issue: login from a separate windows machine. I'm being prompted to "insert usb security key" but i have two passkeys registered : (1) from iphone and (1) from another windows machine. I would expect the option to pop a QR-CODE to proceed using iphone passkey

if we have measurements of "Authentication process was interrupted " we could segment by user -agent or device to measure incidence of this issue.

video working experience using "show desktop site" on mobile safari

Wonder if this is some variant of T244088: Logging in at another wiki than WebAuth was set up fails, due to the different mobile domain...

Some more context…

1. I created two keys using Edge. (1) was a local key and (2) was the iPhone key (using QR code)