Newbie to CAS : URL encoding and pattern registry ?

[Marvin Addison]

>
> If the "service" param in the initial request to login is URL encoded,
> the example service definition[2] obviously won't match.
>

Short answer: I don't believe there would be a problem since IIRC URL
decoding is an implicit part of the servlet request processing pipeline.

Long answer follows.

Registered services commonly contain a scheme, host, and path and nothing
more like the following:

https://rp.example.com/path.*

A CAS protocol request for that service might look like the following:

https://idp.example.com/idp/profile/cas/login?service=https://rp.example.com/path/start

That is a valid URL since '/' and ':' are legal query string characters per
RFC 3986 [1]. However, since the CAS client component is responsible for
constructing the URL above, you're at the whim of the client. Some clients
encode the '/' and ':' characters, others do not; it's about 50:50 in my
experience. If the service URL contained a query delimiter, '?', it would
have to be encoded, but that's usually ignored anyway due to the wildcard
".*" at the end of the registered service regex.


> Should there be a service definition which URL decodes first before
> matching ?
>

Good question. I _thought_ that URL decoding was a built-in facility of
most servlet containers. In that view, even if the client sends a request
line like

/idp/profile/cas/login?service=https%3A%2F%2Frp.example.com%2Fpath%2Fstart

by the time HttpServletRequest#getParameter("service") is called, you ought
to get the decoded URL. I believe I verified that recently. Are you seeing
something different in your testing?

M <dev-unsubscribe at shibboleth.net>

[1] http://tools.ietf.org/html/rfc3986#appendix-A
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20150123/148d38e6/attachment.html