I have been trying to use the CAS Java client 3.0 (from the JA-SIG Maven2 repository) with a CAS 2 server. In my securityConfiguration.xml file I have set a serverName property for the TicketValidationFilter and AuthenticationFilter beans. As I understand it these filters will construct the appropriate serviceurl from the servicename which will then be passed to the CAS server. I then experienced the:
ticket 'ST-XXX' does not match supplied service problem that I subsequently read about on this list. It appears to be happening because a jsessionid is being appended (and encoded) in my serviceurl created by the filters. If I understand it correctly, Scott B. has previously written that older versions of the CAS server do not properly parse out the jsessionid and this is fixed in more recent CAS 3 server versions. I'm using a production CAS 2 server that is not yet scheduled for upgrade. It looks to me like this issue could be fixed from the client side. My workaround was to make copies of AbstractCasFilter, TicketValidationFilter and AuthenticationFilter. I then high jacked the "stripJsessionFromUrl" method from the CAS server WebUtils class and added it into AbstractCasFilter. Now AbstractCasFilter's "constructServiceUrl" method ends with "return stripJsessionFromUrl(returnValue);". The jsessionid is no longer appearing in the serviceurl and everything seems to be working as I would expect. Am I missing something or would this be a sensible modification to make to the real CAS 3 client code? I would expect that backwards compatibility with CAS 2 servers is a desirable feature for the CAS 3 client. -- "Paradoxically, the more time saving abstractions you are using the more you actually have to know." - Simon Willison _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
