On Wed, 25 Aug 2010 12:22:22 +0200, Felix Schumacher <[email protected]> wrote: > 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. Ok, that behaviour is a result of our loadbalancer -> httpd -> tomcat chain. I looked at an ajp capture and there I see a redirect to http://portal... as I wanted. Now I will have to look at the other components. Thanks for your input. Felix > > 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
