https://issues.apache.org/bugzilla/show_bug.cgi?id=51994

--- Comment #2 from Jan Wolter <[email protected]> 2011-10-07 18:19:15 UTC ---
Yes, it's documented, so this an enhancement request, not a bug request.

Without a cache flush you put administrators into the tricky position of having
to decide between long timeouts for performance and short timeouts so password
changes and account deletions happen smoothly. That dilemma is a false one,
arising out of an weakness in the software design. Good caches are flushable.

Yeah, server restart probably works for some back-ends, at least. Kind of
extreme. If they are using a dbd file it might not be hard to write a separate
program that erases it. With more work, they could probably even do that with
shared memory. But if that's the way to go, then do we expect every
administrator to write their own? They might be able to do something with
setting the cache timeout temporarily to zero, hitting the page with the user
ID and a random bad password, and setting it back again. No,that won't work -
looks like changing the timeout won't effect the timeout of things already in
the cache. I can't say any of these solutions are elegant.

I don't know. I think this is going to be a common enough concern with users of
mod_authn_socache that a reasonably clean and graceful way of handling it ought
to be part of the design. It's worth at least making the attempt to come up
with a smart solution to the problem.

Maybe it'd be good enough to have authn_cache_store() modified so that if you
pass it a NULL for the data argument it removes that user from the cache. Then
third-party modules could be written that do cache flushes. The scheme I
described in my original post could totally be a separate module, listed before
socache on the AuthBasicProvider directive, if only it had a way to ask
mod_authn_socache to flush a cache entry.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to