This would be OK except that there is a bigger problem that I looked into trying to fix at one point but never completed it. The problem is the duplication of authorization types. Currently we have both mod_authz_groupfile and mod_authz_dbm implementing the types "group" and "file-group". This causes a problem because if both of these modules are loaded and the configuration contains the directive:
require group foo or require file-group which authorization module handles it? Well it seems to be completely dependant on load order and/or the use of the directives AuthzXXXAuthoritative. In addition to implementing an optional function in mod_authz_owner to get the owner id, all authorization types should probably be renamed to be unique. group - mod_authz_groupfile dbm-group - mod_authz_dbm dbd-group - mod_authz_dbd ldap-group - mod_authnz_ldap (already done) etc... thoughts on this...? Brad >>> On 10/24/2005 at 4:08:39 pm, in message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > I've just looked at authz. > > There's an IMO ugly hack whereby every authz provider has to run after > authz_file and make a special case for file-group. It's repitition of > identical code, and breaks modularity. > > Wouldn't it be better for mod_authz_owner to be able to determine whether > file-group is satisfied before returning, instead of faffing about with Notes > and complicating the AuthAuthoritativeness logic? We could implement that > using a file-group optional hook in mod_authz_owner. The normal authz_FOO > modules can then implement the hook and properly preserve modularity. > > Any thoughts?
