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
http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlAccessHandler).
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 -
http://perl.apache.org/docs/2.0/user/handlers/http.html#HTTP_Request_Cycle_Phases
- has a corresponding hook in Apache which runs after mod_perl if DECLINED
is returned. This is one of mod_perl's greatest strengths.