mod_auth[nz]_dbd password caching

[Phil Endecott <sp...@chezphil.org>]

Dear All,

First of all, congratulation on the release of 2.2.

I use mod_auth_pgsql at http://anyterm.org/my.html, and found a problem 
earlier in the year.  To get reasonable performance you need to use the 
module's caching mechanism, but this cache is not flushed or updated 
when the database changes.  So things don't work properly when the user 
changes their password.

I started to think about fixing it myself but quickly realised that both 
the database and authentication frameworks were changing in 2.1+ and 
decided to wait before doing anything.  I now see that 2.2 has 
mod_auth[nz]_dbd - great!

However, as far as I can see from 
http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html and the source, 
this new module doesn't do any caching.  Is this true?  To get the sort 
of performance that I need for my site I really need in-memory caching 
of passwords, but I also need to solve mod_auth_pgsql's non-updating 
problem.  The solution to this is to use PostgreSQL's asynchronous 
notification mechanism: the module issues a "LISTEN" command and is then 
notified when the password table changes.  I don't know if the APR DB 
interface has any support for this (it doesn't seem to be documented at 
all at http://apr.apache.org/docs/apr-util/modules.html); even if it 
does, it is not portable to other databases.

Has anyone looked at this?  If no-one is working on this and you think 
it would be a useful feature to add, I may be able to write something 
with a bit of help.

Cheers,

--Phil.

Re: mod_auth[nz]_dbd password caching

[Ian Holsman <li...@holsman.net>]

Hi Phil,
A while back I wrote a auth wrapper which used a MD5 hash inside a 
cookie  to determine if the user was authenticated. If the cookie was 
invalid or not present it would fall back to the regular auth method (in 
your case a DB hit).
It also had a bit which sat just after the authentication section which 
would create the cookie on successful authentication.

If you would like I could see if I can find this.. I don't think I 
actually made use of it after I wrote it ;(

Phil Endecott wrote:
> Dear All,
> 
> First of all, congratulation on the release of 2.2.
> 
> I use mod_auth_pgsql at http://anyterm.org/my.html, and found a problem 
> earlier in the year.  To get reasonable performance you need to use the 
> module's caching mechanism, but this cache is not flushed or updated 
> when the database changes.  So things don't work properly when the user 
> changes their password.
> 
> I started to think about fixing it myself but quickly realised that both 
> the database and authentication frameworks were changing in 2.1+ and 
> decided to wait before doing anything.  I now see that 2.2 has 
> mod_auth[nz]_dbd - great!
> 
> However, as far as I can see from 
> http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html and the source, 
> this new module doesn't do any caching.  Is this true?  To get the sort 
> of performance that I need for my site I really need in-memory caching 
> of passwords, but I also need to solve mod_auth_pgsql's non-updating 
> problem.  The solution to this is to use PostgreSQL's asynchronous 
> notification mechanism: the module issues a "LISTEN" command and is then 
> notified when the password table changes.  I don't know if the APR DB 
> interface has any support for this (it doesn't seem to be documented at 
> all at http://apr.apache.org/docs/apr-util/modules.html); even if it 
> does, it is not portable to other databases.
> 
> Has anyone looked at this?  If no-one is working on this and you think 
> it would be a useful feature to add, I may be able to write something 
> with a bit of help.
> 
> Cheers,
> 
> --Phil.
> 
> 
> 
> 

Re: mod_auth[nz]_dbd password caching

[Nick Kew <ni...@webthing.com>]

On Saturday 03 December 2005 11:39, Phil Endecott wrote:

> Has anyone looked at this?  If no-one is working on this and you think
> it would be a useful feature to add, I may be able to write something
> with a bit of help.

This is beyond the scope of what we've done, which is why you didn't
find it:-)  Please do go ahead and look at it.  I look forward to your
improvements.

-- 
Nick Kew