Constant state of re-direct

[tghastings]

I've been using the plugin without any issues for the last 2 months. Today, however, when I go to login I'm in a state of constant redirect. Any one else having issues?

[tghastings]

Working now. Almost seemed like the graph API went down.

[psignoret]

I don't know of any Graph API or Azure AD outage that would have caused this. Let me know if this comes up again and we can look into it further.

[tghastings]

@psignoret Will do. It was really weird. I have the auto-redirect turned on when someone hits the wp-login.php page. It lasted for about an hour or so. I ran a wget on the page and it kept looping w/ the 302 redirect. What was really weird though is when I turned the auto redirect off and went to the wp-login page and clicked "log in w/ my office 365 credentials" I was redirected back to wp-login.php without ever leaving the page. I was running in an incognito window and I wasn't authenticated w/ the site.

[tghastings]

It's happening again. Constant re-direct.

HTTP request sent, awaiting response... 302 Found Location: ?response_type=code&scope=openid&domain_hint=&client_id=c5965c46-d555-4353-bb16-4943296afc3a&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fsomewebsite.com%2Fwp-login.php&state=%7B0ACA481B-84FA-EAF8-B402-D7C29D2DEE36%7D&nonce=%7B0ACA481B-84FA-EAF8-B402-D7C29D2DEE36%7D [following] --2017-05-16 16:31:32-- https://www.somewebsite.com/wp-login.php?response_type=code&scope=openid&domain_hint=&client_id=c5965c46-d555-4353-bb16-4943296afc3a&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fsomewebsite.com%2Fwp-login.php&state=%7B0ACA481B-84FA-EAF8-B402-D7C29D2DEE36%7D&nonce=%7B0ACA481B-84FA-EAF8-B402-D7C29D2DEE36%7D Reusing existing connection to somewebsite.com:443.

HTTP request sent, awaiting response... 302 Found Location: ?response_type=code&scope=openid&domain_hint=&client_id=c5965c46-d555-4353-bb16-4943296afc3a&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fsomewebsite.com%2Fwp-login.php&state=%7B817F106D-8F31-107D-6A17-32E55045D111%7D&nonce=%7B817F106D-8F31-107D-6A17-32E55045D111%7D [following] --2017-05-16 16:31:34-- https://www.somewebsite.com/wp-login.php?response_type=code&scope=openid&domain_hint=&client_id=c5965c46-d555-4353-bb16-4943296afc3a&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fsomewebsite.com%2Fwp-login.php&state=%7B817F106D-8F31-107D-6A17-32E55045D111%7D&nonce=%7B817F106D-8F31-107D-6A17-32E55045D111%7D Reusing existing connection to somewebsite.com:443.

[psignoret]

Did you shorten the URL, or is there really not a &code=[long-stuff] parameter in the redirect?

[tghastings]

There's really not &code it's working again now though. Really weird.

[psignoret]

Ok, well, that explains the redirect loop (presence of code is what tells the plugin not to redirect), and can be addressed so that it fails more gracefully, but I don't know why you're not getting the code in the first place. Can you share details on browser and OS? Also, when it happens, did you test with other browsers and other devices?

[tghastings]

Yeah. I pulled that response info using a wget so it's browser agnostic. Here is a snippet of a wget that works.

wget https://somewebsite.com/wp-login.php --2017-05-16 16:51:00-- https://somewebsite.com/wp-login.php Resolving somewebsite.com (somewebsite.com)... 172.28.1.1 Connecting to somewebsite.com (somewebsite.com)|172.28.1.1|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&scope=openid&domain_hint=&client_id=c5965c46-d555-4353-bb16-4943296afc3a&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fsomewebsite.com%2Fwp-login.php&state=%7B81A971C6-4BDD-9771-BA0F-321B898EE3ED%7D&nonce=%7B81A971C6-4BDD-9771-BA0F-321B898EE3ED%7D [following] --2017-05-16 16:51:02-- https://login.microsoftonline.com/common/oauth2/authorize?response_type=code&scope=openid&domain_hint=&client_id=c5965c46-d555-4353-bb16-4943296afc3a&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fsomewebsite.com%2Fwp-login.php&state=%7B81A971C6-4BDD-9771-BA0F-321B898EE3ED%7D&nonce=%7B81A971C6-4BDD-9771-BA0F-321B898EE3ED%7D Resolving login.microsoftonline.com (login.microsoftonline.com)... 23.100.32.137, 104.210.48.10, 104.42.72.16, ... Connecting to login.microsoftonline.com (login.microsoftonline.com)|23.100.32.137|:443... connected. HTTP request sent, awaiting response... 200 OK

[psignoret]

Actually, I take back what I said earlier regarding the why. I'm reading this much to quickly on an itty-bitty screen, which is not helping. Which OS/browser are you seeing this on?

[tghastings]

I saw it on Ubuntu 16.04 using Chrome and on Internet Explorer on Windows 10.

[SniperXPX]

I am experiencing the same redirect issues as stated above. The issue persists on Chrome, Firefox, and Internet Explorer on Windows 7 x64.

The issue only happens when you do not have valid authentication cookies for WordPress, if you attempt to login without any cookies you get stuck in the redirect loop.

What can I do to help you diagnose the issue?

This is the redirect it keeps going to:

wp-login.php?response_type=code&scope=openid&domain_hint=&client_id=d2a4e291-d577-4c6b-96e7-16740129dc81&resource=https%3A%2F%2Fgraph.windows.net&redirect_uri=https%3A%2F%2Fmywebsite.tld%2Fwp-login.php&state=%7B8540F2FE-1C0C-CB93-8B4B-BDB73D85C270%7D&nonce=%7B8540F2FE-1C0C-CB93-8B4B-BDB73D85C270%7D

[SniperXPX]

Just an update, it seems that the redirect issue is no longer happening. Looking at @lifespent 's comments the issue rectified itself once before and it has now done it again. Perhaps it is something on Microsoft's end?

[aaronware]

I'm still seeing it on an active install. The login will work for a user the first time. Then they will get stuck in the redirect loop after that. I've also seen reports of user saying it acted differently between Chrome and Firefox. Ex Chrome they could login the first time. Firefox they couldn't ever log in (Still awaiting more details)

[psignoret]

@aaronware Can you shoot me an email at [email protected] with detail about your installation? We'll report back to this thread when we've figured this out.

[aaronware]

@psignoret I think it might have to do with our setup. We were using Members(https://wordpress.org/plugins/members/) to create roles and to force users to be logged in. Do you have any suggestions for that functionality? IE we could check if user_logged_in() as early as possible and redirect to a proper URL. Which is pretty much what Members does.

[tghastings]

@aaronware, this might work for what you're wanting. https://wordpress.org/plugins/redirect-to-login-if-not-logged-in/

[aaronware]

Hey @lifespent thanks for the link. Yeah the idea behind that plugin is similar to what I would do. It's really only a few lines to implement. My big thing is just confirming forcing users to be logged in won't cause any issues with how aad-sso-wordpress works

[psignoret]

@aaronware Do you wish to continue using Members, or do you want to move away from it? (In any case, I'll look into possible conflicts with the plugins.)

[aaronware]

@psignoret it's be nice to continue to use the Members plugin as it's great for simple role and capability management and you get a 2for1 with the access restriction (But it is NOT required). There are other plugins (like the one @lifespent mentioned earlier) or Restricted Site Access or custom coding to do the job (literally 1 hook and a simple is_logged_in() would probably suffice. I think it's a matter of hooking properly to not conflict, IE too early, too late. OR EVEN Better. I was going to fork your plugin, add it and do a pull request so that was just an option in the plugin itself.

[psignoret]

I'd like to avoid overloading this plugin, and instead make it play nicely with other plugins that are already good at what they do. Ideally (and without so much as glancing at the Members plugin yet), in this scenario the Members plugin would just require to be signed in, which would "hand-off" the sign-in flow itself to aad-sso-wordpress.

Though I enthusiastically welcome pull requests, in this case I'd like to better understand what's causing this (and hopefully get to a reproducible state) before adding functionality.

[tghastings]

@aaronware Redirect to login is what I'm using with this plugin. Works nicely.

[bradkovach]

It might be beneficial to display a warning in the admin area that there are other applications are hooked to the login hooks... We can't solve everything for every installation but we can be helpful.

// ... snip
global $wp_filter;
if( count( $wp_filter['login_redirect'] ) > 1 ) { // one is expected; for aadsso
     // something else is using 'login_redirect'
     // show warning
}
// ... /snip

Some interesting discussion here: https://wordpress.stackexchange.com/questions/17394/how-to-know-what-functions-are-hooked-to-an-action-filter

You should be able to get a count of the "default" number of functions hooked to a filter by searching the WordPress Git repo: https://github.com/WordPress/WordPress/

[tghastings]

Constant redirect is happening again today

[dotjsprogrammer]

Also experiencing the same - ERR_TOO_MANY_REDIRECTS after trying to login.

[SniperXPX]

I was getting this error sporadically throughout my Wordpress site so I did some more digging around. Turns out Google Chrome caches a 301 redirect INDEFINITELY in the local cache if there isn't an expiration set in the Cache-Control headers. So I installed the plugin HTTP Headers and added a custom header Cache-Control: max-age:60 See more info here https://stackoverflow.com/questions/9130422/how-long-do-browsers-cache-http-301s

[psignoret]

@SniperXPX Did this solve your issue, though? None of the redirects done by this plugin involve a 301 redirect, which is supposed to be cached (301 is a permanent redirect). A 302 redirect, which is what the plugin uses, is not cached by most modern browsers, since it's the basis of most browser-based sign-in flows (e.g. OpenID Connect, OAuth 2.0, SAML 2.0, etc.).

[awlawl]

I was just having this issue but I might have figured out my problem. I was logging in via https but my "Redirect URL" was http. So far so good over the past few hours.

[nilsree]

Having the same problem. Checked azure app, everything seems fine. Tried creating a new key, same problem.

I can prevent the loop by unchecking the "Automatically forward users to the Azure AD...", but users still can't log in.

[psignoret]

@nilsree Most of the times this happens it's related to other redirects happening. A common case is mixing HTTP and HTTPS URLs. Does the redirect URL start with "http://" or "https://"?

[nilsree]

@psignoret The redirect url was starting with http, but stopped working. I have set up a working SSL-certificate, and changed the azure app sign-on, reply and home page url, as well as changing the site url in wordpress general settings and azure ad plugin settings (http -> https). But, still the same issue.

I've also tried to disable all my other plugins, same issue (even in "fresh" browsers, without any potential cached 301 headers).

Any suggestions?

[bg-wilkesreid]

@psignoret Has any progress been made on this? We use this in tandem with the Force Login plugin, and can't figure out exactly why the redirect loop is happening. The fact that it only happens occasionally and works fine the rest of the time is extremely confusing.

[psignoret]

@bg-wilkesreid What platform stack are you running WordPress on?

[bg-wilkesreid]

@psignoret Ubuntu 16.04 behind Nginx... is that what you mean by platform stack?