You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 2001/08/19 17:50:17 UTC

mod_auth again

Currently, mod_auth (and friends) return DECLINED when asked
to authenticate a user and there is no AuthUserFile declared.
This means that the server checks with all the other
authentication handlers, and is likely to eventually die
with a 500 status and the cryptic 'no user file?' message
in the log file.

The lack of an AuthUserFile directive really *is* a configuration
error, but I would like to propose modifying this behaviour
slightly.  If mod_auth is authoritative and there is no
userfile, I propose logging the missing file in the error log
and returning HTTP_UNAUTHORIZED.  This will hopefully save
a wee bit of confusion, and also potentially some cycles
from the core consulting other, non-authoritative, modules
to end up with the same result.
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: mod_auth again

Posted by sterling <st...@covalent.net>.
by the way, i submitted a patch to fix those crazy 'no user file?'
messages a while ago( message appended to this one).

I think the core should return HTTP_UNAUTHORIZED when all auth modules
return DECLINED (instead of calling decl_die).  This way you can give all
auth modules a chance at authenticating without caring the order they are
loaded.

While you're in there, another quirk is that mod_auth handles the
'Require valid-user' case.  This seems like it is an apache standard and
should be in the core (so you don't have to have mod_auth enabled simply
to return OK on a Require valid-user).

--sterling


On Sun, 19 Aug 2001, Rodent of Unusual Size wrote:

> Currently, mod_auth (and friends) return DECLINED when asked
> to authenticate a user and there is no AuthUserFile declared.
> This means that the server checks with all the other
> authentication handlers, and is likely to eventually die
> with a 500 status and the cryptic 'no user file?' message
> in the log file.
>
> The lack of an AuthUserFile directive really *is* a configuration
> error, but I would like to propose modifying this behaviour
> slightly.  If mod_auth is authoritative and there is no
> userfile, I propose logging the missing file in the error log
> and returning HTTP_UNAUTHORIZED.  This will hopefully save
> a wee bit of confusion, and also potentially some cycles
> from the core consulting other, non-authoritative, modules
> to end up with the same result.
>



------------------------------------------------------------------
Hi all -

When no auth handlers are willing to handle a  request, you get an
internal error (which is correct) and a log message  which says 'No User
File?' or 'No Group File?'.  This can be very  misleading (especially if
you don't have mod_auth enabled :).  I suggest a  more accurate message is
printed - (e.g. the patch below) Feel free to change the wording :)


sterling


Index: modules/http/http_request.c
===================================================================
RCS file: /home/cvspublic/httpd-2.0/modules/http/http_request.c,v
retrieving revision 1.105
diff -u -r1.105 http_request.c
--- modules/http/http_request.c	2001/08/06 19:13:02	1.105
+++ modules/http/http_request.c	2001/08/06 19:45:17
@@ -316,14 +316,14 @@
         if (ap_some_auth_required(r)) {
             if (((access_status = ap_run_check_user_id(r)) != 0) || !ap_auth_type(r)) {
                 decl_die(access_status, ap_auth_type(r)
-		    ? "check user.  No user file?"
-		    : "perform authentication. AuthType not set!", r);
+                         ? "check user.  No authentication handler."
+                         : "perform authentication. AuthType not set!", r);
                 return;
             }
             if (((access_status = ap_run_auth_checker(r)) != 0) || !ap_auth_type(r)) {
                 decl_die(access_status, ap_auth_type(r)
-		    ? "check access.  No groups file?"
-		    : "perform authentication. AuthType not set!", r);
+                         ? "check auth.  No authorization handler."
+                         : "perform authentication. AuthType not set!", r);
                 return;
             }
         }
@@ -338,14 +338,14 @@
             }
             if (((access_status = ap_run_check_user_id(r)) != 0) || !ap_auth_type(r)) {
                 decl_die(access_status, ap_auth_type(r)
-		    ? "check user.  No user file?"
-		    : "perform authentication. AuthType not set!", r);
+                         ? "check user.  No authentication handler."
+                         : "perform authentication. AuthType not set!", r);
                 return;
             }
             if (((access_status = ap_run_auth_checker(r)) != 0) || !ap_auth_type(r)) {
                 decl_die(access_status, ap_auth_type(r)
-		    ? "check access.  No groups file?"
-		    : "perform authentication. AuthType not set!", r);
+                         ? "check auth.  No authorization handler."
+                         : "perform authentication. AuthType not set!", r);
                 return;
             }
         }



Re: mod_auth again

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"Ian Kallen " wrote:
> 
> Oooh boy, I think this stuff is a mess (or if it's neater than my
> perception of it, I need to get it clarified for myself :)

Yes, it is very messy.  I have a massively cleaned-up version
in my head, but..

> It is my opinion that if AuthUserFile is not specified mod_auth
> should decline; I'm indicating that I don't want mod_auth to have
> any say in the authentication for this resource.

If it is also labelled as authoritative, you have a conflict.
I would prefer to resolve that conflict away from a 500 error
visible to the user, although that is certainly defensible -- it
*is* a config error.

It would be nice if these handlers were passed a flag about
forced authoritativeness -- the last module called should be
considered authoritative even if the config does not expressly
say so.

And if there is a config error, the module that knows what it is
should be the one to log the message, rather than the core
guessing about it.
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: mod_auth again

Posted by "Ian Kallen <iank@covalent.net>" <ia...@covalent.net>.
Oooh boy, I think this stuff is a mess (or if it's neater than my
perception of it, I need to get it clarified for myself :)

It is my opinion that if AuthUserFile is not specified mod_auth should
decline; I'm indicating that I don't want mod_auth to have any say in the
authentication for this resource.  If no AuthUserDBFile is configured,
mod_auth_db should similarly decline.  Everyone of the auth modules should
have their shot at it but decline if no resource for looking up the
username is provided.  If none of the auth modules have a lookup resource
configured and they're not using the "authoritative" behavior, then
eventually core should pick it up and default to 401 (and perhaps log
something like "authentication credentials required but no resource to
lookup and match against specified.  If that's really what you want then
just say 'order deny, allow && deny from all', dumbo!")

Having core throwing a 500 error or an auth module "authoritative" but its
resource specification unspecified highlights a real problem.  I may want
to specify what resource to consult first.  Say 99.9% of my users are in a
db but there are special case users in a textfile, so I'd want
1) authuserdbfile consulted first, if the user is looked up by the
password mismatched, 401; if the user is not found, declined
2) authuserfile consulted second, same decisions
3) core sees that authuserdbfile and authuserfile had their shot and
declined and throws a 401
Right now, with my understanding of module order no longer being user
configured, I'm not sure how to express this in httpd 2.0 while it may be
expressed in 1.3 by manipulating module order and making the last module
authoritative.

About the authorative stuff, I'd rather signify that an auth module is
authoritative with the absence of other auth module lookup resources and
make it "the last in line."

-Ian

On Sun, 19 Aug 2001, Rodent of Unusual Size wrote:

> Currently, mod_auth (and friends) return DECLINED when asked
> to authenticate a user and there is no AuthUserFile declared.
> This means that the server checks with all the other
> authentication handlers, and is likely to eventually die
> with a 500 status and the cryptic 'no user file?' message
> in the log file.
> 
> The lack of an AuthUserFile directive really *is* a configuration
> error, but I would like to propose modifying this behaviour
> slightly.  If mod_auth is authoritative and there is no
> userfile, I propose logging the missing file in the error log
> and returning HTTP_UNAUTHORIZED.  This will hopefully save
> a wee bit of confusion, and also potentially some cycles
> from the core consulting other, non-authoritative, modules
> to end up with the same result.
> 

cheers,
-Ian

--
Ian Kallen <ia...@covalent.net> | AIM: iankallen