Add analytics property for WebAuthn sign-in frontend error

[aduth]

🎫 Ticket

Related to LG-11399

🛠 Summary of changes

This adds a new property frontend_error to unsuccessful WebAuthn sign-ins.

While it doesn't appear this property is actively used in any dashboards, the availability of this value inadvertently regressed as part of #9572, which previously logged the specific error name as part of the error_details property.

An alternative implementation could try to incorporate this as the "type" of the error detail, but the case mismatch between e.g. incoming NotAllowedError and expected detail type formatting of not_allowed_error could create some confusion.

📜 Testing Plan

1. (Prerequisite) Have an account with Security Key or Face or Touch Unlock as an associated MFA
2. Run make watch_events in a separate terminal process
3. Go to http://localhost:3000
4. Sign in
5. (If not prompted for MFA, click "Forget all browsers", confirm, sign out, and start over from Step 3)
6. When prompted WebAuthn, click "Use face or touch unlock" or "Use security key"
7. Cancel the dialog that's shown
8. Observe in event log that you see "Multi-Factor Authentication" event including "NotAllowedError"

[aduth]

The "alternative" approach described in the original comment could look something like...

Suggested change

	error_details: { webauthn_error: { webauthn_error: true } },
	error_details: { webauthn_error: { NotAllowedError: true } },

Or:

Suggested change

	error_details: { webauthn_error: { webauthn_error: true } },
	error_details: { webauthn_error: { not_allowed_error: true } },

Or some extra processing to trim the redundant suffix:

Suggested change

	error_details: { webauthn_error: { webauthn_error: true } },
	error_details: { webauthn_error: { not_allowed: true } },

[kevinsmaster5]

Does the third version leave the door open for other types of webauthn_errors? I'm not sure if that sort of scalability is likely but if it is I think that's a strong candidate. It seems pretty descriptive regardless.

[aduth]

Yeah, I think I like it as far as providing the actual detail relevant for the field, but my main concern is that it's not obvious the mapping between the original JavaScript-derived error name and the resulting logged key name, which would I expect would be derived by some opaque logic like javascript_error_name.underscore.tr('_error', ''). And the "Error" suffix of JavaScript error names is only a standard convention, not strictly mandatory.

[aduth]

I'm actually thinking I might go a different direction with this and use ActiveRecord's built-in absence validator for this, which seems like a nice compromise between the challenges above and trying to avoid having a redundant webauthn_error subproperty.

I'll plan tackle that in a quick follow-on pull request.

[aduth]

I'll plan tackle that in a quick follow-on pull request.

See #9614

[aduth]

If this is being logged on the Multi-Factor Authentication event, it should probably be documented in the arguments for that method, and qualified as relating specifically to "WebAuthn".

Though maybe that extra friction is enough to warrant persuing the alternative instead.

[aduth]

I'm open to suggestions, but fairly happy with the solution proposed here currently, and I'd like to try to get this included in the next production deploy to ensure continuity of the data for error types.

[kevinsmaster5]

Looks good! My vote for error_details ver no. 3
Tested locally