httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Darroch <chr...@pearsoncmg.com>
Subject Re: User/Realm order in AuthDBDUserRealmQuery (mod_authn_dbd)
Date Sat, 16 May 2009 04:26:42 GMT
KaiGai Kohei wrote:

> I think a new directive with formats support is preferable to
> keep compatibility with existing directives.

   We definitely need compatibility with existing directives.
That's why I figured the extra parameter would be optional --
if you only provided one parameter, the query, it would be handled
as it is now (i.e., user and realm interpolated, in that order).

> For example:
>    AuthDBDUserRealmQueryFmt \
>        "SELECT md5(uname || ':' || %R || ':' || upass) FROM uaccount \
>             WHERE uname = %u AND uaddr >>= %a::inet"
> 
> When the directive is given, mod_authn_dbd can register the type and
> order of the charater to be replaced. Then it can set up as a paramter
> list on query execution phase.

   I think you'll find that trying to change the format specifiers
(e.g., "%u", "%a::inet", etc.) is not the way to go.  These are
handled by APR-util, not mod_authn_dbd.  At least in APR trunk,
there's a large set of format specifiers supported and these were
hashed through some time ago (e.g., "%pa" for date/timestamps, etc.)
on the APR lists.  I don't think it's a good idea to start adding
more DB query format specifier parsing in httpd.

   That's why I figured you might stick with APR-util's specifiers
in the query itself, but then provide a comma-delimited list of
specifiers in the optional argument to the AuthDBD* directives.
These would be follow mod_log_config and would represent the various
request-related data one could interpolate into the query.
(E.g., "u" for user, "H" for protocol, "a" for remote address, etc.)
That would provide a vast number of possibilities (more, certainly,
than anyone really needs) but would at least stick to existing
format specifiers as defined for both APR-util DBD and httpd now.

> Should I submit a patch to support the feature?

   Patches are always welcome (although I'm the first to admit
that I'm too slow at reviewing and committing them).

Chris.

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


Mime
View raw message