You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by David Castro <dc...@apu.edu> on 2004/08/30 20:09:22 UTC
Trick PerlAuthzHandler into thinking Basic Auth occurred
I currently have a PerlAuthenHandler that performs a authentication
against a WebISO service. Once authentication is successful, I want to
be able to use an Apache authorization module that expects Basic Auth to
have occurred. Specifically, mod_auth_ldap. Is there a way that I can
set the state of the request such that mod_auth_ldap is fooled and gets
the username and some dummy password? I need to do this in both
mod_perl 1.x and 2.x. I have tried several things including:
- Setting the "Authorization" header in the request using header_in
- Setting the username/pass with set_basic_credentials()
First, is it possible? If so, does anyone have any references or sample
code to help me on my way?
Thanks in advance
--
David Castro
Software Architect
Azusa Pacific University
"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ)
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
David Castro wrote:
> Okay, a little more tracking down revealed that handler #5 ("check if
> the user is ok _here_") is never getting called when my module is being
> used, but is for Basic auth. Happen to know under which circumstances
> this occurs/doesn't occur? Maybe there is something else I can set to
> get that mechanism called in the first place. This appears to be the
> main problem I have right now, preventing me from moving forward.
I don't see anything funny in the code to short-circuit the request cycle,
so I would assume that things progress as they ordinarily would, which is
like this:
o apache checks for a "Requires" directive, signaling that the authen and
authz phases should be run.
o the authentication phase runs:
- apache calls mod_perl, which dispatches to your PerlAuthenHandler.
- your PerlAuthenHandler returns OK and ends the authen phase. or your
handler returns 403 (or some other error) and immediately goes to the
logging phase.
o the authorization phase runs
- apache calls mod_perl, which dispatches to your PerlAuthzHandler (if
any). if that handler returns OK then thus ends the authz phase, and
mod_authz_ldap will _not_run. if there are no PerlAuthzHandlers registered
then apache will dispatch to mod_authz_ldap.
basically, these parts are somewhat separated from eachother - apache will
call whatever handlers are registered (your #5 above) and those handlers
will run unless the handlers themselves take special steps to avoid being
run (and return DECLINED so other authentication can occur). I don't see
any signs of that, so I don't know what to say. that is, other than check
out the mod_auth_ldap that ships with httpd-2.0 and see if it is any better
behaved than this module.
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by David Castro <dc...@apu.edu>.
Okay, a little more tracking down revealed that handler #5 ("check if
the user is ok _here_") is never getting called when my module is being
used, but is for Basic auth. Happen to know under which circumstances
this occurs/doesn't occur? Maybe there is something else I can set to
get that mechanism called in the first place. This appears to be the
main problem I have right now, preventing me from moving forward.
on 08/30/04 15:12 David Castro wrote:
> on 08/30/04 15:01 Geoffrey Young wrote:
>
>>>Ooops, yeah. A follow-up email corrected "mod_authz_ldap" to
>>>"mod_auth_ldap". Sorry 'bout that. To give a bit more detail, I am
>>>using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0. Went looking
>>>through the C code of the authz module and found the function it gets
>>>the credentials from:
>>>
>>>char *authz_ldap_get_userdn(request_rec *r) {
>>> authz_ldap_config_rec *sec;
>>> sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
>>> return sec->userdn;
>>>}
>>>
>>>
>>
>>well, close - I think it's authz_ldap_set_username but the problem is the
>>same...
>>
>>basically, mod_authz_ldap is caching the given username in it's private
>>stash - r->per_dir_config is generally used to refer to the httpd.conf
>>configuration data that applies to the current request. so, what I think is
>>going on here is one of the scenarios I posited before:
>>authz_ldap_set_username is only called in auth.c, so if you don't use
>>mod_authz_ldap to do your authentication then you are SOL, since it uses
>>it's cached version of the username instead of grabbing it from one of the
>>standard places after authentication.
>>
>>my suggestion would be to play around with the mod_auth_ldap that ships with
>>httpd-2.0 - it is likely to be moved from experimental in the next release
>>IIRC and is much more well-behaved (judging from both the authors and
>>conversations I've been following).
>>
>>another approach is to try to play around with this module's private data.
>>you can use this code as an example
>> http://www.modperlcookbook.org/code/ch08/Cookbook-LanguagePriority-0.01.tar.gz
>>
>>but I'm afraid the corresponding explanations are not online. and I haven't
>>(yet) proven that this approach works with 2.0, so YMMV.
>>
>>
> Yeah, I just found that in authz_ldap_set_username too. Sigh.
>
> Well, thanks for your help.
>
>>HTH
>>
>>--Geoff
>>
>>
>>
>
>
>--
>David Castro
>Software Architect
>Azusa Pacific University
>
>"My little children, let us not love in word or in tongue,
>but in deed and in truth." -- 1 Jn 3:18 (NKJ)
>
>
--
David Castro
Software Architect
Azusa Pacific University
"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ)
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by David Castro <dc...@apu.edu>.
on 08/30/04 15:01 Geoffrey Young wrote:
>>Ooops, yeah. A follow-up email corrected "mod_authz_ldap" to
>>"mod_auth_ldap". Sorry 'bout that. To give a bit more detail, I am
>>using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0. Went looking
>>through the C code of the authz module and found the function it gets
>>the credentials from:
>>
>>char *authz_ldap_get_userdn(request_rec *r) {
>> authz_ldap_config_rec *sec;
>> sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
>> return sec->userdn;
>>}
>>
>>
>
>well, close - I think it's authz_ldap_set_username but the problem is the
>same...
>
>basically, mod_authz_ldap is caching the given username in it's private
>stash - r->per_dir_config is generally used to refer to the httpd.conf
>configuration data that applies to the current request. so, what I think is
>going on here is one of the scenarios I posited before:
>authz_ldap_set_username is only called in auth.c, so if you don't use
>mod_authz_ldap to do your authentication then you are SOL, since it uses
>it's cached version of the username instead of grabbing it from one of the
>standard places after authentication.
>
>my suggestion would be to play around with the mod_auth_ldap that ships with
>httpd-2.0 - it is likely to be moved from experimental in the next release
>IIRC and is much more well-behaved (judging from both the authors and
>conversations I've been following).
>
>another approach is to try to play around with this module's private data.
>you can use this code as an example
> http://www.modperlcookbook.org/code/ch08/Cookbook-LanguagePriority-0.01.tar.gz
>
>but I'm afraid the corresponding explanations are not online. and I haven't
>(yet) proven that this approach works with 2.0, so YMMV.
>
>
Yeah, I just found that in authz_ldap_set_username too. Sigh.
Well, thanks for your help.
>HTH
>
>--Geoff
>
>
>
--
David Castro
Software Architect
Azusa Pacific University
"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ)
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Ooops, yeah. A follow-up email corrected "mod_authz_ldap" to
> "mod_auth_ldap". Sorry 'bout that. To give a bit more detail, I am
> using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0. Went looking
> through the C code of the authz module and found the function it gets
> the credentials from:
>
> char *authz_ldap_get_userdn(request_rec *r) {
> authz_ldap_config_rec *sec;
> sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
> return sec->userdn;
> }
well, close - I think it's authz_ldap_set_username but the problem is the
same...
basically, mod_authz_ldap is caching the given username in it's private
stash - r->per_dir_config is generally used to refer to the httpd.conf
configuration data that applies to the current request. so, what I think is
going on here is one of the scenarios I posited before:
authz_ldap_set_username is only called in auth.c, so if you don't use
mod_authz_ldap to do your authentication then you are SOL, since it uses
it's cached version of the username instead of grabbing it from one of the
standard places after authentication.
my suggestion would be to play around with the mod_auth_ldap that ships with
httpd-2.0 - it is likely to be moved from experimental in the next release
IIRC and is much more well-behaved (judging from both the authors and
conversations I've been following).
another approach is to try to play around with this module's private data.
you can use this code as an example
http://www.modperlcookbook.org/code/ch08/Cookbook-LanguagePriority-0.01.tar.gz
but I'm afraid the corresponding explanations are not online. and I haven't
(yet) proven that this approach works with 2.0, so YMMV.
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by David Castro <dc...@apu.edu>.
on 08/30/04 13:43 Geoffrey Young wrote:
>>>then all you should need to do is set $r->user to the authenticated
>>>user and
>>>you should be good to go. for completeness, you might also want to set
>>>$r->connection->auth_type to 'Basic', but that is most likely not
>>>required
>>>to get things working.
>>>
>>>
>>>
>>>
>>Hrmm. Yeah, this is what I had thought and tried at one point with no
>>luck. When I use basic auth and let mod_authz_ldap do it's thing, I get
>>"...basic LDAP authentication of user 'test'...", but with my auth
>>module (using the code above) I get "...on user '(null)' failed..." in
>>my logs. So, basic auth is doing something that I am not to get that
>>user set for the underlying authz module, I just can't figure out what
>>the heck it is.
>>
>>
>
>well, I can't find either of those error messages in mod_auth_ldap from
>
> http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html
>
>
>
Ooops, yeah. A follow-up email corrected "mod_authz_ldap" to
"mod_auth_ldap". Sorry 'bout that. To give a bit more detail, I am
using "mod_authz_ldap-0.22" on Apache 2 under RHAS 3.0. Went looking
through the C code of the authz module and found the function it gets
the credentials from:
char *authz_ldap_get_userdn(request_rec *r) {
authz_ldap_config_rec *sec;
sec = ap_get_module_config(r->per_dir_config, &authz_ldap_module);
return sec->userdn;
}
Here is the debugging lines for mod_authz_ldap from my apache logs:
[Mon Aug 30 14:21:07 2004] [debug] authz.c(412): [client 10.10.105.236]
[11032]
authz_ldap_authz called by user '(null)' for URI '/test/'
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(38): [client
10.10.105.236] [11032] initialize LDAP connection
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(60): [client
10.10.105.236] [11032] got ldap connection to *************:389 at
0x08dc05d8
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(74): [client
10.10.105.236] [11032] protocol version set to 3
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(135): [client
10.10.105.236] [11032] bind to ldap server succeeded
[Mon Aug 30 14:21:07 2004] [debug] authz.c(423): [client 10.10.105.236]
[11032]
LDAP connection established
[Mon Aug 30 14:21:07 2004] [debug] authz.c(446): [client 10.10.105.236]
[11032]
starting with return code 0
[Mon Aug 30 14:21:07 2004] [debug] authz.c(460): [client 10.10.105.236]
[11032]
processing requirement role 507
[Mon Aug 30 14:21:07 2004] [debug] authz.c(513): [client 10.10.105.236]
[11032]
role(s) required: 507
[Mon Aug 30 14:21:07 2004] [debug] authz.c(199): [client 10.10.105.236]
[11032]
allocating 20 bytes for role filter
[Mon Aug 30 14:21:07 2004] [debug] authz.c(204): [client 10.10.105.236]
[11032]
role filter: (gidNumber=507)
[Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(50): [client
10.10.105.236] performing substitutions in filter '(gidNumber=507)'
[Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(102): [client
10.10.105.236] filter substitutions give new filter '(gidNumber=507)'
[Mon Aug 30 14:21:07 2004] [debug] authz.c(47): [client 10.10.105.236]
[11032] checking filter '(null)' for user '(gidNumber=507)'
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(174): [client
10.10.105.236] [11032] search from '(null)' for '(gidNumber=507)' returns 32
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(191): [client
10.10.105.236] [11032] retry the search
[Mon Aug 30 14:21:07 2004] [error] [client 10.10.105.236] ldap [11032]
search for filter '(gidNumber=507)', scope = 0 on user '(null)' failed
[Mon Aug 30 14:21:07 2004] [debug] authz.c(209): [client 10.10.105.236]
[11032]
role requirement failed
[Mon Aug 30 14:21:07 2004] [debug] authz.c(585): [client 10.10.105.236]
authz_ldap_authz()[11032]: elapsed time: 37ms, cpu time: 0ms
[Mon Aug 30 14:21:07 2004] [debug] authz.c(587): [client 10.10.105.236]
[11032]
return code from authz_ldap_authz: NOK (403)
>on in httpd-2.0, so I'm not sure exactly where the error is coming from.
>one thing of interest is that in the former code they call
>ap_get_basic_auth_pw() from the authz phase, which is clearly wrong and will
>subvert the approach I outlined above. but if you can't set the
>Authorization header either (recipe 13.4) and have it work then I don't know.
>
>anyway, if you give me a pointer to the mod_auth_ldap code you're using I
>can look it over and see, but there are only a few different places where
>the user information can come from - $r->user directly, or from the
>Authorization header.
>
>well, I guess there is a third - mod_auth_ldap could assume (or require)
>that it is the authentication handler and instead of looking in those two
>places it could rely on some internal cache. in fact, this seems to be the
>case, as the "AuthLDAPAuthoritative" directive seems to be designed exactly
>for this purpose. the docs indicate that you should set it to "no" if you
>want to use something other than mod_auth_ldap for the authentication phase,
>which is what you are trying to do. so, have you set this directive and
>tried a the other two approaches (setting the incoming header and/or just
>$r->user)?
>
>--Geoff
>
>
>
--
David Castro
Software Architect
Azusa Pacific University
"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ)
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> then all you should need to do is set $r->user to the authenticated
>> user and
>> you should be good to go. for completeness, you might also want to set
>> $r->connection->auth_type to 'Basic', but that is most likely not
>> required
>> to get things working.
>>
>>
> Hrmm. Yeah, this is what I had thought and tried at one point with no
> luck. When I use basic auth and let mod_authz_ldap do it's thing, I get
> "...basic LDAP authentication of user 'test'...", but with my auth
> module (using the code above) I get "...on user '(null)' failed..." in
> my logs. So, basic auth is doing something that I am not to get that
> user set for the underlying authz module, I just can't figure out what
> the heck it is.
well, I can't find either of those error messages in mod_auth_ldap from
http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html
on in httpd-2.0, so I'm not sure exactly where the error is coming from.
one thing of interest is that in the former code they call
ap_get_basic_auth_pw() from the authz phase, which is clearly wrong and will
subvert the approach I outlined above. but if you can't set the
Authorization header either (recipe 13.4) and have it work then I don't know.
anyway, if you give me a pointer to the mod_auth_ldap code you're using I
can look it over and see, but there are only a few different places where
the user information can come from - $r->user directly, or from the
Authorization header.
well, I guess there is a third - mod_auth_ldap could assume (or require)
that it is the authentication handler and instead of looking in those two
places it could rely on some internal cache. in fact, this seems to be the
case, as the "AuthLDAPAuthoritative" directive seems to be designed exactly
for this purpose. the docs indicate that you should set it to "no" if you
want to use something other than mod_auth_ldap for the authentication phase,
which is what you are trying to do. so, have you set this directive and
tried a the other two approaches (setting the incoming header and/or just
$r->user)?
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by David Castro <dc...@apu.edu>.
on 08/30/04 12:09 Geoffrey Young wrote:
>>Heh. Yeah, maybe the point I needed to make more clear is this. The
>>PerlAuthenHandler is NOT relying on basic auth to actually have ever
>>occured. It is a handler that gets credentials via another service
>>altogether. Suffice it to say that no basic auth ever happens, but my
>>PerlAuthenHandler gets a username. Now, I want to fool the authz
>>module, which expects basic auth to have occurred, into thinking that
>>basic auth occurred. So, somehow I need to setup the
>>environment/request object/etc. to accomplish this.
>>
>>
>
>ah :)
>
>then all you should need to do is set $r->user to the authenticated user and
>you should be good to go. for completeness, you might also want to set
>$r->connection->auth_type to 'Basic', but that is most likely not required
>to get things working.
>
>
Hrmm. Yeah, this is what I had thought and tried at one point with no
luck. When I use basic auth and let mod_authz_ldap do it's thing, I get
"...basic LDAP authentication of user 'test'...", but with my auth
module (using the code above) I get "...on user '(null)' failed..." in
my logs. So, basic auth is doing something that I am not to get that
user set for the underlying authz module, I just can't figure out what
the heck it is.
>for more discussions on hacking together your own authentication mechanism,
>where both of these things are discussed, see recipes 13.7 and 13.8 in the
>mod_perl developer's cookbook. all of chapter 13 can be read online for free:
>
> http://www.modperlcookbook.org/chapters/ch13.pdf
>
>HTH
>
>--Geoff
>
>
>
--
David Castro
Software Architect
Azusa Pacific University
"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ)
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Heh. Yeah, maybe the point I needed to make more clear is this. The
> PerlAuthenHandler is NOT relying on basic auth to actually have ever
> occured. It is a handler that gets credentials via another service
> altogether. Suffice it to say that no basic auth ever happens, but my
> PerlAuthenHandler gets a username. Now, I want to fool the authz
> module, which expects basic auth to have occurred, into thinking that
> basic auth occurred. So, somehow I need to setup the
> environment/request object/etc. to accomplish this.
ah :)
then all you should need to do is set $r->user to the authenticated user and
you should be good to go. for completeness, you might also want to set
$r->connection->auth_type to 'Basic', but that is most likely not required
to get things working.
for more discussions on hacking together your own authentication mechanism,
where both of these things are discussed, see recipes 13.7 and 13.8 in the
mod_perl developer's cookbook. all of chapter 13 can be read online for free:
http://www.modperlcookbook.org/chapters/ch13.pdf
HTH
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by David Castro <dc...@apu.edu>.
on 08/30/04 11:26 Geoffrey Young wrote:
>David Castro wrote:
>
>
>>I currently have a PerlAuthenHandler that performs a authentication
>>against a WebISO service. Once authentication is successful, I want to
>>be able to use an Apache authorization module that expects Basic Auth to
>>have occurred. Specifically, mod_auth_ldap. Is there a way that I can
>>set the state of the request such that mod_auth_ldap is fooled and gets
>>the username and some dummy password? I need to do this in both
>>mod_perl 1.x and 2.x. I have tried several things including:
>>
>> - Setting the "Authorization" header in the request using header_in
>> - Setting the username/pass with set_basic_credentials()
>>
>>First, is it possible? If so, does anyone have any references or sample
>>code to help me on my way?
>>
>>
>
>hmm, I don't think I follow.
>
>the authorization phase (your PerlAuthzHandler) will not run unless the
>authentation phase (your PerlAuthenHandler) has sucessfully matched a
>username and password. if your PerlAuthenHandler returns OK that means that
>Basic auth has occurred and that the user/password pair stripped from the
>Authorization header matches whatever backend datastore you used. it also
>means that mod_auth_ldap will _not_ be called for the authentication phase -
>for both authen and authz the first handler to return OK wins and
>short-circuits all other handlers for that phase.
>
>so, assuming you have gotten to the authorization phase, if you called
>$r->get_basic_auth_pw() in your PerlAuthenHandler then $r->user will be set
>to the incoming username from the Authorization header - that will be the
>username that mod_auth_ldap uses in future authorization comparisons.
>
>at this point, I would expect the password to be meaningless since in the
>authz phase it's $r->user that is important. that is, once you have
>verified the user in the auth phase the utility of the password is gone,
>since authz checks are against a _known_ user. this is why $r->user is a
>slot in the request_rec but $r->password is not - the importance of the user
>persists but the importance of the password does not.
>
>so, with all of this in mind, exactly what is it that you want to do in the
>authz phase with mod_auth_ldap and what information does it require? I
>would suspect that it would only use $r->user, which should be set up
>already (and you can check). if you can clarify a bit more for me maybe I
>can help more :)
>
>
Heh. Yeah, maybe the point I needed to make more clear is this. The
PerlAuthenHandler is NOT relying on basic auth to actually have ever
occured. It is a handler that gets credentials via another service
altogether. Suffice it to say that no basic auth ever happens, but my
PerlAuthenHandler gets a username. Now, I want to fool the authz
module, which expects basic auth to have occurred, into thinking that
basic auth occurred. So, somehow I need to setup the
environment/request object/etc. to accomplish this.
Making sense?
>--Geoff
>
>
>
>
--
David Castro
Software Architect
Azusa Pacific University
"My little children, let us not love in word or in tongue,
but in deed and in truth." -- 1 Jn 3:18 (NKJ)
Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
David Castro wrote:
> I currently have a PerlAuthenHandler that performs a authentication
> against a WebISO service. Once authentication is successful, I want to
> be able to use an Apache authorization module that expects Basic Auth to
> have occurred. Specifically, mod_auth_ldap. Is there a way that I can
> set the state of the request such that mod_auth_ldap is fooled and gets
> the username and some dummy password? I need to do this in both
> mod_perl 1.x and 2.x. I have tried several things including:
>
> - Setting the "Authorization" header in the request using header_in
> - Setting the username/pass with set_basic_credentials()
>
> First, is it possible? If so, does anyone have any references or sample
> code to help me on my way?
hmm, I don't think I follow.
the authorization phase (your PerlAuthzHandler) will not run unless the
authentation phase (your PerlAuthenHandler) has sucessfully matched a
username and password. if your PerlAuthenHandler returns OK that means that
Basic auth has occurred and that the user/password pair stripped from the
Authorization header matches whatever backend datastore you used. it also
means that mod_auth_ldap will _not_ be called for the authentication phase -
for both authen and authz the first handler to return OK wins and
short-circuits all other handlers for that phase.
so, assuming you have gotten to the authorization phase, if you called
$r->get_basic_auth_pw() in your PerlAuthenHandler then $r->user will be set
to the incoming username from the Authorization header - that will be the
username that mod_auth_ldap uses in future authorization comparisons.
at this point, I would expect the password to be meaningless since in the
authz phase it's $r->user that is important. that is, once you have
verified the user in the auth phase the utility of the password is gone,
since authz checks are against a _known_ user. this is why $r->user is a
slot in the request_rec but $r->password is not - the importance of the user
persists but the importance of the password does not.
so, with all of this in mind, exactly what is it that you want to do in the
authz phase with mod_auth_ldap and what information does it require? I
would suspect that it would only use $r->user, which should be set up
already (and you can check). if you can clarify a bit more for me maybe I
can help more :)
--Geoff
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html