> 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
