perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Foo Ji-Haw <>
Subject Re: Modperl2 + PerlAccessHandler + Sending Cookie
Date Mon, 13 Mar 2006 03:33:00 GMT
Hello Fred,

Ok, the 12 layers of Apache is as cool as the OSI layers. Let's say that 
in my PerlAuthzHandler I verified the user via a cookie (given to the 
client during login). It sounds like double work to retrieve the user 
details again during the PerlResponseHandler phase (I have to do that to 
process the page based on the user). Following the mailing list thread, 
is the only/ preferred way to use the bucket brigade?

Fred Moyer wrote:
> On Mon, 13 Mar 2006, Foo Ji-Haw wrote:
>> Wow, a little tangent to the topic here: I didn't know that you can 
>> do this
>> PerlResponseHandler Apache2::Const::OK
>> Is that 'legal'? It's interesting to know, but I wouldn't know of a 
>> practical use for this trick.
> Specifying a return code for a handler phase is perfectly legal.  I 
> first saw this technique used in 'PerlMapToStorageHandler 
> Apache2::Const::OK' to skip the request phase which maps the uri to a 
> location on disk, but you can use it with any phase.
>> Last question: is it a best practice to do the user and access 
>> authentication check at the PerlAccessHandler level? I like the idea 
>> (obviously I've not been trying this way). A single authentication 
>> module that can be used across various PerlResponseHandler. Easy to 
>> maintain and propogate.
> The PerlAccessHandler phase runs in the same phase of the request 
> cycle as Apache's mod_access module, and is meant to handle the 
> request based on IP and domain information.  In httpd.conf, you can 
> say 'Order Allow, Deny',
> 'Deny from 123.456.789.012', or you can use the PerlAccessHandler 
> phase and
> examine the request IP and accomplish the same functionality ( see
> It is best practice to do access checks.
> Best practice for user authentication is to use PerlAuthenHandler, and 
> best practice for user authorization is the PerlAuthzHandler.  This 
> way, you can modify the request, and return DECLINED, and Apaches 
> authen and authz modules can do additional checks on those phases of 
> the request.  Or you can do authen/authz only in the mod_perl phases 
> and return OK or UNAUTHORIZED and skip Apache's auth/authz modules.
> Each phase in this diagram - 
> - has a corresponding hook in Apache which runs after mod_perl if 
> DECLINED is returned.  This is one of mod_perl's greatest strengths.

View raw message