You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The revalidation feature added in #529 is somewhat not ideal for a multitude of reasons, but one of the biggest pain points is that it's possible to setup a 2fa method and be prompted to revalidate instantly.
This is partly due to the way the user-interface works, with providers being able to be in 3 states for a user: Not Enabled, Enabled (but not usable), and Available (Enabled, and configured).
For some providers, such as TOTP, the flow can be either: Not Enabled -> Available or Not Enabled -> Enabled -> Available depending on whether the TOTP client is configured before enabling it, or after enabling it.
For some providers, such as Email or Dummy, there is no real Enabled state as they go directly from Not Enabled -> Available in all situations.
The way I've approached this on WordPress.org WordPress/wporg-two-factor#186, is to set the 2fa settings after a provider is configured (for TOTP this is when they key is saved, and when a key is added for WebAuthn). This works for custom implementations like ours, but this doesn't translate directly to the Two-Factor plugin or how it's used.
The WordPress.org approach could potentially work however, if something like #526 was implemented, we could simply hook into the actions like ( provider.enabled OR provider.configured ) => Check if provider.is_available_for_user THEN set-as-2fa'd
Steps to Reproduce
Enable TOTP
Save (Note that the next page doesn't have it as checked, but that's irrelevant for us right now)
Wait 11 minutes (ie. Longer than the 10minute grace time, but shorter than the 2*$grace time of 20mins)
Setup TOTP
Reload the page (Do not re-check the checkbox for TOTP, do not update profile, reload)
Need to revalidate still, even though you JUST setup TOTP.
This is not very visible on the Two-Factor UI, and seems like an edge-case, but is much more visible with other providers or other plugins that use the Two-Factor API such as https://github.com/WordPress/wporg-two-factor eg: WordPress/wporg-two-factor#173WordPress/wporg-two-factor#179 - The issue with the downstream project was partly a bug in the implementation there, but partly due to the above edge-case being triggered.
Screenshots, screen recording, code snippet
Screen.Recording.2023-05-25.at.6.35.36.pm.mov
Environment information
No response
Please confirm that you have searched existing issues in this repository.
Yes
Please confirm that you have tested with all plugins deactivated except Two-Factor.
Yes
The text was updated successfully, but these errors were encountered:
Describe the bug
The revalidation feature added in #529 is somewhat not ideal for a multitude of reasons, but one of the biggest pain points is that it's possible to setup a 2fa method and be prompted to revalidate instantly.
This occurs as there was code added to flag a session as being 2fa when the provider is enabled, but this is not when a provider is actually configured.
This is partly due to the way the user-interface works, with providers being able to be in 3 states for a user:
Not Enabled
,Enabled
(but not usable), andAvailable
(Enabled, and configured).For some providers, such as TOTP, the flow can be either:
Not Enabled -> Available
orNot Enabled -> Enabled -> Available
depending on whether the TOTP client is configured before enabling it, or after enabling it.For some providers, such as Email or Dummy, there is no real
Enabled
state as they go directly fromNot Enabled
->Available
in all situations.The way I've approached this on WordPress.org WordPress/wporg-two-factor#186, is to set the 2fa settings after a provider is configured (for TOTP this is when they key is saved, and when a key is added for WebAuthn). This works for custom implementations like ours, but this doesn't translate directly to the Two-Factor plugin or how it's used.
The WordPress.org approach could potentially work however, if something like #526 was implemented, we could simply hook into the actions like
( provider.enabled OR provider.configured ) => Check if provider.is_available_for_user THEN set-as-2fa'd
Steps to Reproduce
This is not very visible on the Two-Factor UI, and seems like an edge-case, but is much more visible with other providers or other plugins that use the Two-Factor API such as https://github.com/WordPress/wporg-two-factor eg: WordPress/wporg-two-factor#173 WordPress/wporg-two-factor#179 - The issue with the downstream project was partly a bug in the implementation there, but partly due to the above edge-case being triggered.
Screenshots, screen recording, code snippet
Screen.Recording.2023-05-25.at.6.35.36.pm.mov
Environment information
No response
Please confirm that you have searched existing issues in this repository.
Yes
Please confirm that you have tested with all plugins deactivated except Two-Factor.
Yes
The text was updated successfully, but these errors were encountered: