Serveur Apache HTTP Version 2.4
Serveur Apache HTTP Version 2.4
| Description: | G�re un cache des donn�es d'authentification pour diminuer la charge des serveurs d'arri�re-plan |
|---|---|
| Statut: | Base |
| Identificateur�de�Module: | authn_socache_module |
| Fichier�Source: | mod_authn_socache.c |
| Compatibilit�: | Versions 2.3 et ult�rieures |
Maintient un cache des donn�es d'authentification afin que la recherche d'un nouveau serveur d'arri�re-plan pour chaque requ�te authentifi�e ne soit plus n�cessaire.
Certains utilisateurs qui mettent oeuvre une authentification
lourde s'appuyant par exemple sur des requ�tes SQL
(mod_authn_dbd) ont signal� une charge induite
inacceptable sur leur fournisseur d'authentification. Cela se
produit typiquement dans le cas o� une page HTML contient des
centaines d'objets (images, scripts, pages de styles, media,
etc...), et o� une requ�te pour cette page g�n�re des centaines de
sous-requ�tes � effet imm�diat pour des contenus suppl�mentaires
authentifi�s.
Pour r�soudre ce probl�me, mod_authn_socache fournit une solution qui permet de maintenir un cache des donn�es d'authentification.
Le cache d'authentification doit �tre utilis� lorsque les
requ�tes d'authentification induisent une charge significative sur le
serveur, le serveur d'arri�re-plan ou le r�seau. Cette mise en cache
n'apportera probablement aucune am�lioration dans le cas d'une
authentification � base de fichier (mod_authn_file)
ou de base de donn�es dbm (mod_authn_dbm) car ces
m�thodes sont de par leur conception rapides et l�g�res (la mise en
cache peut cependant s'av�rer utile dans le cas o� le fichier est
situ� sur un montage r�seau). Les fournisseurs d'authentification
bas�s sur SQL ou LDAP ont plus de chances de tirer parti de cette
mise en cache, en particulier lorsqu'un probl�me de performances est
d�tect�. mod_authnz_ldap g�rant son propre cache,
seul mod_authn_dbd est concern� par notre sujet.
Les principales r�gles � appliquer pour la mise en cache sont :
AuthnCacheProvideFor.AuthBasicProvider
ou AuthDigestProvider.Voici un exemple simple permettant d'acc�l�rer
mod_authn_dbd et utilisant dbm comme moteur de la
mise en cache :
<Directory /usr/www/myhost/private>
AuthType Basic
AuthName "Cached Authentication Example"
AuthBasicProvider socache dbd
AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
AuthnCacheProvideFor dbd
AuthnCacheContext dbd-authn-example
AuthnCacheSOCache dbm
Require valid-user
</Directory>
Les d�veloppeurs de modules doivent savoir que la mise en cache avec mod_authn_socache doit �tre activ�e dans leurs modules. La fonction simple de l'API ap_authn_cache_store permet de mettre en cache les donn�es d'authentification qu'un fournisseur vient de rechercher ou de g�n�rer. Vous trouverez des exemples d'utilisation � r957072, o� trois fournisseurs authn sont activ�s pour la mise en cache.
| Description: | Sp�cifie une cha�ne de contexte � utiliser dans la cl� du cache |
|---|---|
| Syntaxe: | AuthnCacheContext directory|server|cha�ne-personnalis�e |
| D�faut: | directory |
| Contexte: | r�pertoire |
| Statut: | Base |
| Module: | mod_authn_socache |
Cette directive permet de sp�cifier une cha�ne � utiliser avec le nom d'utilisateur fourni (et le domaine d'authentification - realm - dans le cas d'une authentification � base de condens�s) lors de la construction d'une cl� de cache. Ceci permet de lever l'ambigu�t� entre plusieurs noms d'utilisateurs identiques servant diff�rentes zones d'authentification sur le serveur.
Il y a deux valeurs sp�ciales pour le param�tre : directory, qui utilise le contexte de r�pertoire de la requ�te comme cha�ne, et server, qui utilise le nom du serveur virtuel.
La valeur par d�faut est directory, qui est aussi la d�finition la plus courante. Ceci est cependant loin d'�tre optimal, car par exemple, $app-base, $app-base/images, $app-base/scripts et $app-base/media poss�deront chacun leur propre cl� de cache. Il est pr�f�rable d'utiliser le fournisseur de mot de passe : par exemple un fichier htpasswd ou une table de base de donn�es.
Les contextes peuvent �tre partag�s entre diff�rentes zones du serveur, o� les donn�es d'authentification sont partag�es. Ceci est cependant susceptible de cr�er des trous de s�curit� de type cross-site ou cross-application, et cette directive n'est donc pas disponible dans les contextes .htaccess.
| Description: | Active la mise en cache de l'authentification en tout endroit |
|---|---|
| Syntaxe: | AuthnCacheEnable |
| Contexte: | configuration du serveur |
| AllowOverride: | None |
| Statut: | Base |
| Module: | mod_authn_socache |
Normalement, cette directive n'est pas n�cessaire : l'activation est implicite si la mise en cache de l'authentification a �t� activ�e en tout autre endroit du fichier apache2.conf. Par contre, si cette mise en cache n'a pas �t� activ�e, par d�faut, elle ne sera pas initialis�e, et ne sera donc pas disponible dans un contexte de fichier .htaccess. Cette directive permet d'�tre s�r que la mise en cache a bien �t� activ�e et pourra donc �tre utilis�e dans les fichiers .htaccess.
| Description: | Sp�cifie le fournisseur pour lequel on veut effectuer une mise en cache |
|---|---|
| Syntaxe: | AuthnCacheProvideFor fournisseur-authn [...] |
| D�faut: | None |
| Contexte: | r�pertoire, .htaccess |
| AllowOverride: | AuthConfig |
| Statut: | Base |
| Module: | mod_authn_socache |
Cette directive permet de sp�cifier un ou plusieurs fournisseurs pour le(s)quel(s) on veut effectuer une mise en cache. Les donn�es d'authentification trouv�es par un fournisseur non sp�cifi� dans une directive AuthnCacheProvideFor ne seront pas mises en cache.
Par exemple, pour mettre en cache les donn�es d'authentification
trouv�es par mod_authn_dbd ou par un fournisseur
personnalis� mon-fournisseur, et ne pas mettre en cache
celles trouv�es par les fournisseurs l�gers comme file ou dbm :
AuthnCacheProvideFor dbd mon-fournisseur
| Description: | S�lectionne le fournisseur socache d'arri�re-plan � utiliser |
|---|---|
| Syntaxe: | AuthnCacheSOCache nom-fournisseur[:arguments-fournisseur] |
| Contexte: | configuration du serveur |
| AllowOverride: | None |
| Statut: | Base |
| Module: | mod_authn_socache |
| Compatibilit�: | Les param�tres optionnels du fournisseur sont disponibles depuis la version 2.4.7 du serveur HTTP Apache |
Cette d�finition s'applique � l'ensemble du serveur et permet de s�lectionner un fournisseur pour le cache d'objets partag�s, ainsi que des arguments �ventuels pour ce fournisseur. Les fournisseurs disponibles sont, entre autres, "dbm", "dc", "memcache", ou "shmcb", chacun d'entre eux n�cessitant le chargement du module appropri�. Si elle est absente, c'est la valeur par d�faut pour votre plate-forme qui sera utilis�e.
| Description: | D�finit une dur�e de vie pour les entr�es du cache |
|---|---|
| Syntaxe: | AuthnCacheTimeout dur�e-de-vie (secondes) |
| D�faut: | 300 (5 minutes) |
| Contexte: | r�pertoire, .htaccess |
| AllowOverride: | AuthConfig |
| Statut: | Base |
| Module: | mod_authn_socache |
La mise en cache des donn�es d'authentification peut constituer un trou de s�curit�, bien qu'un mise en cache de courte dur�e ne posera probablement pas de probl�me. En g�n�ral, il est conseill� de conserver les entr�es du cache de fa�on � ce que la charge du serveur d'arri�re-plan reste normale, mais pas plus longtemps, bien qu'une dur�e de vie plus longue puisse �tre n�cessaire si les changements d'utilisateurs et de mots de passe sont peu fr�quents. La dur�e de vie par d�faut de 300 secondes (5 minutes) est � la fois raisonnable et suffisamment importante pour r�duire la charge d'un serveur d'arri�re-plan comme dbd (requ�tes SQL).
Cette dur�e de vie ne doit pas �tre confondue avec la dur�e de vie de session qui est un tout autre sujet. Cependant, vous devez utiliser votre logiciel de gestion de session pour v�rifier si les donn�es d'authentification mises en cache peuvent allonger accidentellement une session, et en tenir compte lorsque vous d�finissez la dur�e de vie.