We’re using Login by Auth0 v4.5.0 on WordPress v6.2.2. Users can create account through custom database connection and Google Social Login. We’re also using Universal Login. We’re using the standard login and get user scripts. Node 12 is used and we do not have any rule enabled.
This setup has been working just fine. Existing users can still login and new users can create an account via Google Social Login. However all of sudden our users started to have issues with creating an account using custom database connection.
Even though no change has been done, in order to be sure we’ve double checked the plugin and Auth0 configurations. Our hosting provider, WP Engine, looked at caching rules as well as how they handle Authorization headers, but they don’t find any issue.
When user tries to create an account they see “WE’RE SORRY, SOMETHING WENT WRONG WHEN ATTEMPTING TO SIGN UP.” message.
We’ve reviewed all troubleshooting suggestions here but didn’t get anywhere. Here it’s suggested that the error we have is related to Authorization headers but our hosting provider doesn’t think so. The only thing they suspect is that CDN (they’re using Cloudflare) strips the headers before they hit the server. But this doesn’t explain why login is working while sign up via custom database is not.
Does anyone know what else we can investigate or even better a solution / suggestion that we can use?
@developer6 Signup using a custom database connection - leastways one that is not configured for user import - will typically utilize the user creation script (see Create Script Templates for details). Have you double-checked to see that is working OK? If custom database login is working, and so too is login/signup via (Google) social connection, then I suspect that is probably where your issue lies
To configure custom database, we’re using the login script and the get user script according to the guide here. I’ve compared the scripts we’re using with the ones provided and they’re identical.
I’ve reviewed the logs again and now I see that not all users can login. There are lots of Unexpected token < in JSON at position 0 and Unknown client errors at login, sign up and password change events.
The link you shared is to the user migration (to Auth0) guide. Does that mean you’re migrating your users to Auth0? Rather that leaving users credentials in your custom (credential) store? For user migration to Auth0, the custom database login and get user scripts should suffice. Though if you want to support a user resetting their password as part of a login attempt, you will also likely need to implement change password too (see Change Password Script Templates for details). Until a user is migrated to Auth0, password reset will typically be performed against your custom (credential) store.
However if you are not performing user migration and you are also looking to support Signup via Auth0, you will typically need to implement a create script (see Create Script Templates for more details) as well. In this situation - i.e. where users are not being migrated - the same would go for change password too.
I’ve reviewed the logs again and now I see that not all users can login. There are lots of Unexpected token < in JSON at position 0 and Unknown client errors at login, sign up and password change events.
You might want to take a look at the troubleshooting section of the user migration guide here. This describes potential solutions for a number of situations, including the one it sounds like you’re currently experiencing (see here for details).
Yes, we’re performing user migration as we have a large user base that are not on Auth0. That’s why we’re using those scripts. Change Password is an issue and we’ll look into your recommendation when the sign up issue is solved.
Unexpected token < in JSON at position 0 is the inital error we’re getting at sign up. We followed the troubleshooting recommendations here. Our endpointUrl is https://examplewebsite.com/index.php?a0_action=. According the documentation, this is how it should be but when we visit this URL, we get a 404. However if we add migration-ws-login or migration-ws-get-user to the endpointUrl, we get another error Unauthorized: missing authorization header. The suggested reason for this error is headers not being parsed. Our hosting provider investigated this and says that the headers are parsed.
For the record, the hosting provider is WP Engine and they’re using Cloudflare as CDN.
It looks like we’re stuck and no potential solution in sight.
Thank you for the assistance anyway
I’m not a Wordpress expert, but looking at the code in the GitHub repository (here) there are a few things I can suggest (in no particular order):
It looks like the endpoint - i.e. /index.php?a0_action=migration-ws-login - is expecting a formPOST, so if you are trying to navigate to this (i.e. via GET) then this would probably explain why you are seeing Unauthorized: missing authorization header. Perhaps try something like Postman to perform the operation outside of Auth0 and see what you get? Naturally you’d ideally want to test against a test system, or failing that using a dummy user
It doesn’t look like the request to Wordpress is failing otherwise the callback(error) would be driven. It looks more like the call to JSON.parse is failing given the error message you’re seeing. It’s likely throwing an exception (as described here) and it’s likely doing so because the content of the body is not valid. Perhaps try adding a console.log(body) before the var wpUser = JSON.parse(body);? You should then be able to see the output using the Real-time Webtask Logs Extension. Again you’d ideally want to try this on a test system, using a dummy user
Perhaps try to wrap the code in the request.post callback function in an exception handling block? That way the exception can be caught. And you can perform a return callback(null); in the same way as the in the if (wpUser.error || ! wpUser.data) block (rather than an uncaught exception being thrown). As ever, you’d ideally want to try this change out on a test system, again using a dummy user
Hello, I am having the same error. The content of the body in my code is showing up as HTML rather than JSON. Similarly we have had no changes in our environment recently that could cause this. Any ideas? Not sure what truly fixed the issue on this post.
Signup using a custom database connection - leastways one that is not configured for user import - will typically utilize the user creation script (see 
