some fido2/webauthn keys can have a pin, and the client can request
a mode for the user verification.
'default' (no value set), lets the browser/device decide if the user has to
enter the pin of the device
'discouraged' requests that the user should not need to enter the pin
'preferred' requests that the user should need to enter the pin (if possible)
since we use webauthn only as a 2nd factor, having the user enter
the device pin on login may seem too much hassle for some users, so
give them the option
since this is a client option anyway, do not save it in the backend, but
in the browser local storage
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
s/availabel/available/g
no semantic change at all
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Co-Authored-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Tested-by: Oguz Bektas <o.bektas@proxmox.com>
Signed-off-by: Oguz Bektas <o.bektas@proxmox.com>
Fix two things:
* do not reject the login promise when we get the abort DOMException
error
* safely save the original challenge string as we work on a reference
here and avoid to convert to a UInt8 array twice to avoid an
exception.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
simple heuristic for those people who always prefer a specific TFA
method and have the others only as backup.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Improve UX by avoiding the need to click some buttons twice, or
calling TOTP and Recovery codes both "OTP" codes and showing multiple
buttons, with all having the same goal "submit a TFA token" at the
same time.
Instead use a tab panel with a single submit button.
WebAuthn can and should be still improved, but that can be OK as
followup.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>