From: Lucien Gentis Date: Sat, 17 Aug 2013 16:17:16 +0000 (+0000) Subject: Updates. X-Git-Tag: 2.5.0-alpha~5181 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=168c1b87089e16007387cfab94ae2469e73aa6d6;p=apache Updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1515008 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/mod/event.xml.fr b/docs/manual/mod/event.xml.fr index 5f835f0253..d84c510456 100644 --- a/docs/manual/mod/event.xml.fr +++ b/docs/manual/mod/event.xml.fr @@ -1,7 +1,7 @@ - + @@ -75,6 +75,16 @@ mobiliser des threads que pour les connexions en cours de traitement +

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.

+

Le MPM présuppose que l'implémentation apr_pollset sous-jacente est raisonnablement sûre du point de vue des threads. Ceci permet au MPM d'éviter un verrouillage de haut niveau excessif, diff --git a/docs/manual/mod/mod_auth_basic.xml.fr b/docs/manual/mod/mod_auth_basic.xml.fr index 26d940d8cd..a393acaff0 100644 --- a/docs/manual/mod/mod_auth_basic.xml.fr +++ b/docs/manual/mod/mod_auth_basic.xml.fr @@ -1,7 +1,7 @@ - + @@ -198,5 +198,90 @@ d'utilisateur et mot de passe fournis + +AuthBasicUseDigestAlgorithm +Vérifie les mots de passe auprès des fournisseurs +d'authentification à la manière de l'authentification de type Digest. + +AuthBasicUseDigestAlgorithm MD5|Off +AuthBasicUseDigestAlgorithm Off +directory.htaccess + +AuthConfig + + +

Normalement, lorsqu'on utilise l'authentification basique, les + fournisseurs spécifiés via la directive AuthBasicProvider 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.

+ +

Lorsqu'on utilise l'authentification de type Digest, les + fournisseurs spécifiés par la directive AuthDigestProvider 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 RFC 2617, + Section 3.2.2.2 pour plus de détails à propos du type de + chiffrement utilisé pour cette chaîne).

+ +

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.

+ +

Si la directive AuthBasicUseDigestAlgorithm est + définie à la valeur MD5, 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 AuthBasicProvider comme si la + directive AuthType + était définie à Digest et si l'authentification de type + Digest était utilisée. +

+ +

Grâce à cette directive, un site peut basculer d'une + authentification de type digest à basique sans devoir changer les + mots de passe des utilisateurs.

+ + + 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. + + + + Seuls les fournisseurs qui supportent l'authentification de type + digest pourront authentifier les utilisateurs lorsque la directive + AuthBasicUseDigestAlgorithm + est définie à MD5. L'utilisation d'un autre + fournisseur provoquera un message d'erreur et le client se verra + refuser l'accès. + + diff --git a/docs/manual/upgrading.xml.fr b/docs/manual/upgrading.xml.fr index 680e6632cd..defd9794b3 100644 --- a/docs/manual/upgrading.xml.fr +++ b/docs/manual/upgrading.xml.fr @@ -3,7 +3,7 @@ - +