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]> 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]> 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
--
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
