httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 51994] New: Mod_authn_socache should have some way to flush the cache
Date Fri, 07 Oct 2011 15:35:20 GMT

             Bug #: 51994
           Summary: Mod_authn_socache should have some way to flush the
           Product: Apache httpd-2
           Version: 2.3.12-beta
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: mod_authn_socache
    Classification: Unclassified

I think the major defect with mod_authn_socache is that it lacks a way to flush
the authentication cache. The timeout just isn't fully satisfactory. It means
that it takes minutes before a password change actually takes effect, and a
user can keep accessing resources for minutes after his account has been
deleted.  If there were some mechanism by which a password change program or
account deletion program could signal mod_authn_socache to flush it's cache,
then not only would these actions take effect instantaneously, but
administrators could freely set their timeout values higher, improving
performance on all authentications.

Either a mechanism that empties the entire cache or one that just de-caches a
single user would be fine.

I think the easiest way to do this would be to have a special password that
flushes the cache. So, if a user makes a request with the special password, say
'AllOthersPayCache' then (1) mod_authn_socache would erase it's cache entry for
the user, and (2) mod_authn_socache pass on the authentication, just as it
would if the user wasn't in cache. So even if some ridiculous user chose that
as their password, the site would still work for them, though without caching.

Site administrators would have to train their user deletion and password change
programs to hit the website with a request with the username and special
password, but that's not hard.

Lots of other mechanisms could be used, and probably one can think of some that
are more graceful than this one (though probably not one that's easier to
implement) but I really think you would double the practical value of the
module if some such mechanism were available.

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message