perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Castro <>
Subject Re: Trick PerlAuthzHandler into thinking Basic Auth occurred
Date Mon, 30 Aug 2004 21:27:47 GMT
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
>>>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
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] 
authz_ldap_authz called by user '(null)' for URI '/test/'
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(38): [client] [11032] initialize LDAP connection
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(60): [client] [11032] got ldap connection to *************:389 at 
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(74): [client] [11032] protocol version set to 3
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(135): [client] [11032] bind to ldap server succeeded
[Mon Aug 30 14:21:07 2004] [debug] authz.c(423): [client] 
LDAP connection established
[Mon Aug 30 14:21:07 2004] [debug] authz.c(446): [client] 
starting with return code 0
[Mon Aug 30 14:21:07 2004] [debug] authz.c(460): [client] 
processing requirement role 507
[Mon Aug 30 14:21:07 2004] [debug] authz.c(513): [client] 
role(s) required: 507
[Mon Aug 30 14:21:07 2004] [debug] authz.c(199): [client] 
allocating 20 bytes for role filter
[Mon Aug 30 14:21:07 2004] [debug] authz.c(204): [client] 
role filter: (gidNumber=507)
[Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(50): [client] performing substitutions in filter '(gidNumber=507)'
[Mon Aug 30 14:21:07 2004] [debug] filterexpand.c(102): [client] filter substitutions give new filter '(gidNumber=507)'
[Mon Aug 30 14:21:07 2004] [debug] authz.c(47): [client] 
[11032] checking filter '(null)' for user '(gidNumber=507)'
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(174): [client] [11032] search from '(null)' for '(gidNumber=507)' returns 32
[Mon Aug 30 14:21:07 2004] [debug] utilities.c(191): [client] [11032] retry the search
[Mon Aug 30 14:21:07 2004] [error] [client] 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] 
role requirement failed
[Mon Aug 30 14:21:07 2004] [debug] authz.c(585): [client] 
authz_ldap_authz()[11032]: elapsed time: 37ms, cpu time: 0ms
[Mon Aug 30 14:21:07 2004] [debug] authz.c(587): [client] 
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

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) 

View raw message