httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Houser, Rick" <>
Subject RE: Wrapping an existing hook (2.0)
Date Mon, 06 Oct 2008 20:18:26 GMT
Whether this is actually correct or not (remember, I'm a newbie Apache
module programmer), I had assumed the correct behavior would be to
handle the password reset logic in a separate phase (or at least a
second call within the same phase) to allow other modules a chance to
catch the result in-between.  So, I was expecting something like a
DECLINED from the check_user_id phase with a request note indicating an
expired password, which would then be read and the password reset logic
handled via a second hook in a later phase.

Even if I could successfully make a case for IBM to add this
functionality, it would take a long time (likely months) to get the
updated functionality.  I really like the current solution of trapping
the entire check_user_id phase, and manipulating the results after the
saf module take's it's turn.  It certainly wouldn't run as fast as just
replacing the saf module's call with my own, but it's certainly

Thank you as well, Eric,

Rick Houser
Auto-Owners Insurance
Systems Support

-----Original Message-----
From: Eric Covener [] 
Sent: Friday, October 03, 2008 3:54 PM
Subject: Re: Wrapping an existing hook (2.0)

On Fri, Oct 3, 2008 at 11:11 AM, Houser, Rick <>
> I'm relatively new to module development, but I have a need to wrap a 
> function in a proprietary module (no source) registered via a 
> check_user_id hook in a proprietary module (mod_auth_saf).  Basically,

> I need to detect an expired password condition.  I've already tried to

> use the normal pre/post hook registration, but that function returns 
> an HTTP_UNAUTHORIZED (some internal basic auth password change 
> feature) instead of DECLINE, so Apache never runs my call.

If you ask Apache to run your code first, the proprietary module
shouldn't be able to prevent yours from being run. You should be able to
make sure that your own logic runs for the expired password case and
just DECLINE for everything else.

IMO an auth_checker probably shouldn't return DECLINED if it can lookup
a user and specifically find they have an expired password -- could you
make a case to IBM for the behavior you ultimately want?

Eric Covener

View raw message