Some people reported on the mailing list problems in recent TG versions which could be tracked down to changeset r3443 where an "expires" header was added to identity cookies.
The idea of that changeset, requested in ticket #1406, was to allow logging in, even after the browser has been closed for a certain period of time (visit.timeout), and not loosing the CherryPy? session, which does the same trick in the sessionfilter.
However, this change has some drawbacks:
- On most browsers such cookies will not be regarded as session cookies, but as permanent cookies because of the expires header, and therefore can be disallowed completely (depending on the configured security level/realm).
- It's indeed a security risk. If you close your browser (in good faith that you closed the current session), but leave the PC switched on, anybody can reactivate your session within the session timeout, without logging in.
- You get problems when the clocks on the server and client are not in sync or when time zones are not set up and computed correctly.
Maybe some or all of these problems could be solved by using "Max-Age" instead of "Expires", because MSIE and Safari seem to treat such cookies as not permanent. (CherryPy? uses "Expires" instead of "Max-Age" because this behavior was considered as an IE bug, but it seems to be more of an intended security feature).
So, changeset r3443 should be reverted, or it should be made configurable whether "Expires", "Max-Age", both or none (=default) should be set for the visit cookie.
Plus, the CherryPy? people should be convinced to do the same with their sessionfilter to harmonize the behavior of TG visits and CherryPy? sessions.
