LG 8622 Removes stand alone error page for F/T Unlock (only WebAuthn Method)

[kevinsmaster5]

🎫 Ticket

Link to the relevant ticket.
LG_8622

🛠 Summary of changes

Removes the control statement checking if multiple factors are enabled in handle_invalid_webauthn so in any case it will redirect to login_two_factor_webauthn_url rather than the stand alone error page.
Revised the Spec to account for that change.
Deleted the stand alone error page erb file.

📜 Testing Plan

Provide a checklist of steps to confirm the changes.

• Create an account using a device that is able to support Face or Touch Unlock as MFA
• Set up Face or Touch Unlock as the only MFA method
• When the account is complete attempt to log in using a device that does not support Face or Touch Unlock
• An error screen should appear with a button to Use face or touch unlock, a link to choose another authentication method, and a link to Cancel
• It should not show a screen that says "We can't identify your device"

👀 Screenshots

Details

Previous UI

Details

Revised UI

[jmdembe]

When I set up Face/Touch unlock as my only method on Chrome and then try to authenticate on the same machine, but on Firefox, I am getting a 404. Is this an expected behavior?

[kevinsmaster5]

When I set up Face/Touch unlock as my only method on Chrome and then try to authenticate on the same machine, but on Firefox, I am getting a 404. Is this an expected behavior?

No it shouldn't go to a not found page. What path is showing when it 404s?

[jmdembe]

When I set up Face/Touch unlock as my only method on Chrome and then try to authenticate on the same machine, but on Firefox, I am getting a 404. Is this an expected behavior?

No it shouldn't go to a not found page. What path is showing when it 404s?

It appears on the webauthn_error path

[kevinsmaster5]

Thank you @jmdembe I'll try to see why it's trying to get that path in Firefox.

[aduth]

I think that error page might be related to what I'm working on in LG-10177 / #8723, where we redirect the user to the error page if they're signing in and a platform authenticator is not available on the device (specifically, this code).

We probably want to keep that error page around as long as it's used, which will be much less between this ticket and mine. I expect it'd continue to be used for a scenario where someone tries logging in from a device which doesn't support WebAuthn at all (although maybe this falls outside our browser support commitments).

[kevinsmaster5]

@jmdembe and @aduth please take a look in particular how I solved the webauthn verification controller on line 30. I'm mostly concerned about inadvertently short circuiting legitimate errors.

Firefox no longer sends a 404 or put you on that dead end page anymore. It does tell you to Connect your security key which is confusing and not exactly what I would expect. Safari still works as before and Chrome where I have created the Touch authentication continues to work.

[aduth]

Curious, how do the code changes here relate to the ticket. I'm not sure I follow why we'd need them, and the tests pass without them.

[kevinsmaster5]

The original code that was there

Suggested change

	flash[:error] = t(
	'two_factor_authentication.webauthn_error.multiple_methods',
	link: view_context.link_to(
	t('two_factor_authentication.webauthn_error.additional_methods_link'),
	login_two_factor_options_path,
	),
	)
	redirect_to login_two_factor_webauthn_url(platform: params[:platform])
	def error; end

is what was redirecting Firefox to the dead end page.
For whatever reason Safari was working without the code change. I may be missing something elsewhere that would make the solution work without this.

[aduth]

I think keeping the error view to avoid the 404 with your changes in 8a44fb6 is enough for this ticket, and we can address the Firefox behavior as part of my work in #8723.

[kevinsmaster5]

I have taken out that change. Thank you.

[aduth]

LGTM 👍