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
smime.p7s
Description: S/MIME cryptographic signature
