At 06:04 PM 2/18/02, [EMAIL PROTECTED] wrote:
>I would catch user sessions in PerlInitHandler/PerlTransHandler,
>store/check them in PerlAuthzHandler, where I would also set the
>cookie, and close or refresh them in PerlCleanupHandler.
We do something similar, but we've segmented the process a little
differently.
There's a PerlHeaderParserHandler that does most of the work. It
manages all the session stuff (using Apache::Session), and puts
information from the session into pnotes, where the other handlers can
get to it.
I'm not looking at it right now, but iirc it puts the userid, a list of
groups of which the user is a member, an "is authenticated" flag, and a
reference to the session handle into pnotes. Then, the other handlers
look at the bits that apply to them - the Auth handler just looks at
the authenticated flag, the AuthZ handler looks at the groups list,
etc. It's all configured via httpd.conf.
We use it behind a bunch of sites, and it seems to work just fine. I
like it because none of the handlers are more than a screen long.
Is there any demand for something like this? I could put a package
together if people are interested.
>As I need information between the stage of life, I would use $r->notes
>to
>communicate down the cycle. But then again, if I have some data tied
>to the session (I use Apache::Session), how can I give it to
>the PerlHandler. Is $r->notes proofed for any export, object or
>blessing
>behavior?
If you just want to be able to get at the session further down the
chain, do something like this
$r->pnotes('SESSION_HANDLE' => \%session );
somewhere early on. It'll be there throughout the request.
I don't know if that's any more efficient just hitting the session
whenever you need it, but it makes our lives slightly easier.
cheers,
Todd
