Open marepa opened 3 months ago
I'm not clear on how this is a bug with the plugin. The state is generated by the plugin and is valid only for a certain amount of time. If the WordPress login page is left sitting for longer than 3 minutes then the state will have expired and will no longer be valid. The state is stored as a transient and generated when the login button is generated. I personally manage a large number of sites that are each using multiple web server instances and auto-scale and there isn't an issue except for when the Login page is left on a users screen for more than 3 minutes.
Yes, I found the code for 3min limit and everything around this. But this problem does not occur when you have 1 instance with GCP, but only if you have more (or the one you were connected to was deleted completely).
Our current idea is that the session is with previous instance and not on the one current one. But maybe we are wrong and should look for other things? Can this be like indication of something else?
Are you using new object caches or databases with each instance? If you aren't sharing the same single object cache and/or database instances with each website instance then that is also going to be a problem. Generally the Invalid State error is due to either the IDP not sending back the state for validation in the request or the state has expired. If you have multiple object caches or database instances involved then it's also possible that the transients aren't available or not being replicated fast enough.
Ok, will test, thanks for the ideas.
Hi, we tried everything and disabled all caches. But basically we login via SSO and back to WP redirect => instant "Invalid state."
It is happening only in PROD where we have NGINX + GCP (multiple instances).
If I redirect from page A to the Auth endpoint of the IdP it throws the error (the wp-login.php page is an exception). On other sites using the same IdP I do not get the error only on the sites with the redirect and then only when following the redirect flow (following either the "Login with OpenID Connect" button directly or manually navigating to wp-login.php with SSO enabled do not throw the error).
Steps to repeat: -Configure oidc with idp -Create redirect from any page (except wp-login.php) to the auth endpoint of the idp -Oidc returns "Invalid State"
So, if you are using the login button or auth URL to be used on another page I think you are improperly caching the page. The button or the URL has a state nonce that is included in the URL, that expires quickly. If you catch the output in any way then you are going to get an invalid state. Using the WP login page more than likely is never cached
ok, gotcha, I should have seen that. Thanks!
Hi, we are experiencing the same issue. On our site we added the W3 Total Cache plugin and it is giving the invalid-state error on login. Do you know how to solve this? To perform login, we use an anchor pointing to [openid_connect_generic_auth_url].
We do have this quote often and today - right as I was typing this report - it finally occurred to me. We use Google Cloud Platform + custom SSO server. And we think that the problem lies that there are 2 (or more) instances, so that user logged-in in the first one and trying to logged-in inside the second one gets this issue.
This problem seem to occur only when second instance of GCP is activated. Not in local ENV (Laravel Valet) and not in DEV (only 1 instance forced at a time).
What happend to me step by step
Expected behavior Logged in as usual
WordPress Environment