From: Christophe Jaillet Date: Sun, 18 Aug 2019 18:29:09 +0000 (+0000) Subject: s/cacheing/caching/ X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=56d493e8f42b668d2ed9418ce888e90aad8fa23e;p=apache s/cacheing/caching/ Improve layout. Add some missing tags. Add some missing tags. Add some missing links Add the name of the directive in , so that 'quickreference.html' is generated correctly. In the AuthnCacheContext directive, fix the way 'directory' and 'server' are displayed. They are key-words and should not be in italic. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1865402 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/mod_authn_socache.xml b/docs/manual/mod/mod_authn_socache.xml index d47cdc1bc2..76043fe576 100644 --- a/docs/manual/mod/mod_authn_socache.xml +++ b/docs/manual/mod/mod_authn_socache.xml @@ -35,7 +35,7 @@ the load on backends lookup is not required for every authenticated request.

-
Authentication Cacheing +
Authentication Caching

Some users of more heavyweight authentication such as SQL database lookups (mod_authn_dbd) have reported it putting an unacceptable load on their authentication provider. A typical case @@ -43,7 +43,7 @@ the load on backends (images, scripts, stylesheets, media, etc), and a request to the page generates hundreds of effectively-immediate requests for authenticated additional contents.

-

mod_authn_socache provides a solution to this problem by +

mod_authn_socache provides a solution to this problem by maintaining a cache of authentication credentials.

@@ -53,17 +53,18 @@ the load on backends network. Authentication by file (mod_authn_file) or dbm (mod_authn_dbm) are unlikely to benefit, as these are fast and lightweight in their own right (though in some - cases, such as a network-mounted file, cacheing may be worthwhile). + cases, such as a network-mounted file, caching may be worthwhile). Other providers such as SQL or LDAP based authentication are more likely to benefit, particularly where there is an observed performance issue. Amongst the standard modules, mod_authnz_ldap manages its own cache, so only mod_authn_dbd will usually benefit from this cache.

The basic rules to cache for a provider are:

-
  1. Include the provider you're cacheing for in an - AuthnCacheProvideFor directive.
    2. +
    1. Include the provider you're caching for in an + AuthnCacheProvideFor directive.
    2. List socache ahead of the provider you're - cacheing for in your AuthBasicProvider or AuthDigestProvider directive.
    @@ -85,14 +86,14 @@ AuthnCacheSOCache dbm
-
Cacheing with custom modules +
Caching with custom modules

Module developers should note that their modules must be enabled - for cacheing with mod_authn_socache. A single optional API function + for caching with mod_authn_socache. A single optional API function ap_authn_cache_store is provided to cache credentials a provider has just looked up or generated. Usage examples are available in r957072, in which three authn providers are enabled for cacheing.

+ >r957072, in which three authn providers are enabled for caching.

@@ -103,7 +104,7 @@ AuthnCacheSOCache dbm

This directive is not normally necessary: it is implied if - authentication cacheing is enabled anywhere in httpd.conf. + authentication caching is enabled anywhere in httpd.conf. However, if it is not enabled anywhere in httpd.conf it will by default not be initialised, and is therefore not available in a .htaccess context. This directive @@ -140,7 +141,7 @@ Apache HTTP Server 2.4.7 and later

This directive specifies an authentication provider or providers to cache for. Credentials found by a provider not listed in an - AuthnCacheProvideFor directive will not be cached.

+ AuthnCacheProvideFor directive will not be cached.

For example, to cache credentials found by mod_authn_dbd or by a custom provider myprovider, but leave those looked @@ -155,13 +156,13 @@ AuthnCacheProvideFor dbd myprovider AuthnCacheTimeout Set a timeout for cache entries AuthnCacheTimeout timeout (seconds) -300 (5 minutes) +AuthnCacheTimeout 300 (5 minutes) directory.htaccess AuthConfig -

Cacheing authentication data can be a security issue, though short-term - cacheing is unlikely to be a problem. Typically a good solution is to +

Caching authentication data can be a security issue, though short-term + caching is unlikely to be a problem. Typically a good solution is to cache credentials for as long as it takes to relieve the load on a backend, but no longer, though if changes to your users and passwords are infrequent then a longer timeout may suit you. The default 300 @@ -178,8 +179,8 @@ AuthnCacheProvideFor dbd myprovider AuthnCacheContext Specify a context string for use in the cache key -AuthnCacheContext directory|server|custom-string -directory +AuthnCacheContext directory|server|custom-string +AuthnCacheContext directory directory @@ -187,10 +188,10 @@ AuthnCacheProvideFor dbd myprovider username (and realm in the case of Digest Authentication) in constructing a cache key. This serves to disambiguate identical usernames serving different authentication areas on the server.

-

Two special values for this are directory, which uses - the directory context of the request as a string, and server +

Two special values for this are directory, which uses + the directory context of the request as a string, and server which uses the virtual host name.

-

The default is directory, which is also the most +

The default is directory, which is also the most conservative setting. This is likely to be less than optimal, as it (for example) causes $app-base, $app-base/images, $app-base/scripts and $app-base/media each to