Redirect Loop

By: Aaron Echols user 30 Jun 2016 at 6:08 p.m. CDT

12 Responses
Aaron Echols gravatar
I've got Google SSO working now as can be seen [here](https://support.gluu.org/integrations/google-sso-2898#at11939), but I'm having some random issues with some Redirect loops. It's happening on both hosts, no matter which is hit. I've enabled CE clustering as outlined [here](https://www.gluu.org/docs/cluster/), and all seems to work well. All users are syncing and available from either host, I'm able to login, configs are synced, etc. I've setup Zenloadbalancer in front of the two hosts and _**have had it setup that way since it was a single host setup, before I got Google SSO working**_. I'm using Cookie persistence with JSESSIONID. I've disabled cookie persistence and enabled only IP persistence, and the issue remains. I don't believe that the issue is the load balancer, but rather something within Gluu's setup. Any ideas on what is happening on the constant redirecting? It will do infinitely, until the browser tab is closed. Thank you in advance. :) Please see the log [here](http://paste.ubuntu.com/18199663/) for an example of the redirect loop. See the image below, they register as login failure's. ![Login Failures](https://lh3.googleusercontent.com/Dv0yIbVR20CJkUX3hR6UILC5rCCk5fQIkkhXOqp8dcp9t3wF-3V176IIxT8qoPEZXYmckUcDq_4_WkERE-F5CBlfR-YSas2exfVY1X5YyKobrAbKE8q5Gp036jMSBYt8i4gZh4zn7VIK0azugc6ekGOIel_VH5Gl00qqvJgPeTvPyb6m5g0ps7rwW3RvcQ2ej9w4x0-kcvJavmRVwUksk4AFmK6vt2I0rJV9hjwG0RwjuViLZES8obf9yOnTcLFeqA6UpRMNZtukeZUubKzLk9z0yPKxVX6eG5Sikebv--566tFm7h_izjzYihEhvZYm-aEA1O52Z8JSS-tDIV3re0jkSOy2y4VM0PYem543X07Sx1wYh1SHE9N_ljeWtCLzDeLRPC_ANhY93nv9wxFg_DdFCoRXXX9JzPnbUh8iKy2lSXZe6o_-LyLA7InrEUBsnXh31okKyypfn33-iiDpwZOcSeWWvWb33oyW91BaNVgWFbutj7lPrLl6i2sQOB0vfNPNjxd-vCvnV897_FUgBBaLkvUyk7zzP4_Dk6uC-CqikZzl9Ckt8BFzbfVlD4-vi_Xk67hyZh5TtZKlC6X5cQ-j96l0Nrs=w1661-h338-no "enter image title here")
U1404
closed

Answers

By Aliaksandr Samuseu staff 30 Jun 2016 at 6:40 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Aaron. Could you please elaborate a bit, what is the issue you are experiencing? Regards, Alex.

By Aaron Echols user 30 Jun 2016 at 7:02 p.m. CDT

Copy
Aaron Echols gravatar
When logging in, it will randomly loop after authenticating. The log in the OP shows an example. I can't seem to reproduce it, but when it happens, it's the same log.

By Aliaksandr Samuseu staff 01 Jul 2016 at 6:17 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Check Apache's logs in the container for 403 forbidden HTTP errors at the same time as this happens. If you'll see a lot of them, the culprit may be a selection of anti-(D)DOS modules that are enabled by default in Gluu's Apache package. They are marked with comment in Apache's configuration file, it will be easy to find. You may try to reconfigure/disable them in such case.

By Aliaksandr Samuseu staff 01 Jul 2016 at 11:31 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
It seems it may not be that easy to find in Ubuntu package, actually (it seems Apache configuration there differs slightly in comparison with .rpm packages). I'm talking about `mod_limitipconn`, `mod_evasive` or `mod_antiloris`, any of them has a chance to be enabled, check by running something like `# apachectl -M | grep ipcon` and so on.

By Aaron Echols user 02 Jul 2016 at 10:34 p.m. CDT

Copy
Aaron Echols gravatar
Thanks. I forgot to check the apache frontend to see what modules are loading. I'll take a look and report back on what I find. :)

By Aaron Echols user 03 Jul 2016 at 2:23 a.m. CDT

Copy
Aaron Echols gravatar
So I disabled mod_limitipconn and mod_security, neither resolved the issue. [Here](http://paste.ubuntu.com/18359139/) is a snippet of what it looks like from the httpd side when it is stuck in the redirect loop. [Here](http://paste.ubuntu.com/18359527/) is the tomcat side. [Here](http://paste.ubuntu.com/18360935/) is the oxauth.log

By Aliaksandr Samuseu staff 04 Jul 2016 at 12:07 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Aaron. It's hard to draw any conclusion as picture we have is still quite fragmented. Can I ask you to create a capture of the whole this "looped sequence" from your browser perspective? Some tools that could be easily used for this: 1. [FiddlerCap](http://www.telerik.com/fiddler/fiddlercap) (Windows-only) 2. You also may try installing Firebug addon for the Firefox, and use method described [here](https://knowledge.kaltura.com/faq/how-capture-network-traffic-logs-kaltura-support#firebug) (or may be some other method mentioned on the page will suite you) 3. As a last resort you could use "SAML tracer" Firefox addon, it allows to export all captured HTTP packets, but it's not very convenient. 4. If you are already familiar with this kind of tools, Burp or ZAP or Fiddler proxies may be the best choice for you. Currently, judging by Apache's log, it seems that browser is being redirected from the Google's SP with a SAML request, then (probably) redirected back to it with a correct SAML response, then again is sent from Google to Gluu, and so on. Please disable any encryption for this TR explicitly (if their SP doesn't require it be enabled, of course), so we could decode SAML messages from the capture.

By Aaron Echols user 05 Jul 2016 at 12:55 p.m. CDT

Copy
Aaron Echols gravatar
What are you looking for, the SAML response during this loop?

By Aliaksandr Samuseu staff 05 Jul 2016 at 1:03 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
This too, yes, but also it would presented much more coherent picture of what is happening. Like, from these logs it's hard to see whether browser is sent to some other hosts during the flow, for example. Where it's looping at, is it staying all the time at Gluu's host, or it's bouncing between Google's SP and Gluu's host etc? What possible error messages are being passed back and forth etc.

By Aaron Echols user 05 Jul 2016 at 1:04 p.m. CDT

Copy
Aaron Echols gravatar
Ok, I've got a full log. Let me see how to export it from Chrome's dev console.

By Aaron Echols user 07 Jul 2016 at 3:07 p.m. CDT

Copy
Aaron Echols gravatar
I have resolved the issue. It was happening when I used my custom CNAME's pointing to the calendar webapp on ghs.googlehosted.com. I have multiple domains in my account. So if I had a user in domain1.com and used calendar.domain2.com, it would occasionally cause issues with the loop. When logging in via a user in domain1.com and using calendar.domain1.com, it would work everytime. I was able to verify this by disabling the calendar on domain2.com and attempting to login with the user on domain1.com at calendar.domain2.com. When I did this, it would redirect loop infinitely as well, same exact symptoms and same logs. When I logged in with the user from domain1.com to calendar.domain1.com, it worked perfectly. Sorry to waste your time on this one :)

By Aliaksandr Samuseu staff 07 Jul 2016 at 4:33 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Thanks for sharing your findings, Aaron, good to know it's resolved. I'm closing the ticket now, then.

Post an answer