Wordpress: Can't change user password without clicking "Delete Auth0 Data" in admin

Help
1

Hi community,

I’m having an issue on my WordPress site (using the Auth0 plugin) when it comes to changing user passwords.

We use a custom database with login and get_user functions that work perfectly fine most of the time. When users first sign up, they are able to authenticate with no problems. The issue comes when one of the following happens:

  1. An admin updates their password within WordPress. In this case, the user cannot log in (they get the “wrong username/email” message on the Auth0 widget) until the admin clicks the Delete Auth0 Data button on their user page.
  2. The user attempts to update their own password. We use WooCommerce’s forms, but this same thing happens if they do a password reset from the login page. If they enter their current password and then their new desired password (twice) they get a message saying “Password could not be updated.” Having an admin click the Delete Auth0 Data button in the admin makes it work correctly, until the next time.

We are trying to keep the WordPress database as the authoritative user store and have turned off the " Import Users to Auth0" setting in the Connection within Auth0, yet it still seems to be caching some information there.

Any advice on what to change on my configuration to make this work correctly would be greatly appreciated.

Thank you!
Mike

2

@hellomike - Apologies for the trouble here. Can you tell me what version of the plugin that you’re using? We made some changes to how passwords are pushed to Auth0 in 3.10.0 so if you’re not using that version, can you update and try again?

Password could not be updated.

That tells me that there’s a broken connection between your site and your Auth0 user store. Do you see anything in the plugin’s error logs or the Auth0 error logs?

We are trying to keep the WordPress database as the authoritative user store and have turned off the “Import Users to Auth0” setting in the Connection within Auth0, yet it still seems to be caching some information there.

I will say here … the typical use case for Auth0 is the opposite of that: Auth0 as the authoritative user store that your other sites/apps rely on. The plugin, to the best of its ability, works with that assumption. All that to say: our main goal with the plugin is to have WordPress use Auth0 as the trusted user provider, hence the migration option.

Hope that helps a bit!

3

Hi Josh,

I am using 3.10 now, but was seeing the problem in 3.9 originally.

In the time since I filed this, I was able to figure out the I needed to give the application access to the Auth0 management API, and granted it access to the various user/user metadata read and update permissions. That error has gone away, but I still wasn’t able to get rid of the behavior where Auth0 seems to be caching user logins and not referring back to WordPress to authenticate.

So, the reason we’ve been trying to use WordPress as the authoritative store is because our site heavily uses WooCommerce and it seems that both Auth0 and WooCommerce want to “own the user” so to speak. WooCommerce has a user-accessible email/password/name update tab in their My Account page and the password that they update there seems to be only on the WordPress side. Also, the Reset Password flow provided by the Auth0 widget, while functional, doesn’t direct the user back into the site’s login after successfully updating the password; it generally feels less integrated.

I suppose my thinking was that if we were able to make it so that Auth0 would continue to use the WordPress login (just as they do for the initial login through the custom database) it would make everything just work while keeping the forms we had already been using.

Is such a thing possible? It seems like Auth0’s plugin uses hooks into WordPress’ update password system that take over the process in unexpected ways and prevent us from just using the WordPress/WooCommerce version.

-m

4

@hellomike - Apologies for the long delay here. I did not get a notification for your reply (looking at those settings now).

That error has gone away, but I still wasn’t able to get rid of the behavior where Auth0 seems to be caching user logins and not referring back to WordPress to authenticate.

I’m not sure I totally understand what this means.

the Reset Password flow provided by the Auth0 widget, while functional, doesn’t direct the user back into the site’s login after successfully updating the password; it generally feels less integrated.

Can you walk me through those steps? I’ll see if we can make that experience better for the user.

I suppose my thinking was that if we were able to make it so that Auth0 would continue to use the WordPress login (just as they do for the initial login through the custom database) it would make everything just work while keeping the forms we had already been using.

If you just have a single WordPress site for your tenant then I imagine that would work fine, though you will need users for any other application or site you add to log in through WordPress or link their accounts to make sure that SSO works.

Additionally, there are other scripts that need to be used when you turn off the import function that we don’t provide. You’ll see ~4 more appear on the Custom Database tab which need to be implemented to push any changes in Auth0 to your WordPress site.

It seems like Auth0’s plugin uses hooks into WordPress’ update password system that take over the process in unexpected ways

In the end, that’s really the point of user centralization. Your users across applications are collected in Auth0 and those records are used to authenticate. WooCommerce provides additional front-end pages for login, signup, and password reset, as well as additional profile information but you’re still using the WordPress user so in terms of “ownership,” the split is the same.

I think your best bet is to leave the import setting on and I’m happy to help troubleshooting any issues that are happening with the functionality that the Auth0 plugin provides. We definitely want to play nicely with WooCommerce and happy to work with you to fill in the gaps.

Thank you and apologies again for the delay.

5

Hi Josh,

Thank you for the lengthy reply, but in the interim we basically did just end up using Auth0 migration and hiding the WooCommerce pages. It isn’t ideal from an integration standpoint but it has been working for the most part.

We’ve since run into another problem with (typically Safari) rejecting the cookies needed to make the integrated login work on our site, and we’ve been looking to move to the New Universal Login to hopefully work around that. This process has been held up because we can’t seem to get the password reset link to show up one the New Universal Login form. There is a separate post for that here:

-m

6

That’s the method we recommend and the default when you install the plugin. More details on the differences here:

I’ll take a look at your other thread and see if I can help out there.

8

@hellomike ping ping friendly ping :slight_smile:

9

This topic was automatically closed after 4 days. New replies are no longer allowed.