RE: Wrapping an existing hook (2.0)
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:[EMAIL PROTECTED]
Sent: Friday, October 03, 2008 11:40 AM
To: [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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
RE: Wrapping an existing hook (2.0)
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 (517)703-2580 -Original Message- From: Eric Covener [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2008 3:54 PM To: [EMAIL PROTECTED] Subject: Re: Wrapping an existing hook (2.0) On Fri, Oct 3, 2008 at 11:11 AM, Houser, Rick [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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
Re: Wrapping an existing hook (2.0)
On Fri, Oct 3, 2008 at 11:11 AM, Houser, Rick [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
