[Twisted-web] Session class

Maarten ter Huurne maarten at treewalker.org
Fri Oct 3 07:01:06 EDT 2008

On Wednesday 01 October 2008, glyph at divmod.com wrote:
> On 11:31 am, maarten at treewalker.org wrote:
> >None of this is a critical problem, but it does feel a bit strange. Is
> >the
> >current design motivated by something I haven't understood yet, or is
> >it
> >something that works well enough in typical use even though it has some
> >unexpected special cases?
> Most likely the latter.  twisted.web.server.Session was designed years
> and years ago, before anyone involved in Twisted really had any idea how
> the web worked.  It turns out that it works okay for a lot of cases, but
> it could definitely be a lot better.
> It sounds like you've got lots of very specific ideas for making it
> better.  I very much doubt that you're misunderstanding it; please
> search around the tracker at <http://twistedmatrix.com/trac/> and find
> existing tickets that describe some of these issues (there are bound to
> be a few) and feel free to file some new ones.  Patches (with tests, of
> course) would be very much appreciated.

I looked for tickets describing these issues, and while I found a few that 
describe related issues, I did not find any that describe the same issues. 
Therefore, I entered two new tickets about session expiry:

  Session expiry check frequency should be based on sessionTimeout

  Expired session can be revived

While writing the first ticket, I realized that I was mixing up session 
expiry and session cleanup. Expiry is when the session timeout occurs, 
while cleanup is when the session object is removed. The implementation 
also mixes up these concepts though: the callbacks registered with 
notifyOnExpire() are called on cleanup, not on expiry.

It might be possible to fix 3457 in such a way that 3458 would be fixed as 
well without extra effort: if expired sessions are immediately cleaned up, 
it is not possible for an expired session to be revived, since it is simply 
no longer around.

I also wrote a ticket about the UIDs generation:

  Session UID might be predictable

The most important question in this ticket is whether the session UID is 
indeed supposed to be unpredictable, or whether it is good enough if the 
UID is unique. Can someone please answer that?

And finally a ticket about session cookies and HTTPS:

  Use secure session cookie when connection is secure

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://twistedmatrix.com/pipermail/twisted-web/attachments/20081003/72b021c2/attachment.pgp

More information about the Twisted-web mailing list