Thank you that was the problem and it validated the ticket correctly just as in test 2. This makes me think our cluster should be working. Right now our load balancer address (https://loadbalancer.domain/cas/) only has one server active because of the failures we have been getting. Our load balancer administrator is unavailable until Monday so I can't do much testing until then. I will do more testing once I can do more with the load balancer. Is there anyway I can get more details as to how you (Scott & Marvin) have setup your clusters? Thank you very much for your help.
On Fri, Sep 25, 2009 at 8:48 AM, Scott Battaglia <[email protected]>wrote: > There is not supposed to be a "/" after serviceValidate You might want to > try again without it being "serviceValidate/" > > Cheers, > Scott > > > On Fri, Sep 25, 2009 at 10:45 AM, Ryan Andreasen <[email protected] > > wrote: > >> Here are two tests that I just performed (I had to go straight against the >> servers server1.domain & server2.domain instead of against >> loadbalanced.domain since we have sticky sessions). >> >> Test 1: >> >> 1) Go to >> https://server1.domain/cas/login/?service=http://server.domain/staticHtml(where >> staticHtml is just a regular page that I can get the ST from) >> 2) Login, get redirected to staticHtml, get the ST from the query string >> 3) Go to >> https://server2.domain/cas/serviceValidate/?service=http://server.domain/staticHtml&ticket=ST-FromTheQueryString >> 4) This results in getting redirected to >> https://server2.domain/cas/login/?service=http://server.domain/staticHtml&ticket=ST-FromTheQueryString >> >> In the browser, it is like server2 wants me to login even though I went to >> serviceValidate >> >> Test 2: >> >> 1) Go to >> https://server1.domain/cas/login/?service=http://server.domain/staticHtml(where >> staticHtml is just a regular page that I can get the ST from) >> 2) Login, get redirected to staticHtml, get the ST from the query string >> 3) Using a test ASP.NET web application and the DotNetCasClient >> programmatically validate the ST retrieved in step 2. This works and I get >> the username back. >> >> So what is the difference and why are we seeing this behavior. Apparently >> I was mistaken about getting an unrecognized ticket error, but I swear I >> have gotten them before. Our cluster configuration just seems shaky right >> now. The reason I feel I need session replication is because of the >> documentation here: >> http://www.ja-sig.org/wiki/display/CASUM/Clustering+CAS (which appears to >> have been last modified by yourself Marvin, so I appreciate being able to >> get help directly from you) >> >> Thanks for your help on this issue. I really would like to understand the >> best way to get our servers clustered. >> >> >> >> On Thu, Sep 24, 2009 at 6:56 PM, Marvin Addison <[email protected] >> > wrote: >> >>> > if you get a ST from server A and try to >>> > validate it on server B it returns "unrecognized ticket". >>> >>> Would you mind posting the relevant excerpt from the stack trace that >>> results from either of your test scenarios? I have a hunch about the >>> cause of your problem, but can't be certain without further >>> information. >>> >>> We have never seen any errors of this sort in months of testing our >>> active-active setup that makes no provisions for either session >>> replication or sessionless Web Flow. Since the ticket request and >>> validation steps have different sources, one would expect a 50% error >>> rate in our case of a 2-node cluster if there were a fundamental >>> requirement that Web Flow state be shared among nodes. Our experience >>> suggests there is no such requirement. >>> >>> M >>> >>> -- >>> 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 >>> >> >> -- >> 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 >> >> > -- > 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 > > -- 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
