> -----Ursprüngliche Nachricht----- > Von: Chris Darroch > Gesendet: Dienstag, 4. November 2008 02:14 > An: dev@httpd.apache.org > Betreff: Re: AuthzMergeRules blocks everything in default > configuration > > Ruediger Pluem wrote: > > > I was hoping that your patches would fix this, but sadly > they did not. > > Ironically, the problem appears to have little to do with authz, > but rather authn. The test httpd logs show it's failing to find > an htpasswd-type file in which to check the user's login and password. > That's because there's no AuthBasicProvider in the test config, and > the code -- since way back, I think -- defaults to the "file" authn > provider. > > Looking back in SVN it seems like that should have been the > behaviour for quite a number of years, but I confess I didn't dig > too deeply. Nor did I try out the test suite with 2.2.x to see > if it succeeds as-is, and if so, why. If it does, my hunch would > be that it succeeds because the suite doesn't actually use the normal > authn/z providers, but rather supplies its own module called > mod_authany.c. > > That module contains two different alternative set of functions > based on an #if AP_MODULE_MAGIC_AT_LEAST(20060110, 0) which > corresponds > to, I think, an attempt to just get it to compile after the authn/z > refactoring in trunk. The log comment for r375595 is: > > - attempt to adapt for trunk aaa changes; this doesn't work > but it does at least compile - not sure whether the problem > is in this code or the aaa code. > > At any rate, my guess would be that it works (if it does) with > 2.2.x because the module supplies its own raw check_user_id > (i.e., authn) > and auth_checker (i.e., authz) hook functions which run as > APR_HOOK_FIRST > and probably bypass all the stuff in the usual APR_HOOK_MIDDLE hook > functions of mod_auth_basic and mod_authz_file. So the fact > that it doesn't specify any AuthBasicProvider never comes up because > it bypasses mod_auth_basic entirely. Just a guess. > > At any rate, the patch below makes it run with trunk, and > properly too, in the sense that it uses mod_authn_core and > mod_authz_core to do the heavy lifting and just supplies a tiny > pair of authn/z providers. But, this isn't really a perfect > solution because it's not really correct to put the authn provider > into the AP_MODULE_MAGIC_AT_LEAST(20060110, 0) block, since it > doesn't (I think) have anything in particular to do with that > change. Sorry not to spend more time on this.
I committed a slightly modified version of your patch as r711245 and now the test passes for 2.0.x / 2.2.x / trunk. Thanks for working it out. Regards Rüdiger
