The CAS3 client is backwards compatible with the CAS 1 and CAS 2 protocols, not with any specific server implementation. Therefore, its behavior is correct (it was in fact, incorrect to not encode that jsessionid into the URL to support people with cookies turned off).
If there's a significant demand from the CAS userbase to include a "compatibility" mode for older versions of the server code that do not correctly handle the session id, we could add it as a flag. -Scott On Nov 2, 2007 8:24 AM, Mark McLaren <[EMAIL PROTECTED]> wrote: > 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 > -- -Scott Battaglia LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
