Warning: Can't synchronize with repository "(default)" (Unsupported version control system "svn": No module named svn). Look in the Trac log for more information.

Ticket #1729 (closed defect: fixed)

Opened 11 years ago

Last modified 11 years ago

Problems with visit cookie expiration header

Reported by: chrisz Owned by: anonymous
Priority: normal Milestone:
Component: TurboGears Version:
Severity: normal Keywords: visit session expires timeout


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.

Change History

comment:1 Changed 11 years ago by faide

  • Milestone changed from 1.0.x bugfix to

comment:2 Changed 11 years ago by chrisz

  • Status changed from new to closed
  • Resolution set to fixed

This has now been fixed in TurboGears r4203, and  CherryPy ticket 794 suggests the same fix for CherryPy?'s sessions.

comment:3 Changed 11 years ago by chrisz

After some experiments with MSIE 7 it seems that treating cookies with Max-Age as not permanent is really a bug and not a security feature. A cookie should be permanent if either Expires or Max-Age is set. It even seems that the attribute is ignored completely by MSIE 7, though it is clearly specified in RFC 2109/2965.

However you can set both Max-Age and Expires, and then Max-Age takes precedence in good-behaving browsers. This is better because it works when server and client clocks or timezones are out of sync.

So I implemented a better fix in r4205 by introducing a new setting visit.cookie.permanent which is False by default and controls whether Expires and Max-Age are set or not.

comment:4 Changed 11 years ago by faide

Well it seems that each time I look at my email I have a good surprise :) So let's rock a release tonight then!

Note: See TracTickets for help on using tickets.