Lock WordPress Plugin Ver 3.5.2 - SSO logging in doesn't work after upgrade

Help
1

Hi,

I have 2 websites connected through Auth0 Lock WP plugin to the same client. Everything was working properly before upgrading to Lock WP plugin ver 3.5.2.

After upgrading to ver 3.5.2 on the first site by following the upgrading method issued by the Auth0 team, I did not encounter any problems on the first site. (I don’t remember exactly whether there were any minor problems. It was couple of weeks ago.)

Seeing that everything went well, I upgraded on the second site, and in the last step, it showed that “Review your Client advanced settings, specifically the Grant Types, and authorize your client for the Management API to manually complete the setup.”

I tried doing that, but still the problem was not resolved.

Few days ago, I exported the plugin settings JSON from both sites, and then I deactivated, deleted, and reinstalled the plugin on both sites. I also imported the JSON. Going through the documentation and other support requests again, I found that I had to update the link in both the sites’ plugins to the latest version of Lock 11, which I did as:

//cdn.auth0.com/js/lock/11.5.2/lock.min.js

Now the problem is that the SSO login doesn’t function. That means if I am logged in on one site, when I visit the other one, I am not automatically logged in. I have to login manually.

But surprisingly, SSO logout functions. If I log out from one site, I am automatically logged out from the other too.

(Both SSO login and SSO logout are enabled in the plugins on both sites.)

I found in my logs on the Auth0 dashboard this error:

Failed Silent Auth
Login required

I would really appreciate a prompt help since after troubleshooting these problems on these test sites, I have to implement the same Lock upgrades in another 2 production websites that also use the same client.

Thanks!

Askmpro

2

Hi askmpro,

I was having the same issue. Currently the SSO feature is disabled by developers in their latest release, but it looks like they are working on a fix for v3.5.3 See the discussion here SSO does not work if Lock is used outside wp-login.php · Issue #407 · auth0/wordpress · GitHub

SSO is working by default only on the /wp-login.php page, but SSO code had been taken out of the footer in the code on line 29. See here https://github.com/auth0/wp-auth0/blob/master/lib/WP_Auth0_LoginManager.php#L29

This is probably because of a conflict with the shortcode provided by the wordpress plugin and the newest Lock11. If you are not using the shortcode to display Lock11, but are manually in code defining and displaying the login popup, you can probably re enable line 29 there and get it working sitewide.

1 Like
3

talamihg, thanks for the info. It is really helpful!

I don’t want to play with manual code. Using shortcode is better.

They should have documented well about this particular disablement. It’s crazy when you see that logging in is not working, but logging out is working! :thinking:

I am going to try with logging in through the wp-login.php page. Let me see what happens…

BTW, do you have any idea they will fix this and release version 3.5.3? It’s frustrating… :confounded:

askmpro

4

I heard that they are working on it to get it out before the new July 16th deadline.

5

Thanks, talamihg!

Askmpro

6

Merging in the report from here:

A bit of technical explanation here … the SSO that happens on wp-login.php is not an excellent solution to the SSO problem as a whole. And the reason it was removed from the footer of the site (thanks for the digging @talamihg) is because that’s pinging our API with an authentication request on every page load for every logged out user. Not a sustainable solution for us, particularly for medium-to-high-traffic sites.

The logout code is still there because that only runs for logged-in users, typically a much smaller portion of site traffic. That said, we’re still running the risk of too many requests and rate limiting so that particular snippet will be removed before too long as well.

The issue posted does, in fact, relate to exactly this issue:

https://github.com/auth0/wp-auth0/issues/407

… but it also generated some internal discussion here at Auth0 about how this type of situation should be handled. Generating that authentication request on every page of an unknown and increasing number of sites just won’t fly long-term.

To be clear, though, the idea of SSO is not to automatically log you into a site when you visit any page, it’s to save you from entering your credentials again when you try to authenticate. So the “fix” here is to link to the wp-login.php page with a redirect_to parameter back to the current page.

@askmpro - hopefully this provides some helpful context. I think this addresses the SSO component of your question here and on the WP forum but if I missed anything, let me know. If not, please check your wp-admin error log and your JS console when things go wrong, that will help me diagnose. You mentioned some possible redirection issues. If those are outside of SSO, let’s start a new thread here to keep things focused.

2 Likes
7

Hi @josh.cunningham,

With regards to your last comment about my question over on Github you said

Just a heads up on SSO … we’re going to be changing that soon to point to the hosted login page, which will make this work like the default login method.

If I understand correctly, I will want a hosted page

  • To use SSO with the default login method that hits the /api/v2/users/{id} Management API endpoint
  • To take advantage of retrieving user_metadata upon the first time registration/login
  • To prepare for SSO no longer using the implicit flow that retrieves data via the id_token

Should I start developing my login flow to point to a hosted page to be prepared for this change?
Do you know roughly when this change to SSO in wp-auth0 plugin will happen (weeks/months)?
How will the hosted login page work with WordPress’s /wp-login.php page, should I setup a hosted page in the auth0 management dashboard, or should I just use the WordPress ‘/wp-login.php’ page?

Thanks,
Harry

1 Like
8

Hi @talamihg,

I will want a hosted page

You, and everyone using Auth0, has one, actually. We use the term “hosted login page” to talk about a login page hosted by Auth0. You can see yours by going to the link below, modified with your Application info:

https://YOUR-DOMAIN/authorize?client_id=YOUR-CLIENT-ID&response_type=code

You can actually use that link now with your WordPress site if you include a callback URL and a state parameter. Happy to provide more information there if you want to try it out.

To use SSO with the default login method

It’s the easiest and most secure way (which is why we’re switching over soon) but not the only way. You can also add custom claims to your ID token using rules, more information here:

To take advantage of retrieving user_metadata upon the first time registration/login

If you’re not using SSO, which you couldn’t if someone was registering, and if Implicit is not turned on, then you should be getting that data just fine. Problem is that it will be over-written with the stripped-down information from the ID token on the next login (if SSO is turned on in the plugin). Known issue and yet another reason why we’re switching over!

Should I start developing my login flow to point to a hosted page to be prepared for this change?

I don’t think that’s necessary, really. The WP plugin will being to do that automatically once that change is in place. We can provide a beta plugin for you to try out earlier if you’re interested.

Do you know roughly when this change to SSO in wp-auth0 plugin will happen (weeks/months)?

The next release should be out in 3-4 weeks, which will not have that SSO change. The one after will come a lot quicker, maybe 3-4 weeks after that. Again, happy to provide a plugin to try this functionality out if you’d like. It would definitely benefit us to have folks trying it out before it goes into the wild!

How will the hosted login page work with WordPress’s /wp-login.php page

People will be redirected from wp-login.php to the hosted login page automatically. Looks very similar to the WordPress page with a dark background. Same exact login widget.

Hope that helps!

2 Likes
9

Hi Josh!

Thanks for the technical explanations. It is clearer now.

(1) Can you give me an example code/link for the “fix”? i.e. how to link to the wp-login.php page with a redirect_to parameter back to the current page (or a different page possible?)?

Let me get to know the way Auth0 SSO works, and if everything goes fine, the other problems like redirection issues I mentioned might not happen. :grinning:

Josh, I followed the other posts by @talamihg and your responses, and am I correct in my understanding?

(2) You are moving in the direction of using the hosted login page for all users as the default login method. It is because it is the most secure method and the metadata problems and other issues with the WP plugin and SSO authentication will be gone/solved. Am I right?

(3) I tried this link with my application info. But it showed the error page on Auth0.

And you said:

Please provide me more information with sample link and code. Thanks. :grinning:

(4) In reply to @talamihg’s question, you said:

I am a bit confused here since the plugin as of ver 3.5.2 does not do the SSO from any page other than wp-login.php.

So once the change to the hosted login page as the default login method is implemented throughout the Auth0 system, will users be able to login/register from any page on the website, including wp-login.php?

(5) Can the hosted login page be completely customized?

(6) So, after going through the discussion, I am going with this solution now. Please let me know your feedback/comments. Here it is:

As the WP plugin ver 3.5.2 allows SSO only from the wp-login.php page, I will direct users to that page for register/login with a redirect_to parameter back to a page on the website. (I need your help with that. Please see (1) above.)

So once a user is logged in to the first website, when he visits the second website, he will not be automatically logged in (he will be visiting the homepage of the website). So there has to be a link to the wp-login.php page on the second website on clicking which the user will go to the wp-login.php page and then will be automatically logged in (and has to be redirected to a page on the second website).

And when the hosted login page will be made the default login method in the future, it should be able to register/login from any page (eg. using shortcode) of the connected websites, including the wp-login.php page. Am I right?

(I don’t know how easy it would be to change to the default method of hosted login page when that will be implemented in the future.)

Thanks! :grinning:

@askmpro

10

Can you give me an example code/link for the “fix”? i.e. how to link to the wp-login.php page with a redirect_to parameter back to the current page (or a different page possible?)?

http://example.com/wp-login.php?redirect_to=http%3A%2F%2Fexample.com%2Fpage-needing-auth

Note the URL-encoded link. Use rawurlencode()

You are moving in the direction of using the hosted login page for all users as the default login method

Correct, in general. We are going to switch to the hosted login page for SSO in the WP plugin in a month or two. For non-SSO usage, the switch-over will come sometime down the road.

I tried this link with my application info. But it showed the error page on Auth0.

There should be a link on that page with more information about what went wrong.

Please provide me more information with sample link and code. Thanks.

It’s going to change after this coming release but a quick sample to show how it works now:

https://TENANT.auth0.com/authorize?client_id=CLIENT_ID&response_type=code&redirect_uri=WORDPRESS_SITE_URL/index.php?auth0=1&scope=openid

Log out of the WP site then go to that link. When you log in, you should get back to WP, logged in. Try that link again about you’ll see how the simple SSO works with the hosted login page.

So once the change to the hosted login page as the default login method is implemented throughout the Auth0 system, will users be able to login/register from any page on the website, including wp-login.php?

I was just saying that there is no reason to switch to the hosted login page now as the plugin will do that in the future. We don’t have specific plans to have an SSO check happen on all pages.

Can the hosted login page be completely customized?

You can do a lot with it, more information here (you’ll see the term “Universal Login” which is synonymous):

Please let me know your feedback/comments

Pretty much right on except:

And when the hosted login page will be made the default login method in the future, it should be able to register/login from any page (eg. using shortcode)

See my answer above. Checking for a session on every page (which is what it would need to do to make that work) is not feasible. You’ll need a prompt pointing to the hosted login page or wp-login.php when an authenticated action is required.

2 Likes
11

Hi Josh!

Thanks for the explanatory reply. Now I understand things better! :smiley:

I found the reason why the hosted login page on my tenant did not work. There was a small error in the link you posted. You wrote “client” instead of “client_id”.

https://your-domain/authorize?**client**=YOUR-CLIENT-ID&response_type=code

The correct format:

https://your-domain/authorize?**client_id**=YOUR-CLIENT-ID&response_type=code

I am going to test with the wp-login.php page, and if I need further help, I will get back to you.

Thanks again for your excellent replies! :+1:

@askmpro

12

Sorry for the mis-info … corrected it above!

1 Like
13

Josh,

One more help request before I dive into testing the flow of things. You gave this generic sample link:

As you wrote in one of the earlier replies, if I want the user to be redirected back to the current page (that means not any page, but the page from which he clicked the login link), how will the link above be? How do I get it done? How do I capture the link of the current page, and how do I integrate it in the link to the wp-login.php page as the page to be redirected to after login?

Thanks in advance. :slightly_smiling_face:

@askmpro

14

See here:

Pass the link to where you want to return to after logging in into that function:

<a href="<?php echo wp_login_url( home_url( $_SERVER['REQUEST_URI'] ) )?>">Login</a>
1 Like
15

Thanks, Josh. :grinning:

16

Josh -

For those of us with custom login pages, is there anyway to force the session check manually? totally understand why you wouldn’t want it on by default, but in some cases, having the [auth0] shortcode do the session check does make sense if you don’t want to expose the user to the wp-login.php page. Thoughts?

Thanks!

Kevin

17

The code for that check is here:

https://github.com/auth0/wp-auth0/blob/master/assets/js/lock-init.js#L9

… and the globals that block is using are generated here:

https://github.com/auth0/wp-auth0/blob/master/templates/login-form.php#L7

This is the same call used for the shortcode but you’ll see in that there is a check whether we’re on wp-login or not. You can include that file and call the function in a custom page template if you want to generate the form on a page that isn’t wp-login (though watch the changelog for major version updates as how that form is outputted is likely to change at some point).

If you’re loading the form on a dedicated login page that you want more control of, then that should be fine. The reason we left it out of the shortcode and widget is that it creates a scenario where the authorization URL will be called on many, many pageloads (when the form is, say, in a sidebar), creating an opportunity to hit a rate limit.

Hope that helps!

18

edit: figured it out.

Thx Josh.

1 Like
19

Super glad to hear that @vertoloadm!

20

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.