Sounds interesting.
Is this module just managing the sessionID or also the session data? i.e.
is the manager capable of storing complex objects (via something like
Storable or Data::Dumper)? Will you provide hooks "caching and DB
abstraction" layers so that the developer can provide the backend
implementation?
~J
- Original Message -
From: "Greg Cope" [EMAIL PROTECTED]
To: "Modperl list" [EMAIL PROTECTED]
Sent: Sunday, September 10, 2000 2:40 PM
Subject: [ RFC ] A Session Manager module
Dear All
As some of you are aware for the past few weeks I have been working on a
Session Manager style module.
It works (ish ;-), I know of a few issues (that may not be important
enough to change), but it works in my developement environment.
What do I do with it now ? I think it may fit in well as a front end to
Apache::Session, although it needs a name. Its only around 400 lines
(including some POD and comments).
It could fit in quite well with Apache::Session (ie providing a session
id, and Apache::Session does the server side storage). It may also fit
in with other implementations such as Embperl, Apache::ASP, and Mason -
although most of these have their own implenetations.
My original plan - believe it or not - was to write a short "how to"
style tutorial to creating a mod perl shopping cart, the idea was not to
have another shopping cart, as there are many other better
implentations, but to have a few reasonably easy examples of mod_perl in
a real world type example. This was inspired by someones post a few
months back for documentation / articles etc. Well I started and wrote
a few modules, and went on to create a templating module (as per any
true path to mod_perl wisdom!), this session module and a DB abstraction
layer (and aparently I should be creating a caching module as well!).
Well any ideas - please let me know.
Greg Cope
A few details below.
AIM:
To manage session ID's between client and server - to get (or optionally
set) a sesion id via Cookies, Mungled URL or path_info.
Implemetation:
Uses a transhandler.
Optional configurations to alter logic / options via a package scalar eg
(some but not all) in a startup.pl:
use SessionManager();
$SessionManager::DIR_MATCH = '/foohandler'; # default is match
everything of /\.html/ !
$SessionManager::REDIRECT = 1; # default to no
redirect
$SessionManager::DEBUG = 7; # default debug is off
$SessionManager::SESSION_ID_LENGTH = 32;# nice long ID lenght
$SessionManager::NON_MATCH = '\.gif|\.jpeg|\.jpg'; # ignore images
i.e. the above will session manager a URI matching 'foohandler', if
cookies are off it will redirect and set an mungled URI with a session
id length of 32 - it will also dump loads of debug info (between 3 and
20 lines a request), and ignore any gifs, jpegs, and jpg files within a
URI 'foohandler'.
Also:
$SessionManager::COOKIES_ONLY = 1;
Will only try cookies and then stop
$SessionManager::ARGS_ONLY = 1;
Will only try ARGS (after cookies).
$SessionManager::URI_FIRST = 1;
Try URI (mangled) after cookies, before ARGS, this allows changing the
order of which things are checked.
$SessionManager::USE_ENV = 1;
Instead of using pnotes entries use Environmental variables.
There are aslo a few other bits in the works for trying to setting a
cookie if they are off by redirecting, and then using a mangled URI or
ARGS if that failed - this will have a TTL, and DOMAIN vars that will
allow overriding of the defaults.
Thats about it.
