validating service uri

[Scott Battaglia]

http://www.example.com and http://www.example.com?foo=bar are two different
service urls and will not match on ticket validation.  The only thing
removed from a service url is a jsessionid.

Applications that use Acegi get around this by storing the actual url in a
session variable and always sending the same service url to CAS.

-scott

On 3/14/07, Matt Zukowski <mzukowski at urbacon.net> wrote:
>
> This isn't especially clear in the protocol spec, so I'm hoping someone
> here can answer this question:
>
> Should query parameters in the URI be ignored when checking the
> 'service' parameter for validity?
>
> In other words, if I have a service ticket for service
> http://www.example.com, should that service ticket also be valid for
> http://www.example.com?foo=bar
>
> In some of our applications, http://www.example.com and
> http://www.example.com?foo=bar point to exactly the same service, but
> due to the way the client is redirecting things, sometimes users get
> sent to http://www.example.com and sometimes to
> http://www.example.com?foo=bar.... I'm wondering whether this is a
> problem that should be corrected in our CAS client, or whether it's okay
> to allow our CAS server to ignore the query part of the URI.
>
>
> This e-mail message is privileged, confidential and subject to copyright.
> Any unauthorized use or disclosure is prohibited.
> Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis
> `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer
> sans autorisation.
>
>
> _______________________________________________
> Yale CAS mailing list
> cas at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas
>



-- 
-Scott Battaglia

LinkedIn: http://www.linkedin.com/in/scottbattaglia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20070314/782e86a4/attachment.html