manakuke

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.

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

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

Excellent! Thank you ??

Related, if I uncheck Hide WordPress logins, it does work. So as a work around, I can toggle that off for testing. Not a huge deal. We only use the non-CAS/SSO accounts during random/infrequent testing niche testing scenarios.

Thank you for your on-going support for this plugin.

Wildcard re-directs appear to only work at the start or end of the URL string, but not in the middle.

So this worked:

		{
			"url": "https://*.myschool.edu/*",
			"type": "Web"
		}

But this did not:

		{
			"url": "https://www.myschool.edu/*/wp-login.php",
			"type": "Web"
		}

For the email issue, I was able to replace username with emails via the database (xxx_users table) and update superadmins (xxx_sitemeta table, searching for meta_key=site_admins).

Doing the above got me 90% the way to replacing using CAS. I noticed that there is no option to allow automatic login like you can with CAS. Usually not a big deal, but we have a few sites where links re-direct folks to the front end. But by using Azure AD approach, it always takes the user to the back end and prompts for login even if they are logged in already via another application (so not real SSO 100%). For example, we have an emergency alert system that uses WordPress posts to share full event descriptions. All these posts require login. Usually we link students, faculty, and staff to these posts. In testing this with the Azure AD option, after logging in, it re-directs folks to the backend instead of the post. CAS takes you to the front end post. For example, if the password reuired post was https://www.myschool.edu/alerts/2022/12/24/snow-day/ Azure AD authentication takes you to the admin dashboard. CAS re-directs to the post after authentication. I supposes this is a separate issue, but could the Azure AD oauth option allow for the same re-direct and SSO akin to CAS?

• This reply was modified 2 years, 5 months ago by manakuke.

I think there are some possible CORS conflicts. Have tried using various combinations of Web versus Single-page application set up for the URIs with no luck. I can get direct matching with full URLs, but not using wildcards. I did have to add the wildward via the Manifest as it blocked me from adding via the interface. All our test instances have very different URLs that our main prod due to the way our hosting partner manages those.

Regarding the email already used error, it is for my account and I only have one with my email. It’s set to prevent duplicates as is. I wonder if the way I have it configured in the app registration isn’t passing the email correctly so then the Authorizor code can’t correctly perform the explode function and correctly create the username variable? I’ve tried adding different option tokens to see if that would help with no luck. I also tried adding more API permissions with no effect as of yet.

I tried first creating an enterprise app entry so that I could transform username to just use the email prefix. Then took that app to create a new app registration entry in order to create a client secret. Was able to make a connection, but keep getting an error message that permissions need to be approved by admin. We’ve tried removing any api permission as well as adding in app registration graph entries for email, openid, profile, and User.Read in an effort to cover our bases (and had Grant admin consent applied throughout) with no luck. I believe there is some conflict in the method I am using by combining enterprise application with app registration, but haven’t been able to figure it out (if it is even possible).

Just using app registration, I don’t believe there is an equivalent to grab username and remove the prefix like in the SAML claim options for enterprise applications.

Also, I ran into a side issue since we are running multisite. I could be wrong, but it seems to only work if I add a Reply URI for each sub-site. I cannot add the main network URL.

I had the wrong Secret value. Had used the ID. Created a new one and added the value successfully.

I now get an error saying the “Sorry, that email address is already used!” All our usernames we added using CAS and is just username, not [email protected]. But each user account has email. For example, my account has username = nielsen and email = [email protected]. I’m guessing the Azure AD connection is trying to create a new username called [email protected]. I can try adding a new API permission and see if it can grab username. I am more familiar with creating connections via the Enterprise Application feature vs App registrations ??

Any chance this could only apply to one of the multisite tabs? We have some sub-sites that have varying access settings (ie an Alert site where all authenticated users can view and only logged in users can see the site, others that are more public, but we have login in abilities limited to designated users, etc). But we would want the SSO/CAS setting to be the same on all sites. We are upgrading our CAS platform, which will require updating the CAS URL. As of right now, we would have to go through and check every sub0site as we have never documented which sub-sites have custom access lists settings and I don’t believe the plugin has a tool to show which sites may have the multisite option toggle on to override. Maybe the latter would also work as an alternative. Some way to see which sub-sites “Override multisite options” checked.

I believe it’s working. I think my cache or the like just delayed it appearing. So helpful to not need to import ??

I’m having the same issues when trying to edit the Admin Front End section.

WordPress 5.2.4
PHP 7.3.10

I was able to network activate again. Didn’t do anything different. Some strange things going on. I’ll have to review the network issues with our systems folks. We have Authorizor installed on other WP sites with no issue. It’s just our main site ??

Thanks for the quick fix!!!