On Wed, 25 Aug 2010 12:05:06 +0200, Felix Schumacher <[email protected]> wrote: > On Tue, 24 Aug 2010 23:07:57 -0400, Scott Battaglia > <[email protected]> wrote: >> According to the log, it redirected fine:2010-08-24 08:26:28,803 DEBUG >> [org.springframework.webflow.mvc.servlet.FlowHandlerAdapter] - > That's what I read from those logs, too. > >> If you use Firefox, this plugin can help capture the headers, and all of >> the redirects:https://addons.mozilla.org/en-US/firefox/addon/3829/ [2] > That is the plugin I used to generate the logs in my first mail :) > > I just did another test. If I access > http://portal.../cas-server/login?http://portal.../app1 the browser gets > redirected to http://portal.../app1. If on the other hand I call > https://portal.../cas-server/login?http://portal.../app1 the browser will > end on https://portal.../app1. I think I found out, why this happens to me. As I said in an earlier mail portal... is the name of our loadbalancer. That loadbalancer is our ssl endpoint. So cas will always believe it was called by http. Webflow doing the redirect might check if the redirect would go to the same domain and the same scheme and doing only a relative redirect, if they match. Thus ending up with the protocol of the login-page.
That would mean that live http headers plugin expands the redirect to an absolute one in displaying the url in the logs. Could this be? Felix > > Regards > Felix >> >> On Tue, Aug 24, 2010 at 2:53 AM, Felix Schumacher wrote: >> On Mon, 23 Aug 2010 15:38:16 -0400, Scott Battaglia >> wrote: >> > I've never seen that behavior before and it shouldn't be happening >> (we >> > rely on the service url passed in and essentially send it back >> unmodified >> > except for the appending of the ticket). >> > >> > If you turn up DEBUG logging in CAS for CAS itself and potentially >> Web >> > Flow, does it give any more insights? >> I have turned up logging to DEBUG for org.springframework.webflow, >> org.jasig and (very probably overkill) org.jasig.cas.web.flow. Attached >> is >> the debugging output when trying to log into app1. Every reference to >> that >> app is logged with http://portal. [5]../app1/. Still the end result is >> me >> visiting https://portal. [6]../app1/. >> >> The logs are generated with a slightly modified login-webflow.xml. That >> was done to work around the bug with post redirect views. Alas changing >> the >> webflow to the original 3.4.2 configuration didn't change the outcome. >> >> In the logs are references to realserver. That is the name of the >> server >> on which app1 is located. The setup for the whole environment is as >> follows: >> >> loadbalancer (name portal...) >> | >> ___httpd____ >> / >> tomcat1 tomcat2 (name realserver) >> | | >> cas-server app1 >> >> Anything else I could try? >> >> Bye >> Felix >> > >> > On Mon, Aug 23, 2010 at 4:54 AM, Felix Schumacher wrote: >> > Hi, >> > >> > if the cas server and an application are on the same server (well >> > domain >> > name), the login sequence seems to update the protocol of the >> > application >> > to https. >> > >> > I am using version 3.4.2 (will update to 3.4.2.1 soon). The cas >> server >> > is >> > placed under https://portal-integration [7]. [2].../cas-server. >> > >> > If I call app1 - which is configured to be on the same domain name >> - >> > like >> > http://portal-integration [8]. [3].../app1/, the browser will get >> > redirected >> > correctly to >> > https://portal-integration [9]. >> > [4].../cas-server/login?service=http%3A%2F%2Fportal-integration... >> > The cas-server now redirects it back to >> > *https*://portal-integration..../app1/. >> > >> > This is not what I want. >> > >> > If on the other hand I try an application with a different domain >> name >> > like http://otherserver [10]. [5]..:8080/app2/ the following >> redirects take >> > the >> > browser correctly to *http*://otherserver...:8080/app2/. >> > >> > I have attached those two cases as a slightly shortened firefox >> > live-header protocol. >> > >> > Is this a known bug, or a wanted feature? >> > >> > Bye >> > Felix >> > -- >> > You are currently subscribed to [email protected] [11] [6] >> as: >> > [email protected] [12] [7] >> > To unsubscribe, change settings or access archives, see >> > http://www.ja-sig.org/wiki/display/JSG/cas-user [13] [8] >> >> -- >> You are currently subscribed to [email protected] [14] as: >> [email protected] [15] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user [16] -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
