httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Houser, Rick" <Houser.R...@aoins.com>
Subject RE: Wrapping an existing hook (2.0)
Date Mon, 06 Oct 2008 20:04:19 GMT
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
(517)703-2580

-----Original Message-----
From: Sorin Manolache [mailto:sorinm@gmail.com] 
Sent: Friday, October 03, 2008 11:40 AM
To: modules-dev@httpd.apache.org
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@aoins.com>
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
> (517)703-2580
>
>



Mime
View raw message