If you've got a custom web flow, please make sure you're not falling prey to having accidentally copied in a bad example.
We had a but similar to this that I thought we fixed: https://issues.jasig.org/browse/CAS-868 On Wed, Feb 9, 2011 at 5:51 PM, Bryan Wooten <[email protected]> wrote: > Using firebug I see very different behavior depending on the CAS server. > > > > Old CAS Login URL > > > https://oldCAS.utah.edu/cas/login?method=POST&service=https://trial.acs.utah.edu/psp/plconv/EMPLOYEE/EMPL/h/?tab=DEFAULT > > > > Enter user/password and firebug shows this as the first event: > > > > Post 302 > > > > > https://trial.acs.utah.edu/psp/plconv/EMPLOYEE/EMPL/h/?tab=DEFAULT&ticket=ST-1845016-x3J4PMohA94auVGXrqDw-localhost > > > > New CAS Login URL: > > > https://newCAS.utah.edu/cas/login?method=POST&service=https://trial.acs.utah.edu/psp/plconv/EMPLOYEE/EMPL/h/?tab=DEFAULT > > > > Enter user/password and firebug shows this as the first event: > > > > Post 302 > > > > > https://dev.usecure.utah.edu/cas/login;jsessionid=c8b4144164a17ceb362bf5b2c0d1?method=POST&service=https://trial.acs.utah.edu/psp/plconv/EMPLOYEE/EMPL/h/?tab=DEFAULT&_eventId=submit<=e1s1&password=xxxxxxl&submit=LOGIN&username=u0519980 > > > > Followed by: > > > > Post 302 > > > > https://trial.acs.utah.edu/psp/plconv/EMPLOYEE/EMPL/h/?tab=DEFAULT > > > > > > This is strange. > > > > *From:* Scott Battaglia [mailto:[email protected]] > *Sent:* Wednesday, February 09, 2011 12:33 PM > *To:* [email protected] > *Subject:* Re: [cas-user] Can someone explain this? > > > > If you're using PeopleSoft you'd have to inspect the HTTP post, since the > ticket MUST be passed via POST. > > You might be able to use FireBug to see those values? > > On Wed, Feb 9, 2011 at 2:29 PM, Bryan Wooten <[email protected]> > wrote: > > I am getting desperate, if I can't resolve this issue my whole CAS project > could fail. We have 2 products that must be CASified (Kronos and > PeopleSoft). > > > > Anyway we have 2 CAS servers (old CAS version 3.2? and new CAS version > 3.4.5). > > > > I have a simple test application that works against both CAS servers, it > prints out the CAS ticket. > > > > Then I have PeopleSoft that only works against old CAS, it can print the > ticket. When run against new CAS there is no ticket to print, there is no > request parameter "ticket". > > > > No matter where I run my new CAS server the above results always hold true. > I've tried both Tomcat and Glassfish V3 on various physical servers. All > certificates are valid. > > > > The test app and PeopleSoft are both behind the same proxy. When I monitor > the proxy log I see the ticket in the URL for test application. When I run > PeopleSoft against either CAS server I never see the ticket in the URL, yet > everything works against the old CAS. > > > > For the life of me I cannot figure out where the ticket is getting dropped. > The new CAS log file looks the same for both the test app and PeopleSoft. > > > > Does anyone have any ideas what else I can do to diagnose this problem? > > > > Cheers, > > > > Bryan > > -- > 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
