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.
Regards,
-jose
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.
