Something to take into consideration with this issue is that a space character is not a valid character in a url, so should already be encoded once when a client is retrieving it's url. Then when that url is passed as a parameter to CAS through login redirection, or ticket validation, it should be encoded a second time since it is a parameter on the CAS url (also avoids issues of having an & in the service url). This means that for most scenarios the CAS server will never have to deal with the varying encodings of a space character.
The only time this would vary is when a client is using something other than a valid url for the service parameter or they are not encoding the url for the service parameter. -Daniel On Dec 31, 2012, at 2:10 PM, Scott Battaglia <[email protected]<mailto:[email protected]>> wrote: I think I'm sitting on the same fence you are :-) As mentioned previously, I wouldn't stop making the server "safe" for both, but I'm not a fan of it. Regardless of what happens to the server, I think we should do (b) by updating the protocol with our recommendation (which I would assume is the RFC, but I'm fine with just choosing either one) and update the official clients to all use the same method. On Mon, Dec 31, 2012 at 2:05 PM, William G. Thompson, Jr. <[email protected]<mailto:[email protected]>> wrote: I'm a bit on the fence on this one. '+' is clearly meant for html forms, where the form data is encoded using the application/x-www-form-urlencoded content type for GETs or POSTs. '%20' is for spaces in URIs generally, being an "unsafe" character. In any case, the URLs in questions ("CAS enabled services") are passed as URL parameters and are constructed by the various CAS client libraries or as static login links. If one where to assume (or specify) application/x-www-form-urlencoded then '+' would be expected (even though no html form per se is to be found). If the login link were for some reason dynamic via an html form then '+' would be sent by the browser user-agent. Currently the CAS protocol doesn't specify an http verb, although GET is assumed by the clients. In retrospect, the end points requesting/validation proxy tickets should have probably been POST (given their non-idempotent behavior) which would have meant application/x-www-form-urlencoded parameters and '+' for spaces. On the other hand '%20' or '+' are both space when interpreting singled encoded URLs and as such logically should be the same. This is the path our client decided to go and patched their local CAS server. As Andrew mentions, this approach also nicely removes this as an issue for other potential clients and integrators. So...looking for some consensus on: a) patch CAS server to treat '%20' and '+' the same when matching validating service to ST/PT issued service. or b) specifying expected encoding and deal with the fall out of cases that won't/can't comply. Best, Bill On Mon, Dec 31, 2012 at 1:45 PM, Andrew Petro <[email protected]<mailto:[email protected]>> wrote: > Not all URLs to request CAS tickets are generated by CAS client libraries -- > some are embedded as static URLs in UIs. So I think the question of what the > behavior should be of the CAS server in evaluating the equivalence of > space-representation-containing service parameter values goes beyond getting > all known CAS client libraries to make the same choice in representing > spaces. Future CAS client libraries may be developed that trip over this > issue such that making the CAS server accept both representations > interchangeably is a more complete and long-term solution than is getting > this right currently in all now prevalent CAS libraries. > > Simplicity of CAS server implementation is a laudable goal. But easing CAS > integrations is more laudable. Both + and %20 are legitimate ways to encode > a space. We can make CAS friendlier to integrate with at no cost to > security by accepting both space representations interchangeably in the > values for the service parameter. We should do this. > > No CAS integrator is going to say "Darn! I really wish that CAS server > hadn't treated my %20 and + representations of space characters in my > service URLs as equivalent!" However, CAS adopters of now-existing versions > of client libraries with this mismatch or who lovingly hand-code a CAS login > URL into a UI might well utter some curses after untangling an issue that > turned out to be a mismatch on how the same conceptual space character was > encoded in two different ways. > > I think easing the lives of the integrators in supporting the equivalence of > different representations of a space justifies the complexity of normalizing > the presented service parameter in the CAS server before comparing it. > > Andrew > > > > On Mon, Dec 31, 2012 at 12:44 PM, Scott Battaglia > <[email protected]<mailto:[email protected]>> wrote: >> >> I'm not sure we should be doing more manipulation for comparison purposes >> if there's an appropriate encoding that should be done. It seems like most >> other languages (I looked at PHP and .NET recommend encoding that actually >> processes everything properly (i.e. the RFC that Bill mentioned). Java is >> the only one with their misnamed class that uses "+" instead. We can easily >> rectify that by updating our Java client code). >> >> >> >> >> >> On Mon, Dec 31, 2012 at 12:26 PM, Andrew Petro >> <[email protected]<mailto:[email protected]>> wrote: >>> >>> > Should the CAS server should accepted either form and treat them as a >>> > match? >>> >>> Yes. The intent of the service parameter matching feature comparing >>> ticket issuance with ticket redemption is to prevent illicit delegation, >>> that is, use of a ticket other than for its intended purpose. It allows >>> applications relying upon CAS to verify that the ticket they are validating >>> authenticates to the service they think it authenticates to. >>> >>> It looks like the validating application can legitimately express spaces >>> as %20 or as +; the CAS server shouldn't require the validating application >>> to guess which way the spaces were encoded when the ticket was requested. >>> >>> So, yes, I think opening a JIRA issue in CAS server for this lovely >>> enhancement is a good idea and that treating %20 and + as equivalent in >>> service parameter matching will make CAS friendlier for integrations with no >>> loss to the intention-validating advantages of server-side service parameter >>> matching. >>> >>> >>> >>> >>> On Mon, Dec 31, 2012 at 11:57 AM, William G. Thompson, Jr. >>> <[email protected]<mailto:[email protected]>> wrote: >>>> >>>> Folks, >>>> >>>> Unicon is currently working with a client implementing an extensive >>>> RESTful-based architecture leveraging Proxy Tickets. We've stumbled >>>> on the following issue where Proxy Ticket validation is failing due to >>>> mismatch in how Java CAS Client and .NET CAS Client are encode spaces >>>> in URLs ('+' vs '%20'). >>>> >>>> URLs that include paramters with spaces like 'paramWithSpace=some >>>> value' are getting encoded to 'some+value' by the Java CAS client when >>>> requesting a PT and like 'some%20value' by the .NET CAS client on the >>>> validation call. This results in a "does not match supplied service" >>>> validation error. >>>> >>>> Seems like '+' or '%20' are both valid for space in a URL. >>>> >>>> http://www.ietf.org/rfc/rfc1738.txt says spaces should be encoded >>>> (presumably %20). >>>> >>>> http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1 says >>>> spaces are replaced by '+' when form action is GET. >>>> >>>> Also see: >>>> >>>> http://stackoverflow.com/questions/1634271/url-encoding-the-space-character-or-20 >>>> http://bugs.python.org/issue13866 >>>> >>>> http://stackoverflow.com/questions/5366007/why-does-the-encodings-of-a-url-and-the-query-string-part-differ/5433216#5433216 >>>> >>>> Should the CAS server should accepted either form and treat them as a >>>> match? Open a JIRA issue against CAS Server? >>>> >>>> Best, >>>> Bill >>>> >>>> -- >>>> 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-dev >>> >>> >>> -- >>> 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-dev >> >> >> -- >> 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-dev > > > -- > 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-dev -- 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-dev -- 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-dev -- 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-dev
