[CAF] CAF development roadmap

Richard Dice rdice at pobox.com
Mon Aug 15 16:40:33 EDT 2005

Hey Matt...

I just noticed your email from earlier on this related topic, so I can reply to
both here.

Sessions are currently being implimented by Apache::SessionX, which uses
Apache::Session.  Apache::Session is very "driver oriented", so it provides a
framework and you tell it what drivers you want for it to use to perform the
various needed functions of sessioning. (I use Apache::SessionX rather than
straight Apache::Session because the interface for describing the drivers
desired in X is much more straightforward than in vanilla, and also attemping to
access a session that doesn't exist in vanilla causes a "die", whereas in X it
takes it as a cue to create a new session.)

The particular driver I believe I am using is Apache::Session::DB_File, which
uses some kind of Berkeley DB structure to create session files, one DB file per
session.  So you can get at what you need in them with the DB_File module I
believe.  However, what Apache::Session puts into the DB file is a function of
the serialization method, which is Storable I believe.  So once you open it up
with DB_File, you unpack it with Storable.  But best to check out which one it
is.  It might be FreezeThaw.  It might be beyond my memory right now.

There is no "automatic session management smarts" in CAF (or
cgi::application::mvcframework, or anything else).  The best way to do it would
be to change the storage mechanism to a database (e.g. Mysql), construct the
session table such that there is a timestamp column on it, and then write a
daemon that inspects the table every hour, looking for rows that haven't been
touched in TIMEOUT time, deleting those rows.  (Note that Apache::SessionX will
still serialize into the database with Storable, so the session store within the
database will still be approximately opaque.  This is why the table should be
instrumented with a few other rows that you manage seperately, so that you can
do SQL manipulations on the table without having to try to inspect the session


Quoting "G. Matthew Rice" <matt at starnix.com>:
> Michael Graham <magog at the-wire.com> writes:
> > > Could you add some anti-DOS (not the MS one) modules to it?  I haven't
> looked
> > > into it much but Xoops has something called Xoops Protector:
> > 
> > Hmmm... interesting.  This is usually done at the apache level with
> > something like mod_security.  However Xoops is in php, so they must be
> > doing it at the application level.
> > 
> > I guess the idea is that if your goal is to "run anywhere" you can't
> > count on the user installing apache modules :)
> Cool.  I think that I found a more pressing feature.  session management.
> This is mostly directed at Richard on LPI's installation.  I'm trying to
> figure out the contents of the sessions.  What's an easy way to list the
> contents.  DB_File/Data::Dumper isn't doing a good job (and, yeah, I haven't
> looked at the code yet :).
> Also, is there anything cleaning up old sessions?
> Long term, a GUI to manage and report them would be good.
> -- 
> g. matthew rice <matt at starnix.com>           starnix, toronto, ontario, ca
> phone: 647.722.5301 x242                                  gpg id: EF9AAD20
> http://www.starnix.com              professional linux services & products
> _______________________________________________
> caf mailing list
> caf at lpi.org
> http://list.lpi.org/cgi-bin/mailman/listinfo/caf

This mail sent through IMP: http://horde.org/imp/

More information about the caf mailing list