[Zope-PAS] [RFC] Extending CookieAuthHelper

[Chris McDonough]

On Thu, 2004-11-11 at 14:20, Jens Vagelpohl wrote:
> > WRT sessions, it is a goal of mine for Zope 3 sessions that they be 
> > ubiquitous
> > and storable over ZEO. This means that we choose not to write to them 
> > very
> > often. :)  This alows us to *count* on them being there.
> 
> I believe sessions are one of these killer things that is underutilized 
> for various reasons. One possibly being the fact that they seem to 
> require a lot of mind-bending internal logic to do what they are 
> supposed to do (hello Chris ;), and sometimes reliability is a problem 
> due to the complicated internal logic.

Ah a topic that is near and dear to me. ;-)

TOtally inappropriate here but...

FWIW, the actual session logic isn't mindbending but the operation of it
is painful to test because a) its most crucial variable is time and b)
it depends heavily on ZODB and publisher behavior.  Testing
timing-dependent things comprehensively is hard and even harder in
multithreaded applications.  Its dependency on behaviors of other pieces
of software makes it even more difficult to test.

The lesson I learned here (that in retrospect is obvious) was that unit
tests don't cut it when testing how a piece of software with
dependencies on lots of other software.  Furthermore, when time is a big
factor in operation, you can't test manually.  You need to spend a lot
of time automating "stress test" software so you can just let it run and
find bugs caused by corner cases that don't show up until maybe a few
hours into a particular process lifetime.  This software must exercise
the outermost layer of the software (in this case, Zope's publisher)
because testing it any other way can give misleading results.

We were only able to find and fix the bugs when Michael Dunstan created
the "SessionRig" stress tester (on cvs.zope.org in Packages).  In the
end, we found a number of ZODB and publisher bugs that were causing data
inconsistencies, and with a lot of help from Tim, we got them fixed. 
I'd encourage anybody attempting to polish sessions in Zope 3 to use the
SessionRig test rig (or create their own) for "end-to-end" session
testing.

> The plugin I am thinking of only writes to the session once, on login, 
> and then compares the incoming session key to retrieve credentials from 
> the session. So it seems quite sessioning-friendly.

Note that a read to a session may imply a write.  This is how it works,
because sessions need to clean up after themselves somehow.  A scheduler
would solve this, and the Zope 2 sessioning stuff does allow you to turn
off this behavior and use an external scheduler, but its up to you to
supply that scheduler.

> >> Also, the lifespan of the cookie should be configurable on the plugin 
> >> and there should be a "logout" method that can be called from user 
> >> space/untrusted code to effect cookie expiration.
> >
> > You can't just use the session-timeout mechanism for that?
> > That certainly makes things simpler.
> 
> Yes, that's a good point and I have thought about it myself. There is 
> two items that need to be clened up, come to think of it. On the one 
> hand you have a session, but then there's also a cookie. I'm not sure 
> yet if I want to re-use the standard sessioning cookie or set my own. I 
> need to look at how the timeouts in these items are handled by the 
> standard sessioning machinery.

Session timeout is the way to go, AFAICT.  The cookie lifetime can
theoretically be forever.

- C