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.