You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Nick Kew <ni...@webthing.com> on 2010/06/17 00:29:34 UTC
mod_authn_cache
I thought we had a mod_authn_cache, but it seems it only exists in the
old 2.1 authn stuff at sourceforge!
Just thinking about hacking this up, and wondering how best to do it.
Basic shape seems straightforward enough:
1. Make it a provider like the standard mod_authn_****
2. Configure it ahead of anything heavyweight like dbd.
3. Export an optional function for other mod_authn_* modules to cache
credentials they've looked up.
4. Timestamp everything in cache, and provide a configurable timeout.
But how to implement the cache itself is less clear. The simplest solution
would be to hijack mod_authn_dbm and add a cacheing function and configuration.
But the new socache framework presents an alternative, and an option for users
of threaded MPMs to run a per-process cache would add value.
Thoughts?
--
Nick Kew
Re: mod_authn_cache
Posted by Issac Goldstand <ma...@beamartyr.net>.
I think I sent a patch to fix it up a year or so ago, when I needed it
for 2.2. You can see the fully working (live in production for 6 months
now, I think) code here.
http://sourceforge.net/tracker/download.php?group_id=93106&atid=603134&file_id=350405&aid=2895850
As mentioned there, I wanted this to work against 2.2, but for trunk I'd
have probably used socache instead of the static array used here.
Issac
On 6/17/2010 1:29 AM, Nick Kew wrote:
> I thought we had a mod_authn_cache, but it seems it only exists in the
> old 2.1 authn stuff at sourceforge!
>
> Just thinking about hacking this up, and wondering how best to do it.
> Basic shape seems straightforward enough:
>
> 1. Make it a provider like the standard mod_authn_****
> 2. Configure it ahead of anything heavyweight like dbd.
> 3. Export an optional function for other mod_authn_* modules to cache
> credentials they've looked up.
> 4. Timestamp everything in cache, and provide a configurable timeout.
>
> But how to implement the cache itself is less clear. The simplest solution
> would be to hijack mod_authn_dbm and add a cacheing function and configuration.
> But the new socache framework presents an alternative, and an option for users
> of threaded MPMs to run a per-process cache would add value.
>
> Thoughts?
>
>
ap_socache anomaly (Re: mod_authn_cache)
Posted by Nick Kew <ni...@webthing.com>.
On Thu, 17 Jun 2010 00:43:55 +0200
Graham Leggett <mi...@sharp.fm> wrote:
> mod_socache all the way.
Question on mod_socache usage: how to use create/init/destroy?
Create seems straightforward, but init/destroy are contradictory.
On the one hand, they are passed a server_rec, suggesting they're per-server.
On the other hand, the instance comes from "create", and the cname argument
suggests it should be per-module.
Grepping /trunk/ finds only the providers, no usage examples!
Looking at one of the providers, the server_rec seems only to be used
in ap_log_error.
Is it safe to assume the server_rec won't be used for anything more?
And why not take the apparent mismatch out of the API by using
ap_log_perror instead?
--
Nick Kew
Re: mod_authn_cache
Posted by Nick Kew <ni...@webthing.com>.
On 16 Jun 2010, at 23:43, Graham Leggett wrote:
> On 17 Jun 2010, at 12:29 AM, Nick Kew wrote:
>
>> But how to implement the cache itself is less clear. The simplest solution
>> would be to hijack mod_authn_dbm and add a cacheing function and configuration.
>> But the new socache framework presents an alternative, and an option for users
>> of threaded MPMs to run a per-process cache would add value.
>>
>> Thoughts?
>
> mod_socache all the way.
OK, done. It's called mod_authn_socache.
I'd still like to fix the socache API's ill-fitting use of the server_rec!
And I'm getting what looks like another bug: socache is returning an
incorrect status (20014 in the log) when the actual outcome is NOTFOUND.
I have yet to investigate that one.
--
Nick Kew
Re: mod_authn_cache
Posted by Graham Leggett <mi...@sharp.fm>.
On 17 Jun 2010, at 12:29 AM, Nick Kew wrote:
> But how to implement the cache itself is less clear. The simplest
> solution
> would be to hijack mod_authn_dbm and add a cacheing function and
> configuration.
> But the new socache framework presents an alternative, and an option
> for users
> of threaded MPMs to run a per-process cache would add value.
>
> Thoughts?
mod_socache all the way.
We've backported mod_socache and friends to v2.2, and are using to to
cache geoip and other lookups. It is a very cool API.
Regards,
Graham
--
Re: mod_authn_cache
Posted by Paul Querna <pa...@querna.org>.
On Wed, Jun 16, 2010 at 3:29 PM, Nick Kew <ni...@webthing.com> wrote:
> I thought we had a mod_authn_cache, but it seems it only exists in the
> old 2.1 authn stuff at sourceforge!
>
> Just thinking about hacking this up, and wondering how best to do it.
> Basic shape seems straightforward enough:
>
> 1. Make it a provider like the standard mod_authn_****
> 2. Configure it ahead of anything heavyweight like dbd.
> 3. Export an optional function for other mod_authn_* modules to cache
> credentials they've looked up.
> 4. Timestamp everything in cache, and provide a configurable timeout.
>
> But how to implement the cache itself is less clear. The simplest solution
> would be to hijack mod_authn_dbm and add a cacheing function and configuration.
> But the new socache framework presents an alternative, and an option for users
> of threaded MPMs to run a per-process cache would add value.
>
> Thoughts?
You can take the mod_authn_cache from SF as a baseline; its mine, I'm
happy to donate it to the ASF.
I would suggest just using mod_authn_cache, rippng out its own caching
stuff, and using mod_socache.