Login redirects on multisite subdirectory subsites with 2.1

[timmmmyboy]

We had an issue reported on a multisite in which users who were using the More Privacy Options to require a network login were getting an error from the IdP after multiple redirects (I think the IdP was just failing the request after too many attempts). I suspect it may be due to a URL mismatch of some kind, when the user first logs in at the base site all private sites can then be accessed fine but a the subsites could not initiate a session. I rolled back to 2.0.2 and this issue is not present there so something must have changed on that front. Figured I would report it in case it's useful. Unfortunately I only had a temporary login from the school, I may be able to do some testing here in the very short term if they keep my access open. :)

Notes:

• Centos 7 with cPanel
• PHP 5.6
• Apache suPHP
• Shibboleth SP installed at server level
• WP 4.9.6

[jrchamp]

I'm not sure where to begin, because there's a lot of components here which all need to work together for it to succeed. If you are able, is there any chance you would be willing to perform a git bisect? Helping us find the specific problem commit would make it quite a bit easier to start debugging.

[timmmmyboy]

Sure thing, just finished running through that (wow, bisect is new to me, the things you learn...)

c5e732d08610f9c941efde6818e7ed25d9e19e44 is the first bad commit commit c5e732d08610f9c941efde6818e7ed25d9e19e44 Author: Jonathan Champ jrchamp@ncsu.edu Date: Thu Feb 15 17:39:03 2018 -0500

login: Switch to correct blog when building destination URL

:100644 100644 795bebede8c6194a5929b9b163188d67d6f79092 121c232e6ef67eb98592b753e4b571b1a9fcb9c3 M shibboleth.php

[jrchamp]

I was a bit worried it might be that change. Given that that commit fixed the problem of sending a user to the correct dashboard, my guess is that More Privacy Options is set to "Site Members Only" or "Site Admins Only" on the target subsite and is kicking you back through the redirect cycle. Can you confirm that this behavior is only occurring on sites with one of those more-restrictive settings?

[timmmmyboy]

The particular setting is "Visible only to registered users of this network" so basically any user that can login to the network. In this scenario a faculty member wouldn't need to be added to a student's private blog to access it.

[jrchamp]

I surprised that it's failing with the "any user". How many networks are there on that multisite?

[timmmmyboy]

It's a single network with 185 sites currently.

[jrchamp]

I have a feeling it's the auth_redirect() here: https://plugins.trac.wordpress.org/browser/more-privacy-options/trunk/ds_wp3_private_blog.php#L383

I have a feeling if you checked $_SERVER['PHP_SELF'] you would find wp-login.php, so it might be good to add a check for that at the top of the ds_*_authenticator() functions, something like:

if( strpos($_SERVER['PHP_SELF'], 'wp-login.php')) return; 

[timmmmyboy]

I wrote $_SERVER['PHP_SELF'] to a file and the value is /index.php. Not sure if that helps with diagnosing what my be at play between the two plugins or not. I'm not sure I follow what the checks at the top of ds_users_authenticator() are actually doing, are they situations in which it bypasses initiating auth?

[michaelryanmcneill]

The checks appear to be validating if a user is activating their account. If it does and they're on the main site, it let's things go through. If it does and they aren't on the main site, it kicks them to $network_home_url/wp-activate.php. Just to verify @timmmmyboy, where did you place your $_SERVER['PHP_SELF'] when you were debugging? My thought is the same as @jrchamp's, which is that wp-login.php is getting caught up in this function, causing an endless redirect loop.

[michaelryanmcneill]

Well, after looking more at the plugin code, I'm not so sure anymore. The action that they're using is template_redirect, which should only happen on template page load. What is the default role for the network?

[timmmmyboy]

I had added the check on PHP_SELF to the start of the ds_users_authenticator function. Default role is subscriber.

[michaelryanmcneill]

What other options do you have selected in the general tab?

[timmmmyboy]

Pretty much a default setup with nothing checked.

[michaelryanmcneill]

Okay, so when this occurs, how are users attempting to access the site? Are they visiting the homepage or are they going to wp-login.php or /wp-admin?

[jrchamp]

Yes, the checks at the top of ds_*_authenticator() are there to allow you to access special pages like login that would otherwise send you into a redirect loop.

Due to the subsite relying on the RewriteRule, it makes complete sense that the value would be index.php, so PHP_SELF is not going to work. Instead, I would try:

if ( 'wp-login.php' === $GLOBALS['pagenow'] ) return;

Unfortunately, looking at the code that builds $pagenow, that might not work either but it's worth a shot. Really, you get what I'm trying to do: if the user is trying to load the page that has the login options, then the system should not try and redirect the user to the page that has the login options.

[jrchamp]

I did some basic testing with a simplified version of the plugin, but was not able to trigger the behavior. I would echo @michaelryanmcneill's question. The request sequence would provide a lot of insight into the sequence of redirects that are occurring. I'm wondering if it's possibly sending the user to http when the Shibboleth cookie is stored in https or vice versa.

[timmmmyboy]

A URL mismatch with the Shib cookie would make a lot of sense in terms of how the Shib auth was failing (though we're forcing https with .htaccess and I even checked siteurl and home fields for one of the sites). Tracing redirects in curl it looks like a site set to private is redirected to wp-login.php (specifically /wp-login.php?redirect_to=https%3A%2F%2Fexampleurl.com%2Fsubsitename%2F&reauth=1). I'll see if I can do a trace with a Shib login as well.

[jrchamp]

For reference as you step through the requests, the sequence should be:

1. https://example.com/subsitename/
2. https://example.com/subsitename/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fsubsitename%2F&reauth=1
3. Click Log in with Shibboleth https://example.com/subsitename/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fsubsitename%2F&action=shibboleth
4. https://example.com/Shibboleth.sso/Login?target=https://example.com/Shibboleth.sso/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fsubsitename%2F&reauth=1
5. One or more requests during the login process like https://shibboleth.test/idp/profile/SAML2/POST/SSO
6. https://example.com/Shibboleth.sso/SAML2/POST
7. https://example.com/subsitename/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fsubsitename%2F&action=shibboleth
8. https://example.com/subsitename/

[timmmmyboy]

Apologies for the lack of updates here, it fell off my radar and I no longer have access to a login with that university however we just recently got on setup with another and ran into the same issues. Notably this is not with private sites this time, it is any subsite in which the user is not a user (this is also a subdomain multisite). Will attempt to see if I can log the various paths that it goes through, but the same workaround of rolling the plugin back to the release prior to the change in February fixed it for them as well.

[michaelryanmcneill]

I will do some additional work to attempt to reproduce this, but I haven't been able to up to this point. Any specific steps to reproduce would be super helpful.

[timmmmyboy]

It's admittedly a hard one for us to troubleshoot since we are an outside vendor and rarely if ever given access to a university's identity system with a login for any extended period of time. The fact it happened at two distinct schools was a bit worrying. I'd be happy to put you all in touch with someone at one of these schools if there's desire for that level of troubleshooting. It's not a dealbreaker for us right now because we have frozen the plugin prior to the commit that started causing the redirect, but ideally there's a scenario in which we can allow updates again in the future so anything I can do to facilitate that I'm happy to help.

[timmmmyboy]

Hey guys, unearthing this because the issue has come up for us again. For this particular school they aren't even using More Privacy Options, but the redirects happen on any login with the newer code with the patch from #33. It sounds like #61 might be experiencing the same issue as well. I have a test login to this system and root access on the server if either of you have time to look at it and perhaps see what might be going astray. The school in question obviously wants users logging in to subsites to be directed to the dashboard of that subsite as its causing some confusion amongst their userbase, but until we fix the bug anything past 2.0.2 just breaks logins alltogether with the redirect issue.

[jrchamp]

Any chance the "subsite" login domain doesn't match the configured Shibboleth.sso domain urls?

[timmmmyboy]

It's subfolder multisite and the Shib plugin is set to use relative links /Shibboleth.sso/Login. Is that what you mean? The metadata for the SP would have used the main site's URL for the Assertion URL but was thinking since it's not subdomains or anything subsites should be redirected properly to their own site after login.

[jrchamp]

If the shibboleth plugin is network enabled and AuthType shibboleth is set at the top level (via .htaccess or similar), then it should come down to settings. Does it work for anyone? Is it only working for a few people?

Can you identify which step in the process goes astray from the sequence listed below?

For reference as you step through the requests, the sequence should be:

1. `https://example.com/subsitename/`

2. `https://example.com/subsitename/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fsubsitename%2F&reauth=1`

3. Click Log in with Shibboleth `https://example.com/subsitename/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fsubsitename%2F&action=shibboleth`

4. `https://example.com/Shibboleth.sso/Login?target=https://example.com/Shibboleth.sso/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fsubsitename%2F&reauth=1`

5. One or more requests during the login process like `https://shibboleth.test/idp/profile/SAML2/POST/SSO`

6. `https://example.com/Shibboleth.sso/SAML2/POST`

7. `https://example.com/subsitename/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fsubsitename%2F&action=shibboleth`

8. `https://example.com/subsitename/`

[timmmmyboy]

I finally had a chance to dig in on this with a test login and found that the fix in the server configuration related to cookieprops at https://www.ibiblio.org/archive/2011/10/wordpress-multisite-plus-shibboleth/ worked for this instance. I did not do any patching of the plugin since the article was from 2011 but I did test the server config change in shibboleth2.xml and that was enough for it to resolve the looping redirect issue.