LG-11399: Show Face/Touch message for screen lock error

[aduth]

🎫 Ticket

LG-11399, and somewhat related to LG-11135 in terms of form error refactoring

🛠 Summary of changes

Updates error handling for Face or Touch Unlock sign-in to show a specific error message when the browser produces an error informing us that the user is attempting to sign in on a device ineligible due to lack of screen lock for the userVerification requirement of authentication.

Note that this error is specific to Chrome, is not a behavior described anywhere in the relevant WebAuthn specification, and could change at any point. See the related Slack discussion on this point, but the consensus is that we should still want to target this specific error type, and that as long as we continue to log to our frontend error logger for unexpected errors, we should be made aware if the messaging changes over time.

This is an error we see frequently logged in our frontend error logger, and the changes here are meant to address it directly and prevent further logging.

Draft: This pull request currently contains a lot of refactoring and proposals which may make sense to split off to their own pull request, but compiled here as an initial MVP. Edit: See separate pull requests #9613, #9614, #9572

📜 Testing Plan

I've been using the following diff to emulate the behavior locally:

diff --git a/app/javascript/packages/webauthn/verify-webauthn-device.ts b/app/javascript/packages/webauthn/verify-webauthn-device.ts
index ee39c2016..9f42ad140 100644
--- a/app/javascript/packages/webauthn/verify-webauthn-device.ts
+++ b/app/javascript/packages/webauthn/verify-webauthn-device.ts
@@ -45,6 +45,11 @@ async function verifyWebauthnDevice({
 
   const response = credential.response as AuthenticatorAssertionResponse;
 
+  throw new DOMException(
+    'The specified `userVerification` requirement cannot be fulfilled by this device unless the device is secured with a screen lock.',
+    'NotSupportedError',
+  );
+
   return {
     credentialId: arrayBufferToBase64(credential.rawId),
     authenticatorData: arrayBufferToBase64(response.authenticatorData),

Verify that you're presented with the relevant error message when signing in with Face or Touch Unlock.

👀 Screenshots

With another method available:

Without another method available:

[aduth]

I'm marking this ready for review since it's code-complete. I'm still awaiting final decision on the text of the error message before I get translations, and will plan to swap that in once it's available.

See related Slack discussion: https://gsa-tts.slack.com/archives/C01710KMYUB/p1699390502877849

[zachmargolis]

this probably should have _html on it? the only exception is when strings get written to flash?

[aduth]

The test got angry at me about it. I tested without the _html and it seemed to work fine for me.

I think the alternative would be to apply _html to both the "parent" and "child" strings like what's done above with connect_html, but I'd opted to avoid it since it seemed to work without.

[zachmargolis]

what's rendering this error message?

[aduth]

what's rendering this error message?

I'm not sure what you mean by this. Do you mean how to reproduce the error message being shown?

[zachmargolis]

I meant, where is the code that renders the error in a template.

I did some spelunking and found that the error gets written to the flash:

identity-idp/app/controllers/two_factor_authentication/webauthn_verification_controller.rb

Line 58 in bf8a549

flash[:error] = result.first_error_message

which explains why it renders correctly without being named _html because all flash messages get .html_safe 😭

identity-idp/app/components/flash_component.html.erb

Line 2 in bf8a549

<%= render AlertComponent.new(type:, message: message.html_safe, class: 'margin-bottom-4') %>

[aduth]

😬 I'm not sure I'd realized that. I'd be interested in seeing what it might take to move away from that, though definitely a separate effort. I'll see if it also works to just add _html to both the "parent" and "child" and that would be future-proof at least.

[aduth]

Added the suffix in 05bc0f0 . I did a little bit of testing of what it'd look like to remove html_safe to verify that it'd work, but it looks like something is dropping the HTML safety of the suffixed string somewhere along the way. Something to look at later if / when we try to drop the auto-safety.