From 4eec79babf96971224a41704a8321a7f0167d82f Mon Sep 17 00:00:00 2001
From: Lucien Gentis Maintient un cache des données d'authentification pour limiter
- les sollicitations du serveur d'arrière-plan. Maintient un cache des données d'authentification pour limiter
+ les sollicitations du serveur d'arrière-plan. Certains utilisateurs qui mettent oeuvre une authentification
- lourde s'appuyant par exemple sur des requêtes SQL
- ( Pour résoudre ce problème, mod_authn_socache fournit une solution
- qui permet de maintenir un cache des données d'authentification.
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 (
Les principales règles à appliquer pour la mise en cache sont :
+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 (
Les principales règles à appliquer pour la mise en cache sont :
Voici un exemple simple permettant d'accélérer +
Voici un exemple simple permettant d'accélérer
Les développeurs de modules doivent savoir que la mise en cache - avec mod_authn_socache doit être activée dans leurs modules. La +
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 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 + >r957072, où trois fournisseurs authn sont activés pour la mise en cache.
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 httpd.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 +
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 httpd.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.
+ d'être sûr que la mise en cache a bien été activée et pourra + donc être utilisée dans les fichiers .htaccess.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 +
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.
+ "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.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 +
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
Par exemple, pour mettre en cache les données d'authentification
+ trouvées par
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 ; - une durée de vie plus longue peut être paramétrée 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 +
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 ; + une durée de vie plus longue peut être paramétrée 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 + 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.
+ définissez la durée de vie.Cette directive permet de spécifier une chaîne à utiliser avec le +
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 + 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 +
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, +
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 + 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 + 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.
Cette directive permet de définir si ce module mesure le délai
diff --git a/docs/manual/mod/mod_ssl.xml.fr b/docs/manual/mod/mod_ssl.xml.fr
index ec52ca5a9c..42066dc720 100644
--- a/docs/manual/mod/mod_ssl.xml.fr
+++ b/docs/manual/mod/mod_ssl.xml.fr
@@ -1,7 +1,7 @@
-
+
@@ -1973,7 +1973,6 @@ SSLStrictSNIVHostCheck on
le mandataire doit utiliser
@@ -2004,7 +2003,6 @@ SSLProxyMachineCertificatePath "/usr/local/apache2/conf/proxy.crt/"
clients codés en PEM que le mandataire doit utiliser
@@ -2036,7 +2034,6 @@ SSLProxyMachineCertificateFile
mandataire de choisir un certificat
--
2.40.0