Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Legacy code

This release is superceded by a more recent release.

Getting the files

The files in this release are attached to this Wiki page.

Release notes

These release notes describe how this release differs from Yale CAS Server 2.0.6. The version numbers 2.0.7, 2.0.8, and 2.0.9 were unused – the project jumped from 2.0.6 to 2.0.10.

CAS 2.0.10 (June 2003): product maturation

  • Generally improved packaging, documentation, and installation instructions.
  • Improved the security of "renew=true"; applications may now specify this flag during ticket validation to ensure that a ticket was acquired by a request that set this flag on the login page. This lets an application be surer that a user truly reauthenticated with primary credentials. (Thanks to Mads Freek Petersen from Roskilde University in Denmark for reporting this problem.)
  • The "warn me before logging into other services" feature is now properly shut off upon a second login to CAS during which the user doesn't check the box; the cookie was formerly inappropriately "sticky." (Thanks to Andrew Draskoy from Memorial University in Newfoundland for reporting this problem.)
  • The servlets no longer call Cookie.setDomain() when the goal is to send the ticket back only to the CAS server; this is the default, is more clearly correct and portable, and is conceivably more restrictive too. (No apparent security-related vulnerability is associated with the former call to Cookie.setDomain(request.getServerName()) because, while getServerName() does indeed use the HTTP "Host" header – which led to a client-side problem fixed in version 2.0.2 of the client distribution – an attacker should have no way to coerce a browser to send a malformed or hijacked "Host" header, which would be necessary to exploit getServerName()'s dependency on "Host" in this case.)
  • The "logout" servlet now sets the "TGC overwrite" cookie's path explicitly and marks it "secure." This has no effect on security since the CAS server destroys all records of the session anyway, but if we're going to try to delete the cookie, we may as well do so in a manner that will work with as many browsers as possible. (Thanks to Trenton Adams at Athabasca University.)
  • No labels