As it's a fairly simple protocol, so the CAS client is my own code base. I am building a WSFederation bridge for ADFS that uses CAS for authentication. the "long urls" are basically federation passive redirects from other ADFS servers. For example I want to retain this query string and path
wa=wsignin1.0&wtrealm=https%3a%2f%2fcassts.ginsburg.local%2fCASAuth%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fCASAuth%252f&wct=2013-02-13T17%3a27%3a32Z So you would think I would simply append that to the query string parameter which would result in this (my cas server is cas.ginsburg.local and my federation proxy is cassts.ginburg.local) https://cas.ginsburg.local/cas/login?TARGET=https%3a%2f%2fcassts.ginsburg.local%2fcasauth_sts%2f%3fwa%3dwsignin1.0%26wtrealm%3dhttps%253a%252f%252fcassts.ginsburg.local%252fCASAuth%252f%26wctx%3drm%253d0%2526id%253dpassive%2526ru%253d%25252fCASAuth%25252f%26wct%3d2013-02-13T18%253a25%253a5 If I do that, then the CAS redirect sends me back with this , to the right place but with a mangled URL, notice that parts of the query string are repeated. "https://cassts.ginsburg.local/casauth_sts/?wa=wsignin1.0&wtrealm=https:%2f%2fcassts.ginsburg.local%2fCASAuth%2f&wctx=rm%3d0%26id%3dpassive%26ru%3d%252fCASAuth%252f&wct=2013-02-13T18:30:44Z&TARGET=https:%2F%2Fcassts.ginsburg.local%2Fcasauth_sts%2F%3Fwa%3Dwsignin1.0%26wtrealm%3Dhttps%253a%252f%252fcassts.ginsburg.local%252fCASAuth%252f%26wctx%3Drm%253d0%2526id%253dpassive%2526ru%253d%25252fCASAuth%25252f%26 This example only repeats once, I have seen it repeat up to 4 times (with different federation urls). For the moment what I have done is move the URL to a cookie before sending the request to CAS. That works fine but of course I have to refresh the URL after it comes back so it causes another round trip on my server. Robert Ginsburg rob...@ginsburg.me (803) 467 - 3329 -----Original Message----- From: Ohsie, David [mailto:david.oh...@emc.com] Sent: Wednesday, February 13, 2013 10:26 AM To: cas-user@lists.jasig.org Subject: RE: [cas-user] URL encoding and CAS Can you report which CAS client you are using and also post the URL that is in your browser address bar at the CAS login page or a log of the web server requests. "Long" or "complex" URL's should be working without a problem. david -----Original Message----- From: Robert Ginsburg [mailto:rob...@ginsburg.me] Sent: Wednesday, February 13, 2013 9:28 AM To: cas-user@lists.jasig.org Subject: RE: [cas-user] URL encoding and CAS I must admit to both being a CAS newbie but I have had a similar problem with CAS 3.51. I was unable to reliably get CAS to return complex URL's . By that I mean URLs that had fairly long accompanying URL encoded query strings. I ended up pushing the original URL in a client side cookie and restoring it on return. It does mean an extra redirect but the CAS service url is short and of course works fine. Robert Ginsburg rob...@ginsburg.me (803) 467 - 3329 -----Original Message----- From: Jeff Chapin [mailto:jeff.cha...@uni.edu] Sent: Friday, February 08, 2013 5:39 PM To: cas-user@lists.jasig.org Subject: [cas-user] URL encoding and CAS All, We have an enterprise reporting tool we have operating behind CAS. This service has URLs that have 'special' characters in it -- ampersands, slashes, question marks, spaces, etc. This service handles some URL encoding just fine -- it does not mind replacing ' ' with %20, for instance. When this application is placed behind CAS, however, CAS is modifying the URL -- it is URL encoding strangely. For instance, if I wanted to hit: https://example.com/analytics/saw.dll?dashboard&PortalPath=%2Fshared%2Deans% 2C%20Directors%2C%20Department%20Heads%2F_portal%2FAdmissions%20for%20DDDH CAS is properly authing the user, and then releasing them to: https://example.com/analytics/saw.dll?dashboard%26PortalPath%3d%252Fshared%2 52FDeans%252C%2520Directors%252C%2520Department%2520Heads%252F_portal%252FAd missions%2520for%2520DDDH If you look, it appears that CAS took the already URL encoded service URL, and encoded it again -- %20 becomes %2520 -- the encoding for '%' followed by the '20'. For some reason, CAS is smart enough to encode, but not decode on the way back out. Due to the nature of the service, it *has* spaces in the URLs generated, as well as question marks, ampersands, and slashes -- and who knows what else? It appears that the application is smart enough to decode %20 when it comes in, but not %2520, so these links break, and anytime you are prompted to log in through CAS, you get a 404 error. Subsequent connections (with an existing CAS session) work just fine, with no re-writing of the URLs. Does anyone know of a work around, a setting we can change, or even a section of code to look into in order to fix this behavior? Due to the nature of these reports, and their user base (Deans, Directors, and Department Heads) I am under a decent amount of added incentive to find a fix to this issue... Thanks, Jeff -- Jeff Chapin, Assistant Systems/Applications Administrator ITS-IS, University of Northern Iowa Phone: 319-273-3162 Email: jeff.cha...@uni.edu -- You are currently subscribed to cas-user@lists.jasig.org as: rob...@ginsburg.me To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: david.oh...@emc.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
