<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1477094:1514214 (outdated) -->
+<!-- English Revision : 1514214 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
réserve un thread par connexion. Tous les modules fournis
avec le serveur sont compatibles avec le MPM event.</p>
+ <p>Une restriction similaire existe pour les requêtes qui utilisent
+ un filtre en sortie qui doit lire et/ou modifier l'ensemble du corps
+ de réponse, comme dans le cas de mod_ssl, mod_deflate, ou
+ mod_include. Si la connexion avec le client se bloque pendant que le
+ filtre traite les données, et si la quantité de données générée par
+ ce filtre est trop importante pour être mise en tampon mémoire, le
+ thread utilisé pour la requête n'est pas libéré pendant que httpd
+ attend que toutes les données restantes aient été transmises au
+ client.</p>
+
<p>Le MPM présuppose que l'implémentation <code>apr_pollset</code>
sous-jacente est raisonnablement sûre du point de vue des threads.
Ceci permet au MPM d'éviter un verrouillage de haut niveau excessif,
<?xml version="1.0"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1468581:1514064 (outdated) -->
+<!-- English Revision : 1514064 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
</usage>
</directivesynopsis>
+<directivesynopsis>
+<name>AuthBasicUseDigestAlgorithm</name>
+<description>Vérifie les mots de passe auprès des fournisseurs
+d'authentification à la manière de l'authentification de type Digest.
+</description>
+<syntax>AuthBasicUseDigestAlgorithm MD5|Off</syntax>
+<default>AuthBasicUseDigestAlgorithm Off</default>
+<contextlist><context>directory</context><context>.htaccess</context>
+</contextlist>
+<override>AuthConfig</override>
+
+<usage>
+ <p>Normalement, lorsqu'on utilise l'authentification basique, les
+ fournisseurs spécifiés via la directive <directive
+ module="mod_auth_basic">AuthBasicProvider</directive> tentent de
+ contrôler l'identité d'un utilisateur en recherchant dans leurs
+ bases de données l'existence d'un couple utilisateur/mot de passe
+ correspondant. Les mots de passe enregistrés sont en général
+ chiffrés, mais ce n'est pas systématique ; chaque fournisseur peut
+ choisir son propre mode de stockage des mots de passe.</p>
+
+ <p>Lorsqu'on utilise l'authentification de type Digest, les
+ fournisseurs spécifiés par la directive <directive
+ module="mod_auth_digest">AuthDigestProvider</directive> effectuent
+ une recherche similaire dans leurs bases de
+ données pour trouver un couple utilisateur/mot de passe
+ correspondant. Cependant, à la différence de l'authentification
+ basique, les données associées à chaque utilisateur et comportant le
+ nom d'utilisateur, le domaine de protection (realm) et le mot de
+ passe doivent être contenues dans une chaîne chiffrée (Voir le
+ document <a
+ href="http://tools.ietf.org/html/rfc2617#section-3.2.2.2">RFC 2617,
+ Section 3.2.2.2</a> pour plus de détails à propos du type de
+ chiffrement utilisé pour cette chaîne).</p>
+
+ <p>A cause de la différence entre les méthodes de stockage des
+ données des authentifications de type basique et digest, le passage
+ d'une méthode d'authentification de type digest à une méthode
+ d'authentification de type basique requiert l'attribution de
+ nouveaux
+ mots de passe à chaque utilisateur, car leur mots de passe existant
+ ne peut pas être extrait à partir du schéma de stockage utilisé
+ par les fournisseurs d'authentification de type digest.</p>
+
+ <p>Si la directive <directive
+ module="mod_auth_basic">AuthBasicUseDigestAlgorithm</directive> est
+ définie à la valeur <code>MD5</code>, le mot de passe d'un
+ utilisateur dans le cas de l'authentification basique sera vérifié
+ en utilisant le même format de chiffrement que dans le cas de
+ l'authentification de type digest. Tout d'abord, une chaîne
+ comportant le nom d'utilisateur, le domaine de protection (realm) et
+ le mot de passe est générée sous forme de condensé (hash) en
+ utilisant l'algorithme MD5 ; puis le nom d'utilisateur et cette
+ chaîne chiffrée sont transmis aux fournisseurs spécifiés via la
+ directive <directive
+ module="mod_auth_basic">AuthBasicProvider</directive> comme si la
+ directive <directive module="mod_authn_core">AuthType</directive>
+ était définie à <code>Digest</code> et si l'authentification de type
+ Digest était utilisée.
+ </p>
+
+ <p>Grâce à cette directive, un site peut basculer d'une
+ authentification de type digest à basique sans devoir changer les
+ mots de passe des utilisateurs. </p>
+
+ <note>
+ Le processus inverse consistant à passer d'une authentification de
+ type basique à digest sans changer les mots de passe n'est en
+ général pas possible. Les mots de passe enregistrés dans le cas
+ d'une authentification de type basique ne pourront être extraits
+ et chiffrés à nouveau selon le schéma de l'authentification de
+ type digest, que s'ils ont été stockés en clair ou selon un schéma de
+ chiffrement réversible.
+ </note>
+
+ <note>
+ Seuls les fournisseurs qui supportent l'authentification de type
+ digest pourront authentifier les utilisateurs lorsque la directive
+ <directive
+ module="mod_auth_basic">AuthBasicUseDigestAlgorithm</directive>
+ est définie à <code>MD5</code>. L'utilisation d'un autre
+ fournisseur provoquera un message d'erreur et le client se verra
+ refuser l'accès.</note>
+</usage>
+</directivesynopsis>
</modulesynopsis>