httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Kahan <>
Subject Re: Extending mod_authz_dbd
Date Fri, 17 Apr 2015 11:08:32 GMT
Hello Graham,

Thanks for your feedback. It all makes sense to me. 
Following your reasoning, the only directive that will have i
to stay as is for backwards compatibility will be require 
dbd-group, as it expects either no parameter or the value 
the query will return.

I had initially thought of only using one directive and
extracting the variables from the AuthzDBDQuery arguments, 
substituting them for %s and then preparing the request. Your
proposal is much simpler so I'll go with it.

I'm already looking at the code. Will keep you (and the list)
updated as soon as I have something to share.



On Wed, Apr 15, 2015 at 11:17:04AM +0200, Graham Leggett wrote:
> The limitations we’d have to work with is that all the queries are prepared statements,
and are reused for multiple requests. At the same time any query that is interpreted purely
as a string would need to be protected against SQL injection.
>   Require dbd-login %{REQUEST_URI} %{REQUEST_METHOD} %{REMOTE_USER}
>   AuthzDBDQuery "UPDATE authn SET uri = %s, method = %s WHERE user = %s”
>   Require dbd-logout %{TIME} %{REMOTE_USER}
>   AuthzDBDQuery "UPDATE authn SET logout_time = %s WHERE user = %s”
> To be backwards compatible, "Require dbd-login” on it’s own would imply "Require
dbd-login %{REMOTER_USER}”.
> One possible approach to support completely generic queries might be as follows:
>   Require dbd-query %{REQUEST_URI} %{REMOTE_USER}
>   AuthzDBDQuery “SELECT count(user) FROM authn WHERE uri=%s AND user = %s”
> The bit above where you’d limit the requests to GET or POST you’d probably do with
Limit or LimitExcept.

View raw message