Any thoughts on this stuff? I'd like to try my ideas on the list before going ahead and implementing it in practice.
----- Forwarded message from Martin Wickman <[EMAIL PROTECTED]> ----- From: Martin Wickman <[EMAIL PROTECTED]> Subject: Re: Combining authen-handler with mod_auth On Mon, Jul 07, 2003 at 10:06:59AM -0700, Geoffrey Young wrote: [...] >>I think a lot of interesting password policies could be implemented >>if it was possible to run perl-code before and after existing >>authentication modules. Is it feasible to add this to the current >>mod_perl as a runtime option? > > runtime is not likely to be possible. I'm considering a patch that > would make the hook behavior configurable as a compile-time option, Instead of trying to cram multiple perl-script into the same Authen phase (which could not be done without patching Apache and/or mod_perl), I ended up using other phases but Authen. Other phases that should not really be used for authentication like this and breaks a few Apache rules. I specifically had to change mod_auth_ so it returns sets a apache note and returns DECLINED instead of stopping the whole request with a HTTP_UNAUTHORIZED. The change is simple and can be applied to any auth module without much effort. So, I thought I'd ask the list for opinions regarding this poor-mans-approach. Here is the setup: <Location /secure/> AuthType Basic AuthName "Secure Area" Require valid-user # Find userinfo in cache. If user is banned, return # HTTP_UNAUTHORIZED else let him through to next handler PerlAccessHandler MyApache::Bouncer # The actual auth module. Patched so it creates an apache # request note if user is unauthorized + let request through # to next handler (DECLINED) _even tho_ user failed! AuthExternal wicauth # If apache note contains current user, update cache (nfailures # count) and return HTTP_UNAUTHORIZED or return OK PerlFixUpHandler MyApache::Ledger </Location> Here is my tidied error_log log which shows how it works. [ User wic with wrong pwd below ] Bouncer: wic not in cache. Letting through. AuthExtern wicauth: Failed for user wic. Ledger: wic not in cache. Adding. Bouncer: wic in cache: 1 <--- nfailures AuthExtern wicauth: Failed for user wic Ledger: wic in cache. Updating. [ ... 10 times or something like that ... ] Bouncer: wic in cache: 10 AuthExtern wicauth: Failed for user wic. Ledger: banning wic for 2 hours. Bouncer: wic in cache: banned Bouncer: wic is banned! Bouncer: wic in cache: banned Bouncer: wic is banned! [ The user wic is banned and have to wait for 2 hours until Bouncer will let him through. ] Bouncer: wic banning time has expired. Letting through. AuthExtern wicauth: OK accepted for user wic. Ledger: wic login ok. By keeping count like this (and assuming it works in a real situation), one can device lots of cool ways to add login and password policies. Just change relevant part in the Bouncer/Ledger. (Btw, I am using Cache::FileCache to keep track of number of failed retries.) ----- End forwarded message -----