Kyle

Awesome, case closed!

Hi @auth0josh. Sorry for the late reply. I’ve been under the weather. In regards to your questions above:

Let me correct this statement:
I had it set so that Login Redirection URL was sub.domain.org/?auth0=1

Basically, it sounds like what you wrote above, the Login Redirection URL cannot be have “auth0=1” in the GET parameters? Is that correct?

What I wrote above was just to say that that was the problem. If that is the case, there should be a note somewhere that that is not allowed.

Hi @auth0josh, I believe this is an error in the plugin, but let me know if otherwise. I finally found out how to fix it and the original problem, so here it is. First, I’ll put what I have now, then I’ll put what I had before and why I believe this might be a plugin error.

Now:
I have it set so that the Callback URL is sub.domain.org/?authlogin=1 (just a sensical, but a semi-random string). This meant that when I clicked login it would:

1. Take me to Salesfore Community, where I would sign-in (or automatically be redirected if already signed in)
2. Direct me to domain.auth0.com/login/callback?code=LONGSTRING
3. 302 Redirect to sub.domain.org/index.php?auth0=1&code=LONGSTRING&state=STATESTRING where it succeeds the state check.
4. Then finally a 302 redirect to sub.domain.org/?authlogin=1. At this redirec, it does NOT do a state check.

Previously:
I had it set so that Callback URL was sub.domain.org/?auth0=1. This meant that when I clicked login it would:

1. Take me to Salesfore Community, where I would sign-in (or automatically be redirected if already signed in)
2. Direct me to domain.auth0.com/login/callback?code=LONGSTRING
3. 302 Redirect to sub.domain.org/index.php?auth0=1&code=LONGSTRING&state=STATESTRING. NOTE: this URL had a response header of auth0_state=deleted. Everything works up until this point, specifically the validation functions you’ve listed above in the WP_Auth0_LoginManger.
4. Then finally a 302 redirect to sub.domain.org/?auth0=1. However, at this point, because auth0 is a $_GET parameter, it attempts to validate the auth0_state in $_COOKIE and $_REQUEST. The problem is that those don’t exist because the only $_GET parameter is auth0=1 and the cookies have already been deleted from the header on the previous redirect. At this point, it is completely logged-in (but has no auth0 state as a result of the previous headers that were a response to a successful login).
5. My Conclusion: It should either not let the callback URL to be ?auth0=1 or it should have some login to prevent a state check when the callback URL is ?auth0=1 and that login has already succeeded.

Last question:
Why does this appear in my error log every time when I use the setup wizard, when the client grant did, in fact, have the correct permissions? Is it a just a warning to double-check that? It’s just a little confusing.
A client grant for <client_id> to https://domain.auth0.com/api/v2/ already exists. Make sure this grant at least includes update:clients, update:connections, create:connections, read:connections, create:rules, delete:rules, read:users, update:users, update:guardian_factors.

Hi @auth0josh, I checked that and it showed that the $value matched $_COOKIE['auth0_state'] and was returning true in the response.

Any other ideas? And this was working before I upgraded the plugin.

@auth0josh -> correct, held for moderation. Here’s a screenshot of it: https://cloud.designanddevelop.io/3H313n0j433U

I did another round of tests, and realized previously I accidentally looked at the wrong cookies (the ones that were with the page requests in Chrome Develop Tools -> Network -> Page instead of the current cookies in Application -> Cookies -> Website. So the cookies do line up after all. As well, I was able to find the header I mentioned I couldn’t find earlier (auth0_state=deleted).

In that case, here is where we are at:

1. Doing this in incognito.
2. auth0_state Cookie is set
3. Cookie matches JSON value
4. Put snippet in wp-config.php
5. The printed info shows the $_COOKIE array has an auth0_state that mathes the $_REQUEST state, as well as a value for code. Lastly, the $state_val includes a blank value for interim, a full value for nonce and the proper link for redirect_to
6. Response headers on sub.domain.org?auth0=1 include:

   age: 0
   cache-control: no-cache, must-revalidate, max-age=0
   cf-ray: 44434a93d8595606-ORD
   content-language: en-US
   content-type: text/html; charset=utf-8
   date: Thu, 02 Aug 2018 20:28:30 GMT
   expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
   expires: Wed, 11 Jan 1984 05:00:00 GMT
   server: cloudflare
   status: 500
   strict-transport-security: max-age=31536000; includeSubDomains; preload
   vary: X-Forwarded-Proto,Accept-Encoding,User-Agent
   x-cache: MISS
   x-content-type-options: nosniff
   x-ua-compatible: IE=Edge,chrome=1
   

7. I have Auth0 setup to work with one provider only (salesforce community). So here is the path of redirects from SalesForce Community:

• domain.auth0.com/login/callback?code=LONGSTRING
• 302 Redirect to sub.domain.org/index.php?auth0=1&code=LONGSTRING&state=STATESTRING NOTE: This has unique headers which I have put at the very bottom.
• 302 Redirec to sub.domain.org/?auth0=1 NOTE: This has the headers I listed above. It is a response 500.

• Query string parameter value for state matches the JSON and Cookie value from Step #3
• Removing the debugging script and retrying does the same thing, even in incognito windows
• No problem
• $_COOKIE and $_REQUEST states match each other here.

My only guess here is the 2nd line of item #7 (302 Redirect to sub.domain.org/index.php?auth0=1&code=LONGSTRING) has these headers, does this have anything to do with it:

age: 0
cache-control: max-age=30
cf-ray: 444354bb4c569f05-ORD
content-language: en-US
content-type: text/html; charset=UTF-8
date: Thu, 02 Aug 2018 20:35:27 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Thu, 02 Aug 2018 20:41:18 GMT
location: https://sub.domain.org/?auth0=1
server: cloudflare
set-cookie: wordpress_sec_1234=email%domain.org%LONGSTRING; expires=Fri, 17-Aug-2018 08:40:49 GMT; Max-Age=1252800; path=/; secure; HttpOnly
set-cookie: wordpress_sec_1234=email%domain.org%LONGSTRING; expires=Fri, 17-Aug-2018 08:40:49 GMT; Max-Age=1252800; path=/wp-admin; secure; HttpOnly
set-cookie: wordpress_sec_1234=email%domain.org%LONGSTRING; expires=Fri, 17-Aug-2018 08:40:49 GMT; Max-Age=1252800; path=/wp-content/plugins; secure; HttpOnly
set-cookie: auth0_state=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; Max-Age=0; path=/
status: 302
strict-transport-security: max-age=31536000; includeSubDomains; preload
vary: X-Forwarded-Proto,Accept-Encoding,User-Agent
x-cache: MISS
x-content-type-options: nosniff
x-ua-compatible: IE=Edge,chrome=1

• This reply was modified 6 years, 7 months ago by Kyle.
• This reply was modified 6 years, 7 months ago by Kyle.
• This reply was modified 6 years, 7 months ago by Kyle.

Oh foolish me, I skipped the first couple of steps because the few after that were working. All the steps work except step #3 (because of a mismatch with the value from step #2). The only exception is that step #7 (Also in the response headers, check that set-cookie includes a directive like auth0_state=deleted so we know the validation process is happening.) I don’t see the “set-cookie” header of “auth0_state=deleted”, but the cookie is deleted, so maybe that is working anyways? But regarding step #2 and #3:

For these two steps:

#2 Check that the auth0_state cookie is being set (in Chrome, View > Developer > JavaScript Console > Application tab > Storage on the left > Cookies > domain being tested, look for an auth0_state cookie with a non-empty value). If this value is not set, check for errors in the JS console and that your browser can accept cookies (login will not work without cookies). This is set in /assets/js/lock-init.js (code on GitHub)

I can get the auth0_state cookie here from the page Cookies:

#3 If the value is set, copy the value and view the source code of the page (in Chrome, View > Developer > View Source). Search for that value in the code and it should appear in JavaScript as the value of wpAuth0LockGlobal.auth.settings.state (sample JSON). Make a note of this value by copying and pasting into a text file.

Then I found the value in the CDATA of wpAuth0LockGlobal.auth.settings.state DOES NOT match the value in the Cookie that I copied above.

It looks like the cookie is a concatenation of a few different things, because the first 35 characters match, then the last 76 characters match, but the middle 85 characters to not match.

So @auth0josh, what’s your ideas on next steps for mistmatching state values for the Json and Cookie?

Hi @auth0josh, exactly which troubleshooting steps are you referring to? I’ve tried all the troubleshooting steps I can find, but if there’s anything else I can do, I’d be happy to try it out. Or should I try to raise an issue on GitHub? My live site is practically a test site at the moment because the entire site is hidden to non-users, so I’m good to do whatever tests are available.

Thanks @auth0josh.

The reason I had said it was not cached was because when I visited the URL, the headers were:

age: 0
cache-control: no-cache, must-revalidate, max-age=0
expires: Wed, 11 Jan 1984 05:00:00 GMT
server: cloudflare
x-cache: MISS
x-content-type-options: nosniff

However, I added a Cloudflare page rule as well that is setup to match:
*domain.org/*auth0=1 (callback url is https://sub.domain.org/?auth0=1)
And the setting applied is:
Cache Level: Bypass

But I’m still getting the “Invalid state.” Above you said that it needed to hit the server directly, but as far as I know, that is impossible without disabling Cloudflare. The article you referenced would be for disabling cache, which still serves the request through Cloudflare’s proxy, it just ensures that it delivers an “uncached” page (or the “Server” will still be “cloudflare”).

If a Page Rule is set to “Bypass Cache”, then the resources that match that page rule will not be cached. Note that we will still act as a proxy, and our other performance features will still be active – content just won’t be served from our cache and fetched from the origin directly.

Source: https://support.cloudflare.com/hc/en-us/articles/202775670-How-Do-I-Tell-Cloudflare-What-to-Cache-

Thanks @auth0josh,

I was able to go through and try a few different things, and it is logging in, but the initial callback URL is showing:

There was a problem with your login: Invalid state [error code: unknown]

I can confirm that callback URL is whitelisted in Auth0. As well, it is not cached, and I have turned off all caching (see the headers on it here): https://cloud.designanddevelop.io/403a3l2V2F3W).

Before I hit login, the cookie “auth0_state” was set, but after I clicked it, and it went through it’s redirection, the Cookie was no longer set. However, the “wordpress_logged_in” cookie is set afterwards. So if I then navigate to any other pages, it shows me as logged in.

Do you have any further ideas?

Thanks

@auth0josh, unfortunately, I am NOT able to login. The error message appears when I run the setup wizard, but not when I attempt a login. When attempting to login, I don’t receive an error message in the log, but I do receive this message on the screen: https://cloud.designanddevelop.io/0B1P361W0J0o

Basically:
– Login is not working at all
– I receive an error in the log when running setup wizard
– I do not receive an error message in the log when attempting to login

Negative, @auth0josh, here’s a screenshot of the options in the table that have “auth0” in the option name: https://cloud.designanddevelop.io/13331v0U1F3D

And here’s a screenshot of what happens when I try to login:
https://cloud.designanddevelop.io/0B1P361W0J0o

However, there is nothing new in my error log. Just the message from earlier:
`07/30/2018 18:25:00 WP_Auth0_Api_Client::create_client_grant unknown_code A client grant for ****** to https://SUBDOMAIN.auth0.com/api/v2/ already exists. Make sure this grant at least includes update:clients, update:connections, create:connections, read:connections, create:rules, delete:rules, read:users, update:users, update:guardian_factors.

• This reply was modified 6 years, 7 months ago by Kyle.

Hi @auth0josh, thanks for the help. Unfortunately, it is still not resolving the issue. I can confirm that I’ve doublechecked the two steps you mentioned above. As well, there was not an option in my option table called, “wp_auth0_grant_types_failed”.

The token I generated was from APIs -> Auth0 Management API -> API Explorer -> COPY TOKEN.

Do you have any other ideas?

Ah, I was using the shortcode. Interesting, here is what was happening:
– Shortcode was just vanilla [auth0], but it was ignoring the Login redirection URL from the settings. When I added “redirect_to=’example.com?loggedin=true'” to the shortcode, it started to work.
– wp-login.php/wp-admin have been ignoring the Login redirection URL from the settings, but they have not had the caching problem that was happening on the page using the shortcode login

So when is the “Login redirection URL” from the settings used?

I have completely uninstalled all caching plugins and the problem is persisting.

Interestingly, I have the “Login redirection URL” set in the plugin, but it seems to be ignoring that. Any idea what might prevent that from triggering?