Let me explain the background for this request. The CAS protocol uses the service= string for two purposes. Architecturally it is supposed to identify the application (or set of resources) that are protected by a Service Ticket. Practically it is also the URL to which CAS redirects the browser back after logon.
In most cases it isn't important to make the distinction, because in most cases CAS doesn't really need to know what scope of URLs are being protected and the application or CAS filter issues its own cookie/sessionid that represents the local logon to the applications. So if I try to access http://server/stuff/hostess/twinkie.jpg and there is a CAS filter on the context, the fact that I am really logging into http://server/stuff (the entire context) and that the rest of the service URL is simply the first resource I accessed is not a problem. It becomes a problem, however, if any internal complexity or additional application behavior or other Servlet filters or the container itself are going to modify the URL after the redirect. The most common example is adding JSESSIONID= on the end of the return URL. The filter or application then takes "its URL from the request object" and sends it as the service= on the CAS /validate or /serviceValidate and CAS normally compares the service= it got when it issued the Service Ticket to the service= it gets with the validate request and rejects them if they are not exactly the same (expect for special case logic checking for JSESSIONID added on the end of the second one). Once you accept the need to do this for one parameter added by one type of container, you should solve the general problem. One approach is to just declare a global rule. The Service is only significant down to the context name, or the service is only significant down to the query string (since most URL fiddling occurs by adding variables on the end of the query string). It seems unlikely that an Application to which you are logging on would be identified by a particular set of variable name value pairs in the query string. Scott's proposal of a regular expression generalizes the current logic which has special handling of JSESSIONID but nothing else. Obviously an expression could choose "the context", or "the URL path", or "everything up to the ?" or "everything except a trialing JSESSIONID=". The "correct" fix would be to change the protocol and distinguish the true service URL fragment from the "redirect to this resource" URL, but we have gotten along find for so many years without making this distinction that it is clear we don't absolutely have to fix the ambiguity. We just need a tweak that will allow us to make add CAS to the next oddly behaving application or container. -----Original Message----- In the past we've had people request that CAS modify its matching behaviors for service ids (i.e. to not include the query string or not include the personally identifying item). I'm evaluating the best way to do this in CAS4. One way to use Regular Expression patterns. Find the part of the service id that matches the pattern and extract it and then call equals on both of the pattern-extracted ids. _______________________________________________ cas-dev mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas-dev
