moin,
i am currently working on mod_authn_dbi (part of the 2.1 Authentication Project http://mod-auth.sourceforge.net/) which uses the new authentication framework of apache 2.1. and was wondering if it was still possible to suggest changes to its interface. i would like the interface to allow modules to change the username during the authentication process from the value that was passed by the browser to some other value that will be used as authenticated user further down the chain. an example scenario: suppose you have users who purchased different kinds of support contracts (e.g gold/silver/bronze) from you, and get access to different kinds of files/info accoding to their level. in such a scenario, you would still want each user to have a separate user/pw tuple, but to the access-control logic it does not matter what name the user has, just what level of support should be granted. so the authentication module could take the user/pw tuple, check it and then pass usernames like "gold", "silver", "bronze" down to other modules or CGIs. i know that some of this could be done with something like GroupFile, but that would require generating groupfiles, and even if authz had database support, would require a second database query. another example: suppose you have a webserver that accepts connections from different networks, and based on where the connections come from you could modify the usernames like "joe" to "joe_internal", "joe_external" (the same thing could e.g be done time-based). third example: suppose you would like users to be able to log in with their full name (including spaces), or email-address or something else that contains characters that your underlying application does not like. the authentication provider could change/reformat the username into something that a CGI can better work with. i could think of a few more examples but i think you get the idea. i admit, that most of this functionality could be achieved in other ways. but this should be better for performance, a lot more flexible and very handy if you need to work with some existing application or userbase that you cannot really change. and the required changes for this are very small, with virtually no downside, compared to what the interface is now. to integrate this, two things would have to be changed. first, the two authentication functions of the new interface (get_realm_hash and check_password) would have to pass the username with an additional level of indirection ("char *user" becomes "char **user"). second, some cleanups in mod_auth_digest would have to be done, which brings me to the second part of this mail: currently, mod_auth_basic and mod_auth_digest behave inconsistently in some cases. for example, if i enter a wrong user/pw combination, mod_auth_basic writes the following logline (i.e. without a username) 127.0.0.1 - - [13/Feb/2004:15:20:55 +0100] "GET /foo/index.html HTTP/1.1" 401 540 but mod_auth_digest logs the following line (i.e. with username): 127.0.0.1 - foo [13/Feb/2004:15:20:43 +0100] "GET /foo/index.html HTTP/1.1" 401 540 there are reasons for either behaviour, but in my opinion, the two modules should log the same, especially since the new AAA framework separates mechanism from providers. another inconsistency would be that if the authentication provider reports and internal error, mod_auth_basic produces an "internal server error" whereas mod_auth_diges produces a "user not found" message, both to the client an in the logs. there are probably other edge cases where the two modules behave inconsistenly. ideally, if i change the paramter of AuthType, other things should stay the same in every possible way. so...would there be a chance that the authentication functions get that small change (i.e. an extra *) in their parameters? it still is a development version of apache after all. if yes, i would be happy to write a patch (or patches) to make the changes, adjust all existing modules in the apache sourcetree and make the necessary cleanups in mod_auth_digest. i just thought i'd ask if there is any chance in getting the patch accepted, before i start coding :-) tty, axel grossklaus
