Right now there are zillions of 1.3 auth modules around which have a
check_auth() stage which essentially does:
for each require line
do
if require valid-user
return OK
if require user
then
foreach uid
do
if r->user == uid
return ok
end
endif
end
due to cut-and-paste module creation; and the fact that some people want
to remove mod_auth.c from the server to not have mod_auth.c its own
authenticate_basic_user() against a file in the server.
I am looking at a cookie cutter approach for 2.0.... because in 2.0
everything is better (of course!) and I'd like to simplify things as much
as possible.
So if you look at mod_auth_dbm.c in 2.0 we rely on mod_auth.c to be to be
able to do things like
require user foo
even when we are not using AuthUserFile.
Aside: (And when mod_auth is not LoadModule-d in, but mod_auth_dbm is -
things just got a bit more interesting -as we do not keep a tally
as to if each require line is actually used or parsed sensible by
anyone - so interesting things can sneak past the admin which does
not test his server after a change - **).
So I'd like to remove the (not that technically sound) excuses for people
not to have mod_auth.c in the server anymore. I.e. perception mostly.
Would it be fair to say that
-> We want to make it as easy as possible for those old legacy
mod_auth_* modules to be ported - and as a guideline do not want
them do their own 'require user' stuff anymore.
We want that done central. In a standard module.
-> If we add to mod_auth.c a 'AuthUserFile 'OFF"' or some other
very 'cheap' VISIBLE disbable then there is no reason left for
mod_auth modules to do their own 'require user/require valid user'
work. This would be just to reasure people; the default is NULL
anyway (*). Or alternatively an Auth directive picked up by
mod_auth which uses the ap_auth_type or the source of the info.
Or better perhaps
-> Or alternatively mod_auth is split into a mod_auth and a
a mod_require. The first does the File based username
checking; the latter does the "require valid-user", "require
user foo" checks. 'require group' can stay in mod_auth or
go into a mod_auth_group.
With that out of the way; In the long term may want to do the same for
groups checking which now fundamentally must happen in each module as
group findings are not shared.
I.e. just like we have a r->user have a r->groups field (a table rather
than a char*) which lists the groups the user is part off. (Though I
recognize that there will always be group auth modules which need to to
the reverse; i.e. check if a user is in a list of groups - or, for these
cases, an additional check_group_access handler mirroring the user_access
stage).
Any thoughds ? Note that part of the above problem is perception causing
the duplication of mod_auth because of the file association.
Dw
--
Dirk-Willem van Gulik
Ad *: We'd need to touch up the error messages of mod_auth a little.
Ad **: Which of course would need another hook... and run method in
apache 3.0.
