Prompt for revalidation of 2FA details.

[dd32]

Depends upon WordPress/two-factor#529

Fixes #43 #115

Require revalidation of the user via two-factor if accessing two-factor settings or backup codes, and the userRecord.record[ '2fa_revalidation' ].expires_at time has passed.

TODO:

• Wording
• [] Translations
• Merge Revalidate two factor settings prior to allowing any two-factor changes to an account. two-factor#529

[dd32]

The current UI only enforces 2FA revalidation for TOTP and Backup codes, as Email and Password don't need it.

The current code doesn't block a user attempting to setup TOTP or generating backup codes, as while the user could generate a TOTP key and URI, they're unable to save it via the Two Factor plugin (or be able to access the Backup Codes API)

Due to sameorigin policies, using an inline iframe isn't an option, at present, but potentially could be in the future if we wanted to go down that route.

[dd32]

Due to sameorigin policies, using an inline iframe isn't an option, at present, but potentially could be in the future if we wanted to go down that route.

I realised with some minor changes to the upstream patch, and to WordPress.org's SSO, I could make this work.

I have not tested this with a Security key, but due to the Origin being the same, I believe this should work based on some testing using other sites.

Screen.Recording.2023-05-08.at.4.03.58.pm.mov

The delay in the above recording is while it's doing a refreshUser API call, I suspect this can be made much nicer somehow, perhaps just by having the postMessage pass through the new expiry data and have it refresh it in the background, or have it assume that it's okay.

[dd32]

With the addition of 3ca07e1 the UI feels much 'faster' and a far better UX.

There's obviously going to be some edge-cases in that, but it appears as if it works well enough.

I haven't tested this PR at all with setting up TOTP, I know it 'works' with the Two-Factor plugin, but I haven't tested our UI with it.

Screen.Recording.2023-05-09.at.11.00.52.am.mov

[dd32]

Frustratingly I just realised that this branch appears to be based on an old trunk.. I'll merge/rebase this today. edit: turns out not to have been a problem..

However, I can confirm that the iframe approach works with WebAuthN as in #153

[adamwoodnz]

I'm seeing this warning @dd32, not sure whether it's a concern

[adamwoodnz]

Latest UI:

• Single modal flow and copy matching design, but with restyled login page 2FA elements
• Account Status is displayed behind modal

Desktop	Tablet	Mobile

[adamwoodnz]

@dd32 there is a translation task in the description but I don't see any other translations in the JS app. What are we expecting here?

[dd32]

there is a translation task in the description but I don't see any other translations in the JS app.

Yeah looks like we ditched translations, we can skip that part then for now :)

[dd32]

I'm seeing this warning dd32, not sure whether it's a concern

@adamwoodnz Thanks! I'm not sure how I missed that 🤔; I fixed the variable reference, it was a copy-paste error.

Latest UI

Looks good to me! Thanks!

I think we should do some extra work on the 2FA prompts displayed during login too, but that's not needed as part of this, and can wait for the next Iteration.

[adamwoodnz]

Yeah looks like we ditched translations, we can skip that part then for now :)

Cool, guess we're just dependent on the two-factor PR being merged then. Let me know when that happens, or feel free to merge this yourself of course :)

[StevenDufresne]

I wasn't able to get my environment configured to test this out, but based on what I see, I think this is good solution for the MVP since the grace time should mean that not many users go through this flow (so it's not super critical), but their accounts are protected.

The modal does feel like it has a long chin (a lot of whitespace at the bottom), but I understand it's related to embedding a variable width iframe.

As part of merging this ticket, do ya'll mind opening a new ticket with information about implementing a more ideal case while it's fresh in your mind?

[dd32]

As part of merging this ticket, do ya'll mind opening a new ticket with information about implementing a more ideal case while it's fresh in your mind?

I'm not sure what a better solution is really, without too much code duplication.

The only thing I think that could realistically be done here is to improve the actual Prompt screen to not have as much screen reflow (ie. not insert an error div, but rather have it take up some space that is currently visibility: hidden), and have the postMessage communicate the ideal sizes for the embedded iframe.