Wrapping an existing hook (2.0)

[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.

I think my best option is to locate the check_user_id function pointer
and replace it with a new function.  This new function would still make
the call to the proprietary function, but would allow inspection of the
results instead of terminating the request.

Does this sound reasonable?  Any hints as to how I could obtain the
function pointer I'd need to make this all work?


Thanks,


Rick Houser
Auto-Owners Insurance
Systems Support
[phone]

[Sorin Manolache]

Normally, the check_user_id of the proprietary module should return
DECLINE if the AuthType does not match its auth type. Let us assume
that the auth type of the proprietary module is "saf". The auth type
is set with the AuthType directive.

So, what you could do is to change the auth type in the configuration
from "saf" to your auth type, say "rick". Then, in your check_user_id,
you write

r->auth_type = "saf";
code = ap_run_check_user_id(r); // this will call the check_user_id
hook of the proprietary module. This is a re-entrant call
switch (code) {
// your actions
}

But this works only if you can afford to replace "saf" with "rick" in
the configuration and if the proprietary module declines non-saf
authentication types. Hopefully you're lucky, I have never tried the
solution I'm proposing.

--
S

On Fri, Oct 3, 2008 at 17:11, Houser, Rick <Houser.Rick@...> wrote:

> 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.
>
> I think my best option is to locate the check_user_id function pointer
> and replace it with a new function.  This new function would still make
> the call to the proprietary function, but would allow inspection of the
> results instead of terminating the request.
>
> Does this sound reasonable?  Any hints as to how I could obtain the
> function pointer I'd need to make this all work?
>
>
> Thanks,
>
>
> Rick Houser
> Auto-Owners Insurance
> Systems Support
> [phone]
>
>

[Eric Covener]

On Fri, Oct 3, 2008 at 11:11 AM, Houser, Rick <Houser.Rick@...> wrote:
> 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
covener@...

[Houser, Rick]

Thanks a lot Sorin!

That got me well on my way.  I set my module to run first, skip itself
after the first run, and then re-run the entire check_user_id phase
under it's control.  I then inspect the return codes, manipulate the
result in the expired case (based on the saf module's output headers),
and otherwise return the same code provided.

For the record, auth_type appears to stay null until sometime following
a successful user_id checked, then it becomes something like "Basic" (or
presumably Digest, etc.).  I had needed that module to run, as I must
check against SAF for an expired password.



Thanks,

Rick Houser
Auto-Owners Insurance
Systems Support
[phone]

-----Original Message-----
From: Sorin Manolache [mailto:sorinm@...]
Sent: Friday, October 03, 2008 11:40 AM
To: modules-dev@...
Subject: Re: Wrapping an existing hook (2.0)

Normally, the check_user_id of the proprietary module should return
DECLINE if the AuthType does not match its auth type. Let us assume that
the auth type of the proprietary module is "saf". The auth type is set
with the AuthType directive.

So, what you could do is to change the auth type in the configuration
from "saf" to your auth type, say "rick". Then, in your check_user_id,
you write

r->auth_type = "saf";
code = ap_run_check_user_id(r); // this will call the check_user_id hook
of the proprietary module. This is a re-entrant call switch (code) { //
your actions }

But this works only if you can afford to replace "saf" with "rick" in
the configuration and if the proprietary module declines non-saf
authentication types. Hopefully you're lucky, I have never tried the
solution I'm proposing.

--
S

On Fri, Oct 3, 2008 at 17:11, Houser, Rick <Houser.Rick@...>
wrote:
> 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.
>
> I think my best option is to locate the check_user_id function pointer

> and replace it with a new function.  This new function would still
> make the call to the proprietary function, but would allow inspection
> of the results instead of terminating the request.
>
> Does this sound reasonable?  Any hints as to how I could obtain the
> function pointer I'd need to make this all work?
>
>
> Thanks,
>
>
> Rick Houser
> Auto-Owners Insurance
> Systems Support
> [phone]
>
>

[Houser, Rick]

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
effective.

Thank you as well, Eric,


Rick Houser
Auto-Owners Insurance
Systems Support
[phone]

-----Original Message-----
From: Eric Covener [mailto:covener@...]
Sent: Friday, October 03, 2008 3:54 PM
To: modules-dev@...
Subject: Re: Wrapping an existing hook (2.0)

On Fri, Oct 3, 2008 at 11:11 AM, Houser, Rick <Houser.Rick@...>
wrote:
> 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
covener@...