Hi @matthneedh
Custom domains are fully supported in the plugin as of the latest release, 3.7.0:
https://github.com/auth0/wp-auth0/blob/master/CHANGELOG.md#370-2018-08-13
The domain in the Application won’t change as that domain is still usable. Once you have your custom domain setup correctly, just add that in the Auth settings in WordPress under the Basic tab:
https://www.dropbox.com/s/wzcj4y3xzjlzo4e/Screenshot%202018-09-07%2009.03.39.png?dl=0
Let me know if that works or if you’re still having trouble here.
I have two dev environments, one using Universal Login (via the auto login checkbox) and one using the embedded lock. I updated the plugin in each from 3.6.2 to 3.7.0.
The one with Universal Login works great. The one using the embedded lock widget is no longer allowing me to login, returning the invalid state error (Safari, Chrome, and Firefox). I’ve read https://github.com/joshcanhelp/troubleshooting-invalid-state-wp/, and these sites ARE hosted on Pantheon.
Given what I described, does it make sense that the universal login would work, but the embedded login would not? Would it make sense for the embedded login to stop working on Chrome and Firefox, when it had previously only been failing on Safari?
I’m guessing I’ll need to make tweaks due to Pantheon hosting, but it isn’t clear to me exactly what changes are needed.
Thanks for your help.
I forgot to mention that the Auth0 dashboard logs the login attempt with “Success cross origin authentication”, but no other log types. I can no longer log in to WP to check the log there, so I’m not sure if that provides more info.
> I’ve read https://github.com/joshcanhelp/troubleshooting-invalid-state-wp/, and these sites ARE hosted on Pantheon.
Did you add the filter it mentions there? That is likely to be the problem. If you have an are still having the issue, please run through that troubleshooting guide and let me know what you find.
> Given what I described, does it make sense that the universal login would work, but the embedded login would not?
Embedded login uses cross-origin authentication, which can be problematic in some cases, depending on the browser. See the reply here for more information on that:
https://wordpress.org/support/topic/auth0-is-broken-2/#post-10664960
> Would it make sense for the embedded login to stop working on Chrome and Firefox, when it had previously only been failing on Safari?
It might if you were using anything that’s been deprecated in August. Again, see that thread above for more information.
Sorry I wasn’t more explicit. It was working in Chrome and Firefox with v 3.6.2, and then wasn’t after I upgraded to 3.7.0 and added the custom domain. I’ll try the filter, thanks.
In a dev environment, I’ve created a plugin with the filter and added the custom domain in the Auth0 plugin (v 2.7.0) interface. I have debug mode enabled without seeing any problems reported.
The invalid state error is gone, but I’m back to seeing the Safari login error that prompted me to start looking at custom domain: “Failed cross origin authentication: Unable to configure verification page”. Nothing is reported in the plugin error logs. The Auth0 dashboard errors look pretty much identical, except that the “hostname” for the dev login is the custom domain.
Any ideas where I should go from here?
So, just to be clear, the remaining error is just the one in Safari? And that’s showing at the top of the Lock login screen? Any other browsers getting this?
Make sure you have your WP site domain name in the “Allowed Web Origins” and “Allowed Origins (CORS)” fields on the Application settings page in Auth0.
Firefox and Chrome worked, Safari failed. I ended up resolving the Safari problem by adding configurationBaseUrl to the plugin’s Extra Settings.
I checked with a Windows Chrome user who has historically been seeing the invalid state error (most problems were Safari users with the “unable to configure” failure). Fortunately, he’s no longer seeing the invalid state error. Unfortunately, he’s now seeing the “Unable to configure” error that had previously been limited to Safari.
After what appear to be a successful login, the lock widget disappears and the user sees a white page that says:
There was a problem with your log in: Unable to configure verification page.
[error code: server_error]
← Login
The Login link goes to /login/?skip_sso .
I ended up resolving the Safari problem by adding configurationBaseUrl to the plugin’s Extra Settings.
What URL did you use? That should be added automatically based on your tenant:
https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_Lock10_Options.php#L196
Unfortunately, he’s now seeing the “Unable to configure” error that had previously been limited to Safari.
Sounds very similar to what is described here:
https://community.auth0.com/t/unable-to-configure-verification-page-error-on-hosted-login/9214
That’s a server error returned by Auth0 and if it’s only happening in Windows Chrome (also mentioned in the thread above) it might be a setting problem there.
That thread mentions a Cross-Origin Verification Fallback setting, which might be good to try just in case. The one I have is set to:
<?php echo add_query_arg( ‘auth0fallback’, 1, site_url( ‘index.php’ ) ); ?>
^^^ Run that in a WP environment and you should have the right one.
That said … this fallback is used when trying to do cross-origin authentication, which the custom domain is meant to prevent. This might be a cache/cookies issue in the browser itself. I would try having them clear cookies and cache for the site and trying again.
I added https://cdn.auth0.com.
I’ve read that topic a few times, but hadn’t really considered using suggestions there since this system is using a Custom Domain.
What cookies should the user remove? This is the first time the user has attempted to login at this specific domain, though the old authentication domain and the new custom domain *are* the same used for other systems to which the user has attempted to login. I’d rather not ask users to delete all cookies.
> I’d rather not ask users to delete all cookies.
No, I don’t think it’s sustainable to ask all users to do that but I’m wondering if you can ask this specific user to try that. If it’s their first time then that’s probably not going to help though.
If your tenant is US-based (tenant-name.auth0/com) then that’s the CDN URL that should be used automatically. You can check by removing what you added and searching the login page view source for configurationBaseUrl.
Did you try the “Cross-Origin Verification Fallback” setting under Applications > Your App > Advanced settings at the bottom > OAuth tab? You shouldn’t need that with a custom domain but that’s what the error message sounds like it’s asking for.
I’ve gotten Universql Login and Custom domain working correctly together, so I’ve not followed up on the exact problem here. As far as I’m concerned, this issue can be closed.
FWIW, I did determine that the problem for the Windows Chrome user was due to third-party cookies being disabled (even though it shouldn’t have mattered).
Thanks for your help,
Matthew
Great to hear @matthneedh and thanks for checking back in on this thread as well. If you have any feedback around docs or anything that might have made this easier, I’m all ears!
