| Summary: | `navigator.credentials.get()` immediately fails if a different security key is plugged in | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Lucas Garron <lgarron> | ||||
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | RESOLVED WORKSFORME | ||||||
| Severity: | Normal | CC: | bfulgham, dwaite, jiewen_tan, pascoe, webkit-bug-importer | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | Safari 14 | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 181943 | ||||||
| Attachments: |
|
||||||
WIW, via: Safari 15.1 (17612.2.6.1.1) on Monterey beta, Syncing Platform Authenticator and Web Authentication Modern disabled, Yubikey 5c (with passcode) inserted. Was not able to replicate. Was able to: - sign in via existing yubikey to GitHub.com - register TouchID on MacBook Pro 15 - sign out and provide u/p - provide WebAuthn using TouchID Hi, unable to replicate this behavior on Safari 15 and STP Release 133 (Safari 15.4, WebKit 17613.1.2.2). The steps I tried: 1. Register one security key on Github.com 2. Unplug first key and plug in a second security key 3. Login to account with key from step one We are unable to reproduce this behavior. It does look like this is fixed for me now. 🤷 |
Created attachment 416069 [details] Screen capture of the UX in question Reproduction steps: 1. Register a security key on GitHub.com 2. On a MacBook Pro with macOS Big Sur 11.0, plug in a *different* security key. 3. Log into the account with registered in step 1. Observed: At the security key step, Safari flashes the security key prompt, but immediately removes it and replaces it with a "Found no credentials on this device" explanation. Expected: The user is prompted to insert a security key, as if the correct (or no) security key was currently inserted. The current behaviour somewhat makes sense if you assume that a user only has a single security key that they would ever plug into a given device (or perhaps if the device can only hold one security key that is generally not left in permanently, as on iOS), but it will result in a rather confusing UX if someone: 1. Has two computers with a permanently plugged-in security key each. 2. Registers a security key in computer. 3. Tries to log into the other computer (perhaps to try to register the other key). If they didn't switch the keys ahead of the prompt (quite likely if they don't immediately do step 3 after step 2), they get this issue. If the user is not given a chance to plug in another security key, it would be helpful if the prompt at least explained the reason (one key is already plugged in, and it doesn't have a valid registration for the site).