> On Sat, Oct 27, 2001 at 05:48:54PM -0700, Quinn Dunkan wrote: > > I have a few questions about sessions. It looks like if I want sessions to > > time out, I should override SessionManager.set_session_cookie to include an > > expires attribute in the cookie, and then run > > > > for s in get_session().values(): > > if s.get_access_age() > timeout: > > del get_session()[s.id] > > > > in the _q_access method of the root object. Is this the right way to do it > ? > > I wouldn't do it that way. The loop would be run on every hit. > Instead, I would subclass the session manager and override the new > session method to expire sessions if there are lots of them. > > We have cron job that deletes sessions. You need to have a DB that > allows concurrent access for this approach to work (we use ZODB with > ZEO0. My "DB" is simply a directory of pickles, but the "application state" is also the state of various system files (mailboxes). It's important that session be expired in a certain amount of time. If someone forgets to log off, I'd like the system to log them off after a well-defined period of time. True, the browser should have expired the cookie by then, but I feel better not placing my trust entirely in the browser for that. My (limited) understanding is that if the system only expired sessions when there were, say, 256 of them, then someone on a public machine using a faulty browser that doesn't expire cookies properly could forget to log off and leave their session open for anyone who happens to wander in until the "session garbage collector" triggers, which could be days. If I didn't store the user name in the url (which is another possibly unusual thing about my approach: the namespace looks like Root_object.username.user_subobjects where Root_object uses _q_getname to map usernames to logged in user objects) then the next person would *accidentally* log into someone else's account. As it is, they could use the back button, but at least it's harder to do accidentally. Ultimately you can't protect people who forget to log out from themselves, but since the web is supposed to be stateless, I expect plenty will forget. > > The other question is about session persistence. It looks like the way to > > implement persistent sessions is to override Session.commit to dump a pickl > e > > or something. I'd like to avoid having to touch the disk after every http > > request (that's what FCGI is for, right?), so it doesn't seem to be quite w > hat > > I want. > > We commit on every hit since our session data is important. You could > make Session.commit only do a commit if a certain amount of time has > passed since the last commit. > > > So anyway, persistence is handled entirely by the user object, and Session > has > > nothing to do with it at all. Once again, is this the right way to do thin > gs? > > Or am I solving the problem in the wrong place? > > I don't think I know enough about your application to comment on that. > Your approach sounds slightly odd to me. If you haven't already I would > suggest looking at ZODB. It handles caching automatically for you. I should have been clearer about the application---it's a web mail thing. My personal opinion is that http is for web documents and IMAP and POP are for email, but http is what They want and none of the existing programs out there did what They wanted. Anyway, since I'm also forced to use the inefficient unix mailbox format (have to get along with pine, you know) parsing a large mailbox looking for message 500 and reorganizing messages is expensive. The cache is a cache of message number -> file offsets. Actually, it's a bunch of generic message objects that can return their contents (possibly lazily), since some might be from IMAP boxes, some might be from POP boxes, and some might be from local files. Since the "session state" consists of how the user has manipulated their mailboxes since they were read from disk, committing the session means potentially a lot of disk I/O, and it only makes sense to do it at the end of a session because that's the only time I can unlock their mailboxes.