Yep newCas == usecure, I am supposed to clean up urls. I failed. The CAS login in form is identical between newCAS and oldCAS.
Yes it is the same PS. I adjust ticket validation between tests. The weird thing is that because newCAS doesn't send the ticket it never gets to the validation phase. "As for the apparently missing ticket, what if the newer CAS sends it in the HTTP POST message rather than as the request parameter?" That is interesting. I wonder how I could capture that in PS Funclib peoplecode? That may be the answer. As you probably know the interaction between a PS PIA Weblogic and an appserver peoplecode Funclib is, how can I put this, a mystery? But the question remains, what is so different between my CAS servers? Thanks, Bryan ________________________________________ From: Adam Rybicki [[email protected]] Sent: Wednesday, February 09, 2011 6:03 PM To: [email protected] Subject: Re: [cas-user] Can someone explain this? Bryan, In your last posting, should I assume that newCAS.utah.edu is equivalent to dev.usecure.utah.edu? Otherwise, this could be an issue. I have never seen CAS submit login credentials as the request parameters. Is your CAS login form modified to have method=GET?" The purpose of POST is to put the form fields in the payload of the message and not in the request. I don't work with Firebug, as I find Live HTTP Headers sufficient for what I do. The form fields ending up as CAS URL parameters in the example you gave may be purely an artifact of Firebug, though it would be misleading. As for the apparently missing ticket, what if the newer CAS sends it in the HTTP POST message rather than as the request parameter? Most significantly, though, it looks like in both tests you are using the same instance of PS. You didn't say whether you have reconfigured PS to validate its ticket against the new CAS in the second test. Just a list of random thoughts. Adam On 2/9/2011 14:51, Bryan Wooten 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]<mailto:[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]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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]<mailto:[email protected]> as: [email protected]<mailto:[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
