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] > 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]> 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]> 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] as: >>> [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 >> >> > -- > 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 > > -- 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
