auth0 wordpress plugin not honoring the "required verified email" setting in all circumstances when it is disabled

[aap-jmedema]

Describe the problem

Problem: When an auth0 user is created in the cloud having the same email address as another auth0 user (whether it still exists or not) and the old user has already been created in wordpress, the user login for the new user will fail with "this email address requires validation" even if the plugin has that setting disabled.

Background: We have an auth0 config that has multiple custom databases (prod and dev into the same tenant). We have a problem (in another unrelated ticket) where the users from prod and dev end up with the same user_id in auth0, along with a few other problems that end up with duplicate users in an unsupported fashion. We're in the middle of fixing our back-ends so that they will report each user to auth0 in such a way that auth0 will receive a unique user_id regardless of back-end database. This process will end up transitioning all our users from an old user_id format to a new user_id format. In our wordpress front-end, we're using the wp auth0 plugin (4.3.1) to manage our user authentication exclusively. I'm listing our specific scenario but there are many, much more simple scenarios where this issue occurs.

Root cause: WP_Auth0_UsersRepo line 61 documentation states that it is checking, in addition to other things, to see whether the email validation setting is turned on when in fact the code does not make that check (lines 62 & 63).

What was the expected behavior?

User creation should honor the email validation requirement setting in all scenarios.

Reproduction

To replicate the issue:

1. In Auth0 cloud user mgmt gui, create user A (user ID user_A) in auth0 with an email [email protected]. Do not set the email address as verified.
2. In the wordpress website that has auth0 configured, turn off email verification.
3. Log into the wp site with [email protected]. This should succeed.
4. Log out of the wp site.
5. Verify the user is created in the WP DB, take whatever notes you want here.
6. In Auth0 cloud user mgmt gui, delete user A (this step is optional). Leave the WP user in place!
7. In Auth0 cloud user mgmt gui, create user B (user ID user_B) in auth0 with an email [email protected]. Do not set the email address as verified.
8. Log into the wp site with [email protected]. This will fail with an error "email address requires validation" despite the setting being disabled.

In order to understand the root cause of this invalid state issue, I'll walk through the login process:

1. Authentication and login proceed normally without issue until WP_Auth0_LoginManager.php's login_user function.
2. In this function, it first checks to see whether email verification is enabled and in our case it is not so no errors are initially thrown.
3. It then checks to see whether this user exists in the system by auth0 ID, not by email. It does not find a user, so it assumes it must create a new user.
4. LoginManager's line 334 calls UserRepo->create to create the new user
5. In create, after verifying that the provided userID comes from auth0, it checks to see whether the provided email address is verified despite the disabled setting.
6. The function then grabs the nearest user by email, not by auth0 ID. If it finds an old user here, like in my reproduction steps, it will immediately error out with the email validation error. If an old user is not found then a new user is created without caring about the email validation setting.

To fix this, either add the validation setting check in UsersRepo or change the LoginManager user check to check by email instead of auth0 user_id. I would prefer that both be changed - the UsersRepo setting because creating users should honor the disable email setting and the LoginManager because WP requires email addresses to be unique.

Environment

WPEngine service, presumably ubuntu latest
PHP 8.0
MySQL 8
Nginx latest
Wordpress 6.1
WP Auth0 plugin 4.3.1

[evansims]

Hi @aap-jmedema 👋 Thanks for your question. Allow me a little time to investigate and get back with you.

[aap-jmedema]

Any update on this? This is a higher priority than my other ticket (#871).

[evansims]

Hi @aap-jmedema 👋 Thanks for your patience while we reviewed this! Unfortunately, changing the behavior of the plugin to resolve this would cause a number of side affects for other users, as it would be a breaking change from expected behavior for the plugin. As v4 of the plugin has had with this present behavior current state for quite a few years, we're hesitant to suddenly shake things up on users.

This would be something we'd have to slot in for a new major; however, we already have V5 of the plugin available, which does accomodate this change, and is currently available for installation through Composer. This will be made available on the plugin store in the near future as well.

V5 is a complete redesign of the plugin, so understandably it may not be a simple transition for you, if you've built custom login on top of the V4 API. If this is the case, I'd recommend forking V4 and making the changes you need to accomodate your use case.

Apologies this is not something we can address on our end with a release, but I do thank you for bringing it to our attention, and I hope one of the suggested pathes are viable for you.