[Zope-dev] Re: [ZODB-Dev] Re: BTrees strangeness (was Zope 2.X BIG Session problems - blocker - our site dies - need help of experience Zope developer, please)

[Chris McDonough]

On Tue, 2004-05-18 at 13:11, Steve Jibson wrote:
> Well, after much log reading, I have found that the KeyError we got last 
> night was OUR fault.

Thanks for reporting this, it's reasurring.  I was fixing to go insane.
;-)

> I will fix the problem with our app, then I want to change back to 
> TemporaryStorage and watch the system some more.  I'll keep you posted.

Great, thanks.

> Here's the brief explanation of our problem (you can skip it if you like):
> 
> A user logged in and did some stuff then left his browser for almost an 
> hour.  When he returned and tried to do more stuff, he was no longer in 
> the ExUserFolder's credential cache and his session had expired.  He was 
> forced to log in again.  Upon supplying his ID and password, he was sent 
> to the "loginSuccess" page.  This is the one that calls our method to 
> set up his user session.  The Z2.log shows a 302 result code on this 
> page.

Ooh, that's bad.  I guess that means that your users might not be
logging in as whom they think they're logging in as...  CookieCrumbler
handles this by injecting Pragma: No-Cache and the HTTP/1.1 equivalent
into the header (currently on *every* request, not so great actually).

> His browser had the "loginSuccess" page in cache, so it did not 
> request it again and his session was never re-created.
> 
> Score one for Chris's suggestion on how we should be setting up the 
> user's session.  For now, however, I think I'll just add the 
> please-don't-cache-me header stuff to the RESPONSE.

Right... although caching+auth is kind of tricky.   I wouldn't be
surprised if you found other places where caching is defeating some
other intentions you had.  If the site is meant to be accessed only by
authenticated users, I'd be tempted to arrange for the no-cache headers
to be injected by the main template itself.

I don't understand your setup 100%, although it sounds interesting.  By
your description of it sounds like you're implementing a bit of your own
security machinery (a user can either be an "admin" or a normal user,
depending on some setting he chooses at login time, even though it's
physically only one account).  But maybe an alternate way to implement
the machinery to do this is to do the following:

- Associate "member data" with each user.  This is built in to
  CMF, or you can roll your own if you're not using CMF
  (maybe by manually using a
  Transient Object Container in a FileStorage with the timeout set
  to 0... it basically then just becomes a big dictionary).
  Store user "preferences" there.  Give each user a default
  set of preferences for first-time login.

- Allow the user to log in with just a username and password
  (don't require him to enter his profile data on each login).

- In the session "add notify" script, copy his prefs into his
  session.  Your existing code will then work normally.

- In the session "delete notify" script, copy the prefs data
  in the session back into the member data.

Just an idea... 

- C