durusmail: quixote-users: new user, and session questions
new user, and session questions
2001-10-27
2001-10-29
2001-10-29
Non-reentrant functions in Quixote
2001-10-29
2001-10-29
2001-10-29
2001-10-29
new user, and session questions
Greg Ward
2001-10-29
On 29 October 2001, Quinn Dunkan said:
> 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 that directory of pickles is one pickle file per session, it sounds
like you've got it easy.  Write a script to walk the directory, looking
at each pickle (heck, you don't even have to load it: you could probably
just look at the mtime), and deleting "old" ones (for some definition of
old).  Run it periodically with cron, with a carefully chosen period.
Eg. if you say "sessions older than 1 hour will be expired" and you run
the script every 15 minutes, then a session could live to 1:14:59 before
being expired.

The problem with running every N hits, as Neil suggested, is that it
could be quite a while before N hits elapse.  This is true even if N ==
1; as N decreases, the load on your server increases and the probability
of sessions living on too long decreases.

Maybe you could keep a data structure in your session manager that
classifies sessions by age, so you don't have to be a big expensive loop
over all sessions every N hits.

Or, if you're not afraid of threads, you could run a session expiry
thread.  It would be just like that hypothetical cron job I mentioned,
but with all the pitfalls and advantages (?) of threading.  BTW, we make
*no* promises about the thread safety of Quixote!  Note in particular
that the quixote.get_*() functions are thread-ignorant.

> If someone forgets to log off, I'd like the system to log them off
> after a well-defined period of time.

I suspect someday Quixote's session management machinery should have
some sort of support for this.  Right now, I don't think the right
solution is obvious, so it's better to have a few different approaches
implemented in the wild, and see what works.

> 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.

Hey, another thing just occurred to me: you could expire sessions "on
demand".  Eg. user joe currently has a session open, and a request is
received with that session cookie, you take a look at the current time
and the time of the last request for that session.  If more than 1 hour
(or whatever), expire it.  That's not a complete solution, because
sessions that are genuinely walked away from (browser shut down, cookie
lost forever) will never be touched again.  But it means you could run
your cron-based session expirer less frequently, and not worry about the
window of time between "session theoretically should have expired" and
"session actually expired by cron job".

> 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.

Have you considered Maildir?  AFAIK even Pine works with it.  I see lots
of people on the Exim and ReiserFS mailing lists who are very happy with
Maildir on ReiserFS for POP/IMAP servers.  Maildir would unload a lot of
your job onto the filesystem, and ReiserFS is specifically designed to
take that kind of load.  (A regular Unix filesystem would probably work
just fine, unless you're talking tens of thousands of users with
thousands of messages each.)  It also means you don't have to be afraid
of writing changes to disk, because deleting a file is a hell of a lot
cheaper than rewriting a whole mbox.  And you don't have to worry about
the (potentially) long window between "user walks away from browser
thinking their changes have been made" and "user's session expires and
changes are written to disk".

        Greg


reply