Possible Caching Conflict

Hm yeah, the Pantheon page cache (Varnish) could be the culprit, I noticed the default cache lifetime is 10 minutes: https://docs.pantheon.io/guides/wordpress-configurations/wordpress-cache-plugin

I also confirmed (I have one site hosted on Pantheon) that /wp-admin/ is *not* cached, but /wp-login.php *is*. Since the URL you posted above is a GET request to wp-login.php, it’s possible the unique authentication code being sent from Azure is not getting parsed until the cached version from the last visitor expires.

Maybe worth reaching out to Pantheon to see if they can exclude wp-login.php from the Varnish cache? Not sure if they do that intentionally, or if it’s an oversight (I think normal WordPress logins submit a POST request to wp-login.php which will automatically bypass Varnish).

Pantheon support with the following thread. Would your recommend trying to add wp-login.php per the “Bypassing Cache with HTTP Headers” document linked at the end to see if that would help?

From Pantheon:

May 6, 2024, 9:03?AM PDT

Hello Michael,
?
I am Carey,? a Senior Customer Success Engineer here at Pantheon, assisting you today. ?I have read your concern regarding the cache exclusion of wp-login.php, ?I found it strange when I checked the URL https://www.lasalle.edu/wp-login.php the value of cache-control is no-cache.
?
Here’s the result in curl:
?

?
The result in the browser:

?
A normal WordPress login URL is bypassed via Varnish, it would be all the same on the default WordPress install in Pantheon. ?Let me know if the information has been helpful.?

My response:

When we get the error, it is adding a string after wp-login.php.

For example:

https://our.site.com/wp-login.php?code=0.ATUAe_M2EFkNnEiogBpq69K9B9z9mnqgE0RGlFCdudvtexo1AAA.AgABBAIAAADnfolhJpSnRYB1SVj-Hgd8AgDs_wUA9P_998thzLE85d8dfya-WLvUjJlITQgMJfyLE9hHxQZC5NxoJTGUAM0EDBqGMHfa_qSLNx6FPDVnnaEL9Gv5NcM45YjosAv8N6aHxFFoYwf63_YuAoaLnf2CcWWldy5dn-pbXEu_QqOGAslVVf7ctU01UdW9KfO0eI6VGLX1AihMOHFDMgFa8iaM6fWR8M91H1ndrk7seYGMwNwoAJCSfbNYg65Juyj5-umC6lJB3Z4zQM3bMIRdq66wOM5qSsK8wQkByaSbdfuEhBFCGjqztryP8h2sLFZ2Deez3JK3nf9G7iiVP8XRzX3_cB1vodt-kBI_TVvAYxY0XtonKzDyXrLsohuprBvHWkjKiavP7Rr5bgDvfkp5v4uqnnb85y9BgTvbgy_HTtytSP3P6mocKNctk-OkpOcB4ZGuFGWNVqAxn6wUmD6Nka8zLS1ODyj1oEuAq8lGKVuIRC71e3qvP7LmKr0TtgCja2pD7DbksDBkOMfRRWukjGMk98eK7k5xn8PoZL6cNBskjeYI1l-gxLtGKqeUSSlQF7BkPEX2WucDG6jF_xpNPLoNeMleZtMgqj5aO1T9O3D1WGuHn3PQgfl5D92R0itdU2FX2wioUrIUrRvdxDHjy3GdHZWJsyDDrlFqSFL7hMTqCREULF-oZ8URxX_zjuGZ7xy2YAi6emYshDjAugF_6yBc_aadidpnsYaIdjgZN3LKM6z9MWOISi27IK85xJAGaSGylM7qahwdbElFwykfaVmOjQY8aF4w-R6nRRDrAj_bCgkXiBaQVdxrasaHXv41a9dLt0rDW0PR&state=29faea0d242a749fe96101fee928a0b4&session_state=3fc0d5b3-95e1-49a8-9ef6-1feee9a5a686#

This has only been seen in effect in our live environment. We have not been able to replicate in dev or test.

In our production environment, when users login during a fresh browser session, they get a blank screen. The admin dashboard will load, but only after refreshing the page 5-10 times. We think it might be caching related and are at least trying to rule that out.

Would adding info after wp-login.php bypass the Varnish exception?

Last response from Pantheon:

May 6, 2024, 9:55?AM PDT

I would like you to know that logged sessions are not being cached in the edge servers.  Adding info or params on wp-login.php usually breaks the cache additionally there is a header that would bust the cache on wp-login.php unless  a plugin is overwriting it,   here’s our guide in bypassing cache https://docs.pantheon.io/cache-control

You’re right, I do see the varnish cache being skipped now for wp-login.php. (When I looked before I think I saw a 301 redirect that was cached by varnish on my site, but I confirmed the redirect location was not cached).

That said, I set up Authorizer on my Pantheon site and think I reproduced the behavior in production. I tried a CAS backend and noticed the authentication request timed out at the Pantheon reverse proxy with “The application did not respond in time” when the WordPress server was attempting to verify the authentication ticket with the CAS backend (which I believe is a curl request from the WordPress server in PHP). Perhaps Pantheon’s security prevents their WordPress backends from making curl requests to remote servers? My screenshot is below.

https://docs.pantheon.io/guides/errors-and-server-responses/external-web-service-calls

Pantheon support responded with the below. I’ll see if anything can shed light from our logs. Would you be able to do the same and/or have other ideas?

Awesome work. ?Thank you for providing the above information. ? I want to clarify that Pantheon would not block any external curl request, ?a 504 might mean a timeout error, and the application might be reaching the allotted time to complete. ?https://docs.pantheon.io/timeouts
?
Your team might want to look at php-slow.log as they likely coincide with the slow PHP process. This article should provide further insight:?https://pantheon.io/docs/php-slow-log

There was nothing in Pantheon logs that I saw. And I never did get the request to complete, even after about 10 refreshes, so it’s unlikely a slow process. It very much sounds like a networking issue. Perhaps the auth server (in our case CAS) is blocking the pantheon traffic? Unfortunately I do not have access to that at our institution. Are you able to see any traffic from your Azure AD server?

We had been using CAS and switched to SAML with Azure. It seemed to improve by switching from CAS to SAML, but our CAS instance was passing or using SAML under the hood. We thought simplifying the authentication to be directly tapping into SAML would solve the issue. While it seemed to reduce the number of refreshes needed, it did not go away. Weird that it does not seem to occur in our dev or test environments. I have access to our Azure portal. Not an expert. I can see success entries in the sign-in logs. But I think it is signing in fine. Is there a specific thing I should be looking for in regards to traffic? Today, I checked off/activated the “OAuth2 automatic login” option in the plugin. It seems to be helping, but need to test it over time. Chrome seems to behaving a bit better with that, while Edge is not so far.