Re: mod_authn_dbd fix?

[Chris Darroch <ch...@pearsoncmg.com>]

Nick:

> I don't think we ever had that kind of merge.  And it also looks like
> possible overspill/pollution, where directives from the main config
> are not necessarily wanted in a vhost.
> 
> The complexity here seems to stem from two things.  One is
> specifically the treatment of prepared statements.  In retrospect,
> this is a poor approach: we should instead have exported an
> optional "dbd_construct" hook which modules could use to
> prepare statements more cleanly.  My fault, of course, and I'm going 
> to think about whether that can be changed without breaking things.
> 
> The other lies in the different configuration hierarchies:
> mod_dbd lives in the server hierarchy, but prepared statements
> commonly apply per-directory.  This is falling into a similar trap to
> mod_proxy in 2.0.  I *think* that if we can move to a hook, that'll
> go away, if the prepared statements for other modules can be
> taken away from the mod_dbd config.

   Just to clarify my particular bug, here's the configuration I'm
working with:

<Location /foo>
    AuthDigestProvider dbd
    AuthDBDUserRealmQuery "SELECT password FROM users WHERE username = %s"
    ...
</Location>

<VirtualHost ...>
    ## no auth settings, but expect to inherit from main server
</VirtualHost>

   With the change to mod_dbd in 2.2.3, the auth settings are inherited
by the virtual host, as you'd expect.  However, because the prepared
statement isn't inherited any longer, they don't work in the virtual
host.  Hence my quick attempt at a patch to ensure that they do:
from the admin's perspective, I think, the fact that there are prepared
statements involved here is invisible, and auth settings should
"just work" when they're inherited by a virtual host.  At least,
that was my quick take; sorry, I've been travelling and generally
away from the keyboard lately.

   It didn't seem entirely bad to me that mod_dbd would allow
prepared statements to be inherited by virtual hosts, anyway --
isn't that what you'd normally expect with other directives?
Would recognizing a "none" argument to DBDPrepareSQL help, perhaps?
Other directives often use this to allow inherited values to
be overridden and effectively "unset".  Like I said, I'm not 100%
on top of this at the moment, but I'm pretty sure that the
DBD auth settings should inherit cleanly with no other action
required by the admin.  Thoughts, flames?  :-)

Chris.

-- 
GPG Key ID: 366A375B
GPG Key Fingerprint: 485E 5041 17E1 E2BB C263  E4DE C8E3 FA36 366A 375B