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 <[EMAIL PROTECTED]> 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 [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
-- -Scott Battaglia LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
