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