Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Turn off 2FA if the user only has Backup Codes enabled #75

Merged
merged 6 commits into from
Mar 8, 2023

Conversation

dd32
Copy link
Member

@dd32 dd32 commented Mar 1, 2023

This is partially related to #47 and might fix it, I'm not sure.

This simply disables 2FA if the user only has Backup Codes enabled, which appears to be happening for users when viewing the TOTP screen, but not setting it up (This is a bug in our UI, partially due to a less-than-ideal upstream flow).

The result from that is that they're locked out, as they never saw the backup codes, and are prompted for them next time they login. There are currently ~5 users affected by this.

This PR should resolve the login for those users, and might resolve #47.

@dd32 dd32 requested a review from iandunn March 1, 2023 02:02
@dd32 dd32 added this to the MVP milestone Mar 1, 2023
@dd32 dd32 added the bug Something isn't working label Mar 1, 2023
Copy link
Member

@iandunn iandunn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works in my tests 👍🏻

I don't think it fixes #47, since IMO we still need the UI warning, instead of allowing the backup codes to be generated in the first place.

This is a good server-side protection to enforce that, though, and fixes it retroactively for the folks who've already experienced it.

@iandunn
Copy link
Member

iandunn commented Mar 1, 2023

I just remembered we also have #24, which is similar. cc @pkevan

@pkevan
Copy link
Contributor

pkevan commented Mar 2, 2023

I think I prefer this method, and since we can potentially reduce users' caps should their account fall into what we consider needing it, then it's probably a good solution.

Ideally we'd be able to guide users' easier through our preferred setup.

@dd32
Copy link
Member Author

dd32 commented Mar 3, 2023

I've merged it with set_primary_provider_for_user() as I totally missed that even existed.

I don't have an environment I can run the tests for this repo in, and the steps to get to that point are far too involved to be worth it, so I've just updated the tests with what I believe should pass.

@iandunn
Copy link
Member

iandunn commented Mar 3, 2023

the steps to get to that point are far too involved

If you already have a Core environment locally setup, and the tests working there, then IIRC this is all that's needed:

  1. Set the WP_TESTS_DIR env var to Core's /tests/phpunit folder
  2. composer install in this plugin

I could be forgetting something, though. I'm open to changes that make it easier to setup.

iandunn added 2 commits March 3, 2023 06:22
`get_enabled_providers_for_user()` already calls `array_keys()` on the `ENABLED_PROVIDERS_USER_META_KEY` value.
Explicitly setting `PROVIDER_USER_META_KEY` isn't necessary and distorts the test. The same thing effect should be achieved just by calling `enable_provider_for_user()`, and hardcoding it would hide any error in that function. This is really an integration test rather than a unit test.
@iandunn
Copy link
Member

iandunn commented Mar 3, 2023

The test was failing for me, but I fixed that in 1712d3b. I also pushed 0aaad94 which is unrelated but seems like a good change to make.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Disable backup codes UI until primary provider enabled
3 participants