-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1673932:1738331 (outdated) -->
+<!-- English Revision: 1738331 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviwed by : Vincent Deffontaines -->
<title>Authentification et autorisation</title>
<summary>
- <p>L'authentification est un processus qui vous permet de vérifier
- qu'une personne est bien celle qu'elle prétend être. L'autorisation
- est un processus qui permet à une personne d'aller là où elle veut
- aller, ou d'obtenir les informations qu'elle désire.</p>
+ <p>L'authentification est un processus qui vous permet de vérifier
+ qu'une personne est bien celle qu'elle prétend être. L'autorisation
+ est un processus qui permet à une personne d'aller là où elle veut
+ aller, ou d'obtenir les informations qu'elle désire.</p>
- <p>Pour le contr
ôle d'accès en général, voir le How-To <a
- href="access.html">Contrôle d'accès</a>.</p>
+ <p>Pour le contr
ôle d'accès en général, voir le How-To <a
+ href="access.html">Contrôle d'accès</a>.</p>
</summary>
-<section id="related"><title>Modules et directives concernés</title>
+<section id="related"><title>Modules et directives concernés</title>
-<p>Trois groupes de modules sont concernés par le processus
+<p>Trois groupes de modules sont concernés par le processus
d'authentification et d'autorisation. Vous devrez utiliser au moins un
module de chaque groupe.</p>
</ul>
<p>On peut aussi ajouter <module>mod_authn_core</module> et
- <module>mod_authz_core</module>. Ces modules implémentent des
- directives générales qui opèrent au dessus de tous les modules
+ <module>mod_authz_core</module>. Ces modules implémentent des
+ directives générales qui opèrent au dessus de tous les modules
d'authentification.</p>
<p>Le module <module>mod_authnz_ldap</module> est un fournisseur
d'authentification et d'autorisation. Le module
<module>mod_authz_host</module> fournit une autorisation et un
- contrôle d'accès basés sur le nom du serveur, l'adresse IP ou
- certaines caractéristiques de la requête, mais ne fait pas partie du
- système fournisseur d'authentification. Le module
- <module>mod_access_compat</module> a été créé à des fins de
- compatibilité ascendante avec mod_access.</p>
+ contrôle d'accès basés sur le nom du serveur, l'adresse IP ou
+ certaines caractéristiques de la requête, mais ne fait pas partie du
+ système fournisseur d'authentification. Le module
+ <module>mod_access_compat</module> a été créé à des fins de
+ compatibilité ascendante avec mod_access.</p>
<p>Vous devriez aussi jeter un coup d'oeil au manuel de recettes de <a
- href="access.html">Contrôle d'accès</a>, qui décrit les différentes
- méthodes de contrôle d'accès à votre serveur.</p>
+ href="access.html">Contrôle d'accès</a>, qui décrit les différentes
+ méthodes de contrôle d'accès à votre serveur.</p>
</section>
<section id="introduction"><title>Introduction</title>
<p>Si votre site web contient des informations sensibles ou
- destinées seulement à un groupe de personnes restreint, les
- techniques exposées dans cet article vont vous aider à vous assurer
- que les personnes qui ont accès à ces pages sont bien celles
- auxquelles vous avez donné l'autorisation d'accès.</p>
+ destinées seulement à un groupe de personnes restreint, les
+ techniques exposées dans cet article vont vous aider à vous assurer
+ que les personnes qui ont accès à ces pages sont bien celles
+ auxquelles vous avez donné l'autorisation d'accès.</p>
- <p>Cet article décrit les méthodes "standards" de protection de
- parties de votre site web que la plupart d'entre vous sont appelés à
+ <p>Cet article décrit les méthodes "standards" de protection de
+ parties de votre site web que la plupart d'entre vous sont appelés à
utiliser.</p>
<note><title>Note :</title>
- <p>Si vos données ont un réel besoin de sécurisation, prévoyez
- l'utilisation de <module>mod_ssl</module> en plus de toute méthode
+ <p>Si vos données ont un réel besoin de sécurisation, prévoyez
+ l'utilisation de <module>mod_ssl</module> en plus de toute méthode
d'authentification.</p>
</note>
</section>
-<section id="theprerequisites"><title>Les prérequis</title>
- <p>Les directives décrites dans cet article devront être insérées
+<section id="theprerequisites"><title>Les prérequis</title>
+ <p>Les directives décrites dans cet article devront être insérées
soit au niveau de la configuration de votre serveur principal (en
- général dans une section <directive module="core"
+ général dans une section <directive module="core"
type="section">Directory</directive>), soit au niveau de la
- configuration des répertoires (fichiers <code>.htaccess</code>)</p>
+ configuration des répertoires (fichiers <code>.htaccess</code>)</p>
<p>Si vous envisagez l'utilisation de fichiers
<code>.htaccess</code>, la configuration de votre serveur devra
permettre l'ajout de directives d'authentification dans ces
fichiers. Pour ce faire, on utilise la directive <directive
- module="core">AllowOverride</directive>, qui spécifie quelles
- directives pourront éventuellement contenir les fichiers de
- configuration de niveau répertoire.</p>
+ module="core">AllowOverride</directive>, qui spécifie quelles
+ directives pourront éventuellement contenir les fichiers de
+ configuration de niveau répertoire.</p>
<p>Comme il est ici question d'authentification, vous aurez besoin
d'une directive <directive module="core">AllowOverride</directive>
<p>Si vous avez l'intention d'ajouter les directives directement
dans le fichier de configuration principal, vous devrez bien entendu
- posséder les droits en écriture sur ce fichier.</p>
+ posséder les droits en écriture sur ce fichier.</p>
- <p>Vous devrez aussi connaître un tant soit peu la structure des
- répertoires de votre serveur, ne serait-ce que pour savoir où se
- trouvent certains fichiers. Cela ne devrait pas présenter de grandes
- difficultés, et nous essaierons de clarifier tout ça lorsque le besoin
+ <p>Vous devrez aussi connaître un tant soit peu la structure des
+ répertoires de votre serveur, ne serait-ce que pour savoir où se
+ trouvent certains fichiers. Cela ne devrait pas présenter de grandes
+ difficultés, et nous essaierons de clarifier tout ça lorsque le besoin
s'en fera sentir.</p>
<p>Enfin, vous devrez vous assurer que les modules
<module>mod_authn_core</module> et <module>mod_authz_core</module>
- ont été soit compilés avec le binaire httpd, soit chargés par le
+ ont été soit compilés avec le binaire httpd, soit chargés par le
fichier de configuration httpd.conf. Ces deux modules fournissent
- des directives générales et des fonctionnalités qui sont critiques
- quant à la configuration et l'utilisation de l'authentification et
+ des directives générales et des fonctionnalités qui sont critiques
+ quant à la configuration et l'utilisation de l'authentification et
de l'autorisation au sein du serveur web.</p>
</section>
<section id="gettingitworking"><title>Mise en oeuvre</title>
- <p>Nous décrivons ici les bases de la protection par mot de passe
- d'un répertoire de votre serveur.</p>
+ <p>Nous décrivons ici les bases de la protection par mot de passe
+ d'un répertoire de votre serveur.</p>
- <p>Vous devez en premier lieu créer un fichier de mots de passe. La
- méthode exacte selon laquelle vous allez créer ce fichier va varier
+ <p>Vous devez en premier lieu créer un fichier de mots de passe. La
+ méthode exacte selon laquelle vous allez créer ce fichier va varier
en fonction du fournisseur d'authentification choisi. Mais nous
- entrerons dans les détails plus loin, et pour le moment, nous nous
+ entrerons dans les détails plus loin, et pour le moment, nous nous
contenterons d'un fichier de mots de passe en mode texte.</p>
- <p>Ce fichier doit être enregistré à un endroit non accessible
- depuis le web, de façon à ce que les clients ne puissent pas le
- télécharger. Par exemple, si vos documents sont servis à partir de
+ <p>Ce fichier doit être enregistré à un endroit non accessible
+ depuis le web, de façon à ce que les clients ne puissent pas le
+ télécharger. Par exemple, si vos documents sont servis à partir de
<code>/usr/local/apache/htdocs</code>, vous pouvez enregistrer le
fichier des mots de passe dans
<code>/usr/local/apache/passwd</code>.</p>
<p>L'utilitaire <program>htpasswd</program> fourni avec Apache
- permet de créer ce fichier. Vous le trouverez dans le répertoire
+ permet de créer ce fichier. Vous le trouverez dans le répertoire
<code>bin</code> de votre installation d'Apache. Si vous avez
- installé Apache à partir d'un paquetage tiers, il sera probablement
- dans le chemin par défaut de vos exécutables.</p>
+ installé Apache à partir d'un paquetage tiers, il sera probablement
+ dans le chemin par défaut de vos exécutables.</p>
- <p>Pour créer le fichier, tapez :</p>
+ <p>Pour créer le fichier, tapez :</p>
<example>
htpasswd -c /usr/local/apache/passwd/passwords rbowen
</example>
<p>Si <program>htpasswd</program> n'est pas dans le chemin par
- défaut de vos exécutables, vous devrez bien entendu entrer le chemin
- complet du fichier. Dans le cas d'une installation par défaut, il se
- trouve à <code>/usr/local/apache2/bin/htpasswd</code>.</p>
+ défaut de vos exécutables, vous devrez bien entendu entrer le chemin
+ complet du fichier. Dans le cas d'une installation par défaut, il se
+ trouve à <code>/usr/local/apache2/bin/htpasswd</code>.</p>
- <p>Ensuite, vous allez devoir configurer le serveur de façon à ce
- qu'il demande un mot de passe et lui préciser quels utilisateurs ont
- l'autorisation d'accès. Pour ce faire, vous pouvez soit éditer le
+ <p>Ensuite, vous allez devoir configurer le serveur de façon à ce
+ qu'il demande un mot de passe et lui préciser quels utilisateurs ont
+ l'autorisation d'accès. Pour ce faire, vous pouvez soit éditer le
fichier <code>httpd.conf</code>, soit utiliser un fichier
- <code>.htaccess</code>. Par exemple, si vous voulez protéger le
- répertoire <code>/usr/local/apache/htdocs/secret</code>, vous pouvez
+ <code>.htaccess</code>. Par exemple, si vous voulez protéger le
+ répertoire <code>/usr/local/apache/htdocs/secret</code>, vous pouvez
utiliser les directives suivantes, soit dans le fichier
<code>/usr/local/apache/htdocs/secret/.htaccess</code>, soit dans le
- fichier <code>httpd.conf</code> à l'intérieur d'une section <Directory
+ fichier <code>httpd.conf</code> à l'intérieur d'une section <Directory
"/usr/local/apache/htdocs/secret"> :</p>
<highlight language="config">
Require user rbowen
</highlight>
- <p>Examinons ces directives une à une. La directive <directive
- module="mod_authn_core">AuthType</directive> définit la méthode
- utilisée pour authentifier l'utilisateur. La méthode la plus
- courante est <code>Basic</code>, et elle est implémentée par
- <module>mod_auth_basic</module>. Il faut cependant garder à l'esprit
+ <p>Examinons ces directives une à une. La directive <directive
+ module="mod_authn_core">AuthType</directive> définit la méthode
+ utilisée pour authentifier l'utilisateur. La méthode la plus
+ courante est <code>Basic</code>, et elle est implémentée par
+ <module>mod_auth_basic</module>. Il faut cependant garder à l'esprit
que l'authentification Basic transmet le mot de passe depuis le
- client vers le serveur en clair. Cette méthode ne devra donc pas
- être utilisée pour la transmission de données hautement sensibles si
- elle n'est pas associée au module <module>mod_ssl</module>. Apache
- supporte une autre méthode d'authentification : <code>AuthType
- Digest</code>. Cette méthode est implémentée
- par le module <module>mod_auth_digest</module> et a été conçue pour
- améliorer la sécurité. Ce but n'a cependant pas été atteint et il est préférable
+ client vers le serveur en clair. Cette méthode ne devra donc pas
+ être utilisée pour la transmission de données hautement sensibles si
+ elle n'est pas associée au module <module>mod_ssl</module>. Apache
+ supporte une autre méthode d'authentification : <code>AuthType
+ Digest</code>. Cette méthode est implémentée
+ par le module <module>mod_auth_digest</module> et a été conçue pour
+ améliorer la sécurité. Ce but n'a cependant pas été atteint et il est préférable
de chiffrer la connexion avec <module>mod_ssl</module>.</p>
<p>La directive <directive
- module="mod_authn_core">AuthName</directive> définit
- l'<dfn>Identificateur</dfn> (Realm) à utiliser avec
- l'authentification. L'identificateur possède deux fonctions. Tout
- d'abord, le client présente en général cette information à
- l'utilisateur dans le cadre de la boîte de dialogue de mot de passe.
- Ensuite, le client l'utilise pour déterminer quel mot de passe
- envoyer pour une zone authentifiée donnée.</p>
-
- <p>Ainsi par exemple, une fois un client authentifié dans la zone
- <code>"Fichiers réservés"</code>, il soumettra à nouveau
- automatiquement le même mot de passe pour toute zone du même serveur
- marquée de l'identificateur <code>"Fichiers réservés"</code>. De
- cette façon, vous pouvez éviter à un utilisateur d'avoir à saisir
- plusieurs fois le même mot de passe en faisant partager le même
- identificateur entre plusieurs zones réservées. Bien entendu et pour
- des raisons de sécurité, le client devra redemander le mot
- de passe chaque fois que le nom d'hôte du serveur sera modifié.</p>
+ module="mod_authn_core">AuthName</directive> définit
+ l'<dfn>Identificateur</dfn> (Realm) à utiliser avec
+ l'authentification. L'identificateur possède deux fonctions. Tout
+ d'abord, le client présente en général cette information à
+ l'utilisateur dans le cadre de la boîte de dialogue de mot de passe.
+ Ensuite, le client l'utilise pour déterminer quel mot de passe
+ envoyer pour une zone authentifiée donnée.</p>
+
+ <p>Ainsi par exemple, une fois un client authentifié dans la zone
+ <code>"Fichiers réservés"</code>, il soumettra à nouveau
+ automatiquement le même mot de passe pour toute zone du même serveur
+ marquée de l'identificateur <code>"Fichiers réservés"</code>. De
+ cette façon, vous pouvez éviter à un utilisateur d'avoir à saisir
+ plusieurs fois le même mot de passe en faisant partager le même
+ identificateur entre plusieurs zones réservées. Bien entendu et pour
+ des raisons de sécurité, le client devra redemander le mot
+ de passe chaque fois que le nom d'hôte du serveur sera modifié.</p>
<p>La directive <directive
module="mod_auth_basic">AuthBasicProvider</directive> est, dans ce
- cas, facultative, car <code>file</code> est la valeur par défaut
+ cas, facultative, car <code>file</code> est la valeur par défaut
pour cette directive. Par contre, cette directive sera obligatoire
si vous utilisez une autre source d'authentification comme
<module>mod_authn_dbm</module> ou
<module>mod_authn_dbd</module>.</p>
<p>La directive <directive
- module="mod_authn_file">AuthUserFile</directive> définit le chemin
- du fichier de mots de passe que nous venons de créer avec
- <program>htpasswd</program>. Si vous possédez un grand nombre
- d'utilisateurs, la durée de la recherche dans un fichier texte pour
- authentifier un utilisateur à chaque requête va augmenter
- rapidement, et pour pallier cet inconvénient, Apache peut aussi
- stocker les données relatives aux
- utilisateurs dans des bases de données rapides. Le module
+ module="mod_authn_file">AuthUserFile</directive> définit le chemin
+ du fichier de mots de passe que nous venons de créer avec
+ <program>htpasswd</program>. Si vous possédez un grand nombre
+ d'utilisateurs, la durée de la recherche dans un fichier texte pour
+ authentifier un utilisateur à chaque requête va augmenter
+ rapidement, et pour pallier cet inconvénient, Apache peut aussi
+ stocker les données relatives aux
+ utilisateurs dans des bases de données rapides. Le module
<module>mod_authn_dbm</module> fournit la directive <directive
module="mod_authn_dbm">AuthDBMUserFile</directive>. Les programmes <program>
dbmmanage</program> et <program>htdbm</program> permettent de
- créer et manipuler ces fichiers. Vous
+ créer et manipuler ces fichiers. Vous
trouverez de nombreuses options d'autres types d'authentification
fournies par des modules tiers dans la <a
- href="http://modules.apache.org/">Base de données des modules
+ href="http://modules.apache.org/">Base de données des modules
d'Apache</a>.</p>
<p>Enfin, la directive <directive
- module="mod_authz_core">Require</directive> implémente la partie
- autorisation du processus en définissant l'utilisateur autorisé à
- accéder à cette zone du serveur. Dans la section suivante, nous
- décrirons les différentes méthodes d'utilisation de la directive
+ module="mod_authz_core">Require</directive> implémente la partie
+ autorisation du processus en définissant l'utilisateur autorisé à
+ accéder à cette zone du serveur. Dans la section suivante, nous
+ décrirons les différentes méthodes d'utilisation de la directive
<directive module="mod_authz_core">Require</directive>.</p>
</section>
-<section id="lettingmorethanonepersonin"><title>Autorisation d'accès à
+<section id="lettingmorethanonepersonin"><title>Autorisation d'accès à
plusieurs personnes</title>
<p>Les directives ci-dessus n'autorisent qu'une personne (quelqu'un
- possédant le nom d'utilisateur <code>rbowen</code>) à accéder au
- répertoire. Dans la plupart des cas, vous devrez autoriser
- l'accès à plusieurs personnes. C'est ici
+ possédant le nom d'utilisateur <code>rbowen</code>) à accéder au
+ répertoire. Dans la plupart des cas, vous devrez autoriser
+ l'accès à plusieurs personnes. C'est ici
qu'intervient la directive <directive module="mod_authz_groupfile"
>AuthGroupFile</directive>.</p>
- <p>Si vous voulez autoriser l'accès à plusieurs personnes, vous
- devez créer un fichier de groupes qui associe des noms de groupes
+ <p>Si vous voulez autoriser l'accès à plusieurs personnes, vous
+ devez créer un fichier de groupes qui associe des noms de groupes
avec une liste d'utilisateurs de ce groupe. Le format de ce fichier
- est très simple, et vous pouvez le créer avec votre éditeur favori.
- Son contenu se présente comme suit :</p>
+ est très simple, et vous pouvez le créer avec votre éditeur favori.
+ Son contenu se présente comme suit :</p>
<example>
Nom-de-groupe: rbowen dpitts sungo rshersey
</example>
<p>Il s'agit simplement une liste des membres du groupe sous la
- forme d'une ligne séparée par des espaces.</p>
+ forme d'une ligne séparée par des espaces.</p>
- <p>Pour ajouter un utilisateur à votre fichier de mots de passe
- préexistant, entrez :</p>
+ <p>Pour ajouter un utilisateur à votre fichier de mots de passe
+ préexistant, entrez :</p>
<example>
htpasswd /usr/local/apache/passwd/passwords dpitts
</example>
- <p>Vous obtiendrez le même effet qu'auparavant, mais le mot de passe
- sera ajouté au fichier, plutôt que d'en créer un nouveau (C'est le
- drapeau <code>-c</code> qui permet de créer un nouveau fichier de
+ <p>Vous obtiendrez le même effet qu'auparavant, mais le mot de passe
+ sera ajouté au fichier, plutôt que d'en créer un nouveau (C'est le
+ drapeau <code>-c</code> qui permet de créer un nouveau fichier de
mots de passe)..</p>
<p>Maintenant, vous devez modifier votre fichier
</highlight>
<p>Maintenant, quiconque appartient au groupe
- <code>Nom-de-groupe</code>, et possède une entrée dans le fichier
- <code>password</code> pourra accéder au répertoire s'il tape le bon
+ <code>Nom-de-groupe</code>, et possède une entrée dans le fichier
+ <code>password</code> pourra accéder au répertoire s'il tape le bon
mot de passe.</p>
- <p>Il existe une autre méthode moins contraignante pour autoriser
- l'accès à plusieurs personnes. Plutôt que de créer un fichier de
+ <p>Il existe une autre méthode moins contraignante pour autoriser
+ l'accès à plusieurs personnes. Plutôt que de créer un fichier de
groupes, il vous suffit d'ajouter la directive suivante :</p>
<highlight language="config">Require valid-user</highlight>
<p>Le remplacement de la ligne <code>Require user rbowen</code> par
- la ligne <code>Require valid-user</code> autorisera l'accès à
- quiconque possédant une entrée dans le fichier password, et ayant
- tapé le bon mot de passe. Vous pouvez même simuler le comportement
- des groupes en associant un fichier de mots de passe différent pour
- chaque groupe. L'avantage de cette approche réside dans le fait
+ la ligne <code>Require valid-user</code> autorisera l'accès à
+ quiconque possédant une entrée dans le fichier password, et ayant
+ tapé le bon mot de passe. Vous pouvez même simuler le comportement
+ des groupes en associant un fichier de mots de passe différent pour
+ chaque groupe. L'avantage de cette approche réside dans le fait
qu'Apache ne doit consulter qu'un fichier au lieu de deux. Par
contre, vous devez maintenir un nombre plus ou moins important de
- fichiers de mots de passe, et vous assurer de faire référence au bon
+ fichiers de mots de passe, et vous assurer de faire référence au bon
fichier dans la directive <directive
module="mod_authn_file">AuthUserFile</directive>.</p>
</section>
-<section id="possibleproblems"><title>Problèmes possibles</title>
- <p>L'authentification Basic est spécifiée d'une telle manière que
- vos nom d'utilisateur et mot de passe doivent être vérifiés chaque
- fois que vous demandez un document au serveur, et ceci même si vous
- rechargez la même page, et pour chaque image contenue dans la page
- (si elles sont situées dans un répertoire protégé). Comme vous
+<section id="possibleproblems"><title>Problèmes possibles</title>
+ <p>L'authentification Basic est spécifiée d'une telle manière que
+ vos nom d'utilisateur et mot de passe doivent être vérifiés chaque
+ fois que vous demandez un document au serveur, et ceci même si vous
+ rechargez la même page, et pour chaque image contenue dans la page
+ (si elles sont situées dans un répertoire protégé). Comme vous
pouvez l'imaginer, ceci ralentit un peu le fonctionnement. La mesure
- dans laquelle le fonctionnement est ralenti est proportionnelle à la
- taille du fichier des mots de passe, car ce dernier doit être ouvert
- et la liste des utilisateurs parcourue jusqu'à ce que votre nom soit
- trouvé, et ceci chaque fois qu'une page est chargée.</p>
+ dans laquelle le fonctionnement est ralenti est proportionnelle à la
+ taille du fichier des mots de passe, car ce dernier doit être ouvert
+ et la liste des utilisateurs parcourue jusqu'à ce que votre nom soit
+ trouvé, et ceci chaque fois qu'une page est chargée.</p>
- <p>En conséquence, ce ralentissement impose une limite pratique au
+ <p>En conséquence, ce ralentissement impose une limite pratique au
nombre d'utilisateurs que vous pouvez enregistrer dans un fichier de
mots de passe. Cette limite va varier en fonction des performances
- de votre serveur, mais vous commencerez à remarquer un
+ de votre serveur, mais vous commencerez à remarquer un
ralentissement lorsque vous atteindrez quelques centaines
- d'utilisateurs, et serez alors appelés à utiliser une méthode
- d'authentification différente.</p>
+ d'utilisateurs, et serez alors appelés à utiliser une méthode
+ d'authentification différente.</p>
</section>
-<section id="dbmdbd"><title>Autre méthode de stockage des mots de
+<section id="dbmdbd"><title>Autre méthode de stockage des mots de
passe</title>
- <p>Suite au problème évoqué précédemment et induit par le stockage
- des mots de passe dans un fichier texte, vous pouvez être appelé à
- stocker vos mots de passe d'une autre manière, par exemple dans une
- base de données.</p>
+ <p>Suite au problème évoqué précédemment et induit par le stockage
+ des mots de passe dans un fichier texte, vous pouvez être appelé à
+ stocker vos mots de passe d'une autre manière, par exemple dans une
+ base de données.</p>
<p>Pour y parvenir, on peut utiliser les modules
<module>mod_authn_dbm</module> ou <module>mod_authn_dbd</module>.
Vous pouvez choisir comme format de stockage <code>dbm</code> ou
- <code>dbd</code> à la place de <code>file</code> pour la directive
+ <code>dbd</code> à la place de <code>file</code> pour la directive
<directive module="mod_auth_basic">AuthBasicProvider</directive>.</p>
- <p>Par exemple, pour sélectionner un fichier dbm à la place d'un
+ <p>Par exemple, pour sélectionner un fichier dbm à la place d'un
fichier texte :</p>
<highlight language="config">
</highlight>
<p>D'autres options sont disponibles. Consultez la documentation de
- <module>mod_authn_dbm</module> pour plus de détails.</p>
+ <module>mod_authn_dbm</module> pour plus de détails.</p>
</section>
<section id="multprovider"><title>Utilisation de plusieurs fournisseurs
d'authentification</title>
- <p>Depuis l'arrivée des nouvelles architecture d'autorisation et
- d'authentification basées sur les fournisseurs, vous n'êtes plus
- limité à une méthode d'authentification et d'autorisation
+ <p>Depuis l'arrivée des nouvelles architecture d'autorisation et
+ d'authentification basées sur les fournisseurs, vous n'êtes plus
+ limité à une méthode d'authentification et d'autorisation
unique. En fait, on peut panacher autant de fournisseurs que l'on
- veut, ce qui vous permet d'élaborer l'architecture qui correspond
- exactement à vos besoins. Dans l'exemple suivant, on utilise
+ veut, ce qui vous permet d'élaborer l'architecture qui correspond
+ exactement à vos besoins. Dans l'exemple suivant, on utilise
conjointement les fournisseurs d'authentification
file et LDAP :</p>
<p>Dans cet exemple, le fournisseur file va tenter d'authentifier
l'utilisateur en premier. S'il n'y parvient pas, le fournisseur LDAP
- sera sollicité. Ceci permet l'élargissement des possibilités
- d'authentification si votre organisation implémente plusieurs types
- de bases d'authentification. D'autres scénarios d'authentification
+ sera sollicité. Ceci permet l'élargissement des possibilités
+ d'authentification si votre organisation implémente plusieurs types
+ de bases d'authentification. D'autres scénarios d'authentification
et d'autorisation peuvent associer un type d'authentification avec
un autre type d'autorisation. Par exemple, une authentification
- basée sur un fichier de mots de passe peut permettre l'attribution
- d'autorisations basée sur un annuaire LDAP.</p>
+ basée sur un fichier de mots de passe peut permettre l'attribution
+ d'autorisations basée sur un annuaire LDAP.</p>
- <p>Tout comme plusieurs fournisseurs d'authentification peuvent être
- implémentés, on peut aussi utiliser plusieurs méthodes
- d'autorisation. Dans l'exemple suivant, on utilise à la fois une
- autorisation à base de fichier de groupes et une autorisation à base
+ <p>Tout comme plusieurs fournisseurs d'authentification peuvent être
+ implémentés, on peut aussi utiliser plusieurs méthodes
+ d'autorisation. Dans l'exemple suivant, on utilise à la fois une
+ autorisation à base de fichier de groupes et une autorisation à base
de groupes LDAP.</p>
<highlight language="config">
</Directory>
</highlight>
- <p>Pour un scénario d'autorisation un peu plus avancé, des
+ <p>Pour un scénario d'autorisation un peu plus avancé, des
directives de conteneur d'autorisation comme <directive
module="mod_authz_core" type="section">RequireAll</directive> et
<directive module="mod_authz_core"
type="section">RequireAny</directive> permettent d'appliquer une
logique telle que l'ordre dans lequel les autorisations sont
- appliquées peut être entièrement contrôlé au niveau de la
+ appliquées peut être entièrement contrôlé au niveau de la
configuration. Voir <a
href="../mod/mod_authz_core.html#logic">Conteneurs
- d'autorisations</a> pour un exemple de ce contrôle.</p>
+ d'autorisations</a> pour un exemple de ce contrôle.</p>
</section>
<section id="beyond"><title>Pour aller plus loin qu'une simple
autorisation</title>
- <p>La manière dont les autorisations sont accordées est désormais
- beaucoup plus souple qu'une simple vérification auprès d'une seule
- base de données. Il est maintenant possible de choisir l'ordre, la
- logique et la manière selon lesquels une autorisation est
- accordée.</p>
+ <p>La manière dont les autorisations sont accordées est désormais
+ beaucoup plus souple qu'une simple vérification auprès d'une seule
+ base de données. Il est maintenant possible de choisir l'ordre, la
+ logique et la manière selon lesquels une autorisation est
+ accordée.</p>
<section id="authandororder"><title>Appliquer logique et
ordonnancement</title>
- <p>Le contrôle de la manière et de l'ordre selon lesquels le
- processus d'autorisation était appliqué
- constituait une sorte de mystère par
- le passé. Dans Apache 2.2, un mécanisme d'authentification basé
- sur les fournisseurs a été développé afin de séparer le
- véritable processus d'authentification de l'autorisation et ses
- différentes fonctionnalités. Un des avantages colatéraux
- résidait dans le fait que les fournisseurs d'authentification
- pouvaient être configurés et appelés selon un ordre particulier
- indépendant de l'ordre de chargement du module auth proprement
- dit. Ce mécanisme basé sur les fournisseurs a été étendu au
+ <p>Le contrôle de la manière et de l'ordre selon lesquels le
+ processus d'autorisation était appliqué
+ constituait une sorte de mystère par
+ le passé. Dans Apache 2.2, un mécanisme d'authentification basé
+ sur les fournisseurs a été développé afin de séparer le
+ véritable processus d'authentification de l'autorisation et ses
+ différentes fonctionnalités. Un des avantages colatéraux
+ résidait dans le fait que les fournisseurs d'authentification
+ pouvaient être configurés et appelés selon un ordre particulier
+ indépendant de l'ordre de chargement du module auth proprement
+ dit. Ce mécanisme basé sur les fournisseurs a été étendu au
processus d'autorisation. Ceci signifie que la directive
- <directive module="mod_authz_core">Require</directive> définit
- non seulement quelles méthodes d'autorisation doivent être
- utilisées, mais aussi l'ordre dans lequel elles sont appelées.
- Les méthodes d'autorisation sont appelées selon l'ordre dans
+ <directive module="mod_authz_core">Require</directive> définit
+ non seulement quelles méthodes d'autorisation doivent être
+ utilisées, mais aussi l'ordre dans lequel elles sont appelées.
+ Les méthodes d'autorisation sont appelées selon l'ordre dans
lequel les directives <directive
module="mod_authz_core">Require</directive> apparaissent dans la
configuration.</p>
type="section">RequireAll</directive>
et <directive module="mod_authz_core"
type="section">RequireAny</directive>, la
- configuration contrôle aussi le moment où les méthodes
- d'autorisation sont appelées, et quels critères déterminent
- l'autorisation d'acc
ès. Voir <a
+ configuration contrôle aussi le moment où les méthodes
+ d'autorisation sont appelées, et quels critères déterminent
+ l'autorisation d'acc
ès. Voir <a
href="../mod/mod_authz_core.html#logic">Conteneurs
- d'autorisations</a> pour un exemple de la manière de les
+ d'autorisations</a> pour un exemple de la manière de les
utiliser pour exprimer des logiques d'autorisation
complexes.</p>
- <p>Par défaut, toutes les directives <directive
+ <p>Par défaut, toutes les directives <directive
module="mod_authz_core">Require</directive> sont
- traitées comme si elles étaient contenues dans une directive
+ traitées comme si elles étaient contenues dans une directive
<directive module="mod_authz_core"
type="section">RequireAny</directive>. En d'autres termes, il
suffit
- qu'une méthode d'autorisation s'applique avec succès pour que
- l'autorisation soit accordée.</p>
+ qu'une méthode d'autorisation s'applique avec succès pour que
+ l'autorisation soit accordée.</p>
</section>
<section id="reqaccessctrl"><title>Utilisation de fournisseurs
- d'autorisation pour le contrôle d'accès</title>
- <p>La vérification du nom d'utilisateur et du mot de passe ne
- constituent qu'un aspect des méthodes d'authentification.
- Souvent, le contrôle d'accès à certaines personnes n'est pas
- basé sur leur identité ; il peut dépendre, par exemple de leur
+ d'autorisation pour le contrôle d'accès</title>
+ <p>La vérification du nom d'utilisateur et du mot de passe ne
+ constituent qu'un aspect des méthodes d'authentification.
+ Souvent, le contrôle d'accès à certaines personnes n'est pas
+ basé sur leur identité ; il peut dépendre, par exemple de leur
provenance.</p>
<p>Les fournisseurs d'autorisation <code>all</code>,
<code>env</code>, <code>host</code> et <code>ip</code> vous
- permettent d'accorder ou refuser l'accès en
- fonction de critères tels que le nom d'hôte ou l'adresse
- IP de la machine qui effectue la requête.</p>
+ permettent d'accorder ou refuser l'accès en
+ fonction de critères tels que le nom d'hôte ou l'adresse
+ IP de la machine qui effectue la requête.</p>
- <p>L'utilisation de ces fournisseurs est spécifiée à l'aide de
+ <p>L'utilisation de ces fournisseurs est spécifiée à l'aide de
la directive <directive
module="mod_authz_core">Require</directive>. Cette directive
permet d'enregistrer quels fournisseurs d'autorisation
- seront appelés dans le processus d'autorisation au cours du
- traitement de la requête. Par exemple :</p>
+ seront appelés dans le processus d'autorisation au cours du
+ traitement de la requête. Par exemple :</p>
<highlight language="config">Require ip <var>address</var></highlight>
- <p>où <var>adresse</var> est une adresse IP (ou une adresse IP
+ <p>où <var>adresse</var> est une adresse IP (ou une adresse IP
partielle) ou :</p>
<highlight language="config">Require host <var>domain_name</var></highlight>
- <p>où <var>nom_domaine</var> est un nom de domaine entièrement
- qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer
- plusieurs adresses ou noms de domaines, si vous le désirez.</p>
+ <p>où <var>nom_domaine</var> est un nom de domaine entièrement
+ qualifé (ou un nom de domaine partiel) ; vous pouvez indiquer
+ plusieurs adresses ou noms de domaines, si vous le désirez.</p>
<p>Par exemple, si vous voulez rejeter les spams dont une
machine vous inonde, vous pouvez utiliser ceci :</p>
</highlight>
<p>Ainsi, les visiteurs en provenance de cette adresse ne
- pourront pas voir le contenu concerné par cette directive. Si,
+ pourront pas voir le contenu concerné par cette directive. Si,
par contre, vous connaissez le nom de la machine, vous pouvez
utiliser ceci :</p>
</RequireAll>
</highlight>
- <p>Et si vous voulez interdire l'accès à toutes les machines
- d'un domaine, vous pouvez spécifier une partie seulement de
+ <p>Et si vous voulez interdire l'accès à toutes les machines
+ d'un domaine, vous pouvez spécifier une partie seulement de
l'adresse ou du nom de domaine :</p>
<highlight language="config">
<p>L'utilisation de la directive <directive
module="mod_authz_core" type="section">RequireAll</directive>
avec de multiples directives <directive module="mod_authz_core"
- type="section">Require</directive>, toutes avec la négation
- <code>not</code>, n'accordera l'accès que si toutes les
- conditions négatives sont vérifiées. En d'autres termes, l'accès
- sera refusé si au moins une des conditions négatives n'est pas
- vérifiée.</p>
+ type="section">Require</directive>, toutes avec la négation
+ <code>not</code>, n'accordera l'accès que si toutes les
+ conditions négatives sont vérifiées. En d'autres termes, l'accès
+ sera refusé si au moins une des conditions négatives n'est pas
+ vérifiée.</p>
</section>
- <section id="filesystem"><title>Compatibilité ascendante du contrôle
- d'accès</title>
- <p>L'adoption d'un mécanisme à base de fournisseurs pour
- l'authentification, a pour effet colatéral de rendre inutiles
+ <section id="filesystem"><title>Compatibilité ascendante du contrôle
+ d'accès</title>
+ <p>L'adoption d'un mécanisme à base de fournisseurs pour
+ l'authentification, a pour effet colatéral de rendre inutiles
les directives <directive
module="mod_access_compat">Order</directive>, <directive
module="mod_access_compat">Allow</directive>, <directive
module="mod_access_compat">Deny</directive> et <directive
- module="mod_access_compat">Satisfy</directive>. Cependant, et à
- des fins de compatibilité ascendante vers les anciennes
- configurations, ces directives ont été déplacées vers le module
+ module="mod_access_compat">Satisfy</directive>. Cependant, et à
+ des fins de compatibilité ascendante vers les anciennes
+ configurations, ces directives ont été déplacées vers le module
<module>mod_access_compat</module>.</p>
+ <note type="warning"><title>Note</title>
+ <p>Les directives fournies par le module
+ <module>mod_access_compat</module> sont devenues obsolètes depuis
+ la refonte du module <module>mod_authz_host</module>. Mélanger d'anciennes
+ directives comme <directive
+ module="mod_access_compat">Order</directive>, <directive
+ module="mod_access_compat">Allow</directive> ou <directive
+ module="mod_access_compat">Deny</directive> avec des nouvelles comme
+ <directive module="mod_authz_core">Require</directive> est techniquement
+ possible mais déconseillé. En effet, <module>mod_access_compat</module> a
+ été conçu pour supporter des configurations ne contenant que des anciennes
+ directives afin de faciliter le passage à la version 2.4. Voir le document
+ <a href="../upgrading.html">upgrading</a> pour plus de détails.
+ </p>
+ </note>
</section>
</section>
<section id="socache"><title>Mise en cache de l'authentification</title>
<p>Dans certains cas, l'authentification constitue une charge
- inacceptable pour un fournisseur d'authentification ou votre réseau.
+ inacceptable pour un fournisseur d'authentification ou votre réseau.
Ceci est susceptible d'affecter les utilisateurs du module
<module>mod_authn_dbd</module> (ou les fournisseurs
- tiers/personnalisés). Pour résoudre ce problème, HTTPD 2.3/2.4
+ tiers/personnalisés). Pour résoudre ce problème, HTTPD 2.3/2.4
propose un nouveau fournisseur de mise en cache,
<module>mod_authn_socache</module>, qui permet de mettre en cache
- les données d'authentification, et ainsi réduire la charge du/des
+ les données d'authentification, et ainsi réduire la charge du/des
fournisseurs(s) originels.</p>
<p>Cette mise en cache apportera un gain en performance substantiel
- à certains utilisateurs.</p>
+ à certains utilisateurs.</p>
</section>
<section id="moreinformation"><title>Pour aller plus loin . . .</title>
<p>Vous pouvez aussi lire la documentation de
<module>mod_auth_basic</module> et <module>mod_authz_host</module>
- qui contient des informations supplémentaires à propos du
+ qui contient des informations supplémentaires à propos du
fonctionnement de tout ceci.
- Certaines configurations d'authentification peuvent aussi être
- simplifiées à l'aide de la directive <directive
+ Certaines configurations d'authentification peuvent aussi être
+ simplifiées à l'aide de la directive <directive
type="section"
module="mod_authn_core">AuthnProviderAlias</directive>.</p>
- <p>Les différents algorithmes de chiffrement supportés par Apache
- pour authentifier les donn
ées sont expliqués dans <a
+ <p>Les différents algorithmes de chiffrement supportés par Apache
+ pour authentifier les donn
ées sont expliqués dans <a
href="../misc/password_encryptions.html">PasswordEncryptions</a>.</p>
- <p>Enfin vous pouvez consulter la recette <a href="access.html">Contrôle
- d'accès</a>, qui décrit un certain nombre de situations en relation
+ <p>Enfin vous pouvez consulter la recette <a href="access.html">Contrôle
+ d'accès</a>, qui décrit un certain nombre de situations en relation
avec le sujet.</p>
</section>
-<?xml version="1.0"?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1673945:1738217 (outdated) -->
+<!-- English Revision: 1738217 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
<modulesynopsis metafile="mod_access_compat.xml.meta">
<name>mod_access_compat</name>
-<description>Autorisations de groupe à base de nom d'hôte (nom ou
+<description>Autorisations de groupe à base de nom d'hôte (nom ou
adresse IP)</description>
<status>Extension</status>
<sourcefile>mod_access_compat.c</sourcefile>
<identifier>access_compat_module</identifier>
<compatibility>Disponible dans la version 2.3 du serveur HTTP Apache
-à des fins de compatibilité
-avec les précédentes versions d'Apache httpd 2.x. Les directives fournies par
-ce module sont devenues obsolètes depuis la refonte d'authz. Voir
+à des fins de compatibilité
+avec les précédentes versions d'Apache httpd 2.x. Les directives fournies par
+ce module sont devenues obsolètes depuis la refonte d'authz. Voir
<module>mod_authz_host</module></compatibility>
<summary>
<directive module="core" type="section">Location</directive>, ainsi
que dans les fichiers <code><a
href="core.html#accessfilename">.htaccess</a></code> et permettent
- de contrôler l'accès à certaines parties du serveur. On peut
- contrôler cet accès en fonction du nom d'hôte du client, de son
- adresse IP ou d'autres caractéristiques de la requête, telles
- qu'elles sont enregistr
ées dans les <a href="../env.html">variables
+ de contrôler l'accès à certaines parties du serveur. On peut
+ contrôler cet accès en fonction du nom d'hôte du client, de son
+ adresse IP ou d'autres caractéristiques de la requête, telles
+ qu'elles sont enregistr
ées dans les <a href="../env.html">variables
d'environnement</a>. Les directives <directive
module="mod_access_compat">Allow</directive> et <directive
- module="mod_access_compat">Deny</directive> permettent de spécifier
- quels clients sont ou ne sont pas autorisés à accéder au serveur,
+ module="mod_access_compat">Deny</directive> permettent de spécifier
+ quels clients sont ou ne sont pas autorisés à accéder au serveur,
alors que la directive <directive
- module="mod_access_compat">Order</directive> définit le statut
- d'accès par défaut, et détermine la manière dont les directives
+ module="mod_access_compat">Order</directive> définit le statut
+ d'accès par défaut, et détermine la manière dont les directives
<directive module="mod_access_compat">Allow</directive> et
<directive module="mod_access_compat">Deny</directive> interagissent
entre elles.</p>
- <p>Les restrictions d'accès à base de nom d'hôte et
- l'authentification à base de mot de passe peuvent être implémentées
- simultanément. Dans ce cas, on utilise la directive <directive
- module="mod_access_compat">Satisfy</directive> pour déterminer la
- manière dont ces deux modes de restrictions interagissent.</p>
+ <p>Les restrictions d'accès à base de nom d'hôte et
+ l'authentification à base de mot de passe peuvent être implémentées
+ simultanément. Dans ce cas, on utilise la directive <directive
+ module="mod_access_compat">Satisfy</directive> pour déterminer la
+ manière dont ces deux modes de restrictions interagissent.</p>
<note type="warning"><title>Note</title>
<p>Les directives fournies par le module
- <module>mod_access_compat</module> sont devenues obsolètes depuis
- la refonte d'authz. Voir <module>mod_authz_host</module>.</p>
+ <module>mod_access_compat</module> sont devenues obsolètes depuis
+ la refonte du module <module>mod_authz_host</module>. Mélanger d'anciennes
+ directives comme <directive
+ module="mod_access_compat">Order</directive>, <directive
+ module="mod_access_compat">Allow</directive> ou <directive
+ module="mod_access_compat">Deny</directive> avec des nouvelles comme
+ <directive module="mod_authz_core">Require</directive> est techniquement
+ possible mais déconseillé. En effet, <module>mod_access_compat</module> a
+ été conçu pour supporter des configurations ne contenant que des anciennes
+ directives afin de faciliter le passage à la version 2.4. Voir le document
+ <a href="../upgrading.html">upgrading</a> pour plus de détails.
+ </p>
</note>
- <p>En général, les directives de restriction d'accès s'appliquent à
- toutes les méthodes d'accès (<code>GET</code>, <code>PUT</code>,
+ <p>En général, les directives de restriction d'accès s'appliquent à
+ toutes les méthodes d'accès (<code>GET</code>, <code>PUT</code>,
<code>POST</code>, etc...). C'est d'ailleurs ce que l'on souhaite
dans la plupart des cas. Il est cependant possible de restreindre
- certaines méthodes, alors que les autres méthodes ne se verront
- imposée aucune restriction, en regroupant les directives à
- l'intérieur d'une section <directive module="core"
+ certaines méthodes, alors que les autres méthodes ne se verront
+ imposée aucune restriction, en regroupant les directives à
+ l'intérieur d'une section <directive module="core"
type="section">Limit</directive>.</p>
<note><title>Fusion des sections de configuration</title>
- <p>Lorsqu'une directive fournie par ce module est utilisée dans
- une nouvelle section de configuration, cette dernière n'hérite
- d'aucune directive définie dans une section précédente.</p>
+ <p>Lorsqu'une directive fournie par ce module est utilisée dans
+ une nouvelle section de configuration, cette dernière n'hérite
+ d'aucune directive définie dans une section précédente.</p>
</note>
</summary>
<directivesynopsis>
<name>Allow</name>
-<description>Spécifie quels hôtes peuvent accéder à une certaine zone du
+<description>Spécifie quels hôtes peuvent accéder à une certaine zone du
serveur</description>
-<syntax> Allow from all|<var>hôte</var>|env=[!]<var>variable
+<syntax> Allow from all|<var>hôte</var>|env=[!]<var>variable
d'environnement</var>
-[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
+[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>Limit</override>
<usage>
- <p>La directive <directive>Allow</directive> permet de définir quels
- hôtes ont le droit d'accéder à une certaine partie du serveur. On
- peut contrôler l'accès par nom d'hôte, adresse IP, intervalle
- d'adresses IP, ou toute autre caractéristique de la requête client
- enregistrée dans les variables d'environnement.</p>
+ <p>La directive <directive>Allow</directive> permet de définir quels
+ hôtes ont le droit d'accéder à une certaine partie du serveur. On
+ peut contrôler l'accès par nom d'hôte, adresse IP, intervalle
+ d'adresses IP, ou toute autre caractéristique de la requête client
+ enregistrée dans les variables d'environnement.</p>
<p>Le premier argument de cette directive est toujours
<code>from</code>. Les arguments suivants peuvent prendre trois
- formes différentes. Si <code>Allow from all</code> est spécifié,
- tout hôte se voit accordé l'accès, en tenant compte des directives
+ formes différentes. Si <code>Allow from all</code> est spécifié,
+ tout hôte se voit accordé l'accès, en tenant compte des directives
<directive module="mod_access_compat">Deny</directive> et <directive
- module="mod_access_compat">Order</directive> comme décrit plus loin.
- Pour ne permettre l'accès au serveur qu'à un hôte ou un groupe
- d'hôtes particuliers, on peut spécifier un <em>nom d'hôte</em> sous
+ module="mod_access_compat">Order</directive> comme décrit plus loin.
+ Pour ne permettre l'accès au serveur qu'à un hôte ou un groupe
+ d'hôtes particuliers, on peut spécifier un <em>nom d'hôte</em> sous
une des formes suivantes :</p>
<dl>
Allow from example.org
Allow from .net example.edu
</highlight>
- <p>Les hôtes dont les noms correspondent ou se terminent par la
- chaîne spécifiée ont l'autorisation d'accès. Seules les
- composantes entières du nom d'hôte doivent correspondre ; ainsi,
+ <p>Les hôtes dont les noms correspondent ou se terminent par la
+ chaîne spécifiée ont l'autorisation d'accès. Seules les
+ composantes entières du nom d'hôte doivent correspondre ; ainsi,
dans l'exemple ci-dessus, <code>foo.example.org</code>
correspondra, mais <code>fooexample.org</code> ne conviendra pas.
Avec cette configuration, Apache httpd va effectuer une double recherche
DNS sur l'adresse IP du client, sans tenir compte de la
- définition de la directive <directive
+ définition de la directive <directive
module="core">HostnameLookups</directive>. Tout d'abord, une
- recherche DNS inverse sur l'adresse IP est effectuée pour
- déterminer le nom d'hôte associé, puis une recherche directe sur
- le nom d'hôte est effectuée afin de s'assurer qu'il correspond
- bien à l'adresse IP originale. L'accès ne sera accordé que si le
- nom d'hôte correspond et si les recherches DNS inverse et directe
+ recherche DNS inverse sur l'adresse IP est effectuée pour
+ déterminer le nom d'hôte associé, puis une recherche directe sur
+ le nom d'hôte est effectuée afin de s'assurer qu'il correspond
+ bien à l'adresse IP originale. L'accès ne sera accordé que si le
+ nom d'hôte correspond et si les recherches DNS inverse et directe
concordent.</p></dd>
- <dt>Une adresse IP complète</dt>
+ <dt>Une adresse IP complète</dt>
<dd>
<highlight language="config">
Allow from 10.1.2.3
Allow from 192.168.1.104 192.168.1.205
</highlight>
- <p>L'adresse IP d'un hôte auquel on a accordé l'accès</p></dd>
+ <p>L'adresse IP d'un hôte auquel on a accordé l'accès</p></dd>
<dt>Une adresse IP partielle</dt>
Allow from 10.1
Allow from 10 172.20 192.168.2
</highlight>
- <p>De un à trois des premiers octets d'une adresse IP, afin de
- restreindre l'accès à un sous-réseau.</p></dd>
+ <p>De un à trois des premiers octets d'une adresse IP, afin de
+ restreindre l'accès à un sous-réseau.</p></dd>
- <dt>Une paire réseau/masque de sous-réseau</dt>
+ <dt>Une paire réseau/masque de sous-réseau</dt>
<dd>
<highlight language="config">
Allow from 10.1.0.0/255.255.0.0
</highlight>
- <p>Un réseau a.b.c.d, et un masque de sous-réseau w.x.y.z, pour
- une définition plus précise de la restriction d'accès imposée à un
- sous-réseau.</p></dd>
+ <p>Un réseau a.b.c.d, et un masque de sous-réseau w.x.y.z, pour
+ une définition plus précise de la restriction d'accès imposée à un
+ sous-réseau.</p></dd>
- <dt>Une spécification CIDR réseau/nnn</dt>
+ <dt>Une spécification CIDR réseau/nnn</dt>
<dd>
<highlight language="config">
Allow from 10.1.0.0/16
</highlight>
- <p>Identique au cas précédent, mis à part que le masque est
- constitué des nnn bits de poids fort.</p></dd>
+ <p>Identique au cas précédent, mis à part que le masque est
+ constitué des nnn bits de poids fort.</p></dd>
</dl>
- <p>Notez que les trois derniers exemples désignent le même ensemble
- d'hôtes.</p>
+ <p>Notez que les trois derniers exemples désignent le même ensemble
+ d'hôtes.</p>
- <p>On peut spécifier des adresses et sous-réseaux IPv6 de la manière
+ <p>On peut spécifier des adresses et sous-réseaux IPv6 de la manière
suivante :</p>
<highlight language="config">
Allow from 2001:db8::a00:20ff:fea7:ccea/10
</highlight>
- <p>Le troisième format d'argument de la directive
- <directive>Allow</directive> permet de contrôler l'accès au serveur
+ <p>Le troisième format d'argument de la directive
+ <directive>Allow</directive> permet de contrôler l'accès au serveur
en fonction de l'existence d'une <a
href="../env.html">variable d'environnement</a>. Lorsque <code>Allow
- from env=<var>variable d'environnement</var></code> est spécifié, la
- requête est autorisée si la variable d'environnement <var>variable
+ from env=<var>variable d'environnement</var></code> est spécifié, la
+ requête est autorisée si la variable d'environnement <var>variable
d'environnement</var> existe. En revanche, lorsque <code>Allow from
- env=!<var>env-variable</var></code> est spécifié, la
- requête est autorisée si la variable d'environnement <var>variable
- d'environnement</var> n'existe pas. Le serveur permet de définir
+ env=!<var>env-variable</var></code> est spécifié, la
+ requête est autorisée si la variable d'environnement <var>variable
+ d'environnement</var> n'existe pas. Le serveur permet de définir
avec souplesse des variables d'environnement en se basant sur les
- caractéristiques de la requête client et en utilisant les directives
+ caractéristiques de la requête client et en utilisant les directives
fournies par le module <module>mod_setenvif</module>. Ainsi, on peut
utiliser la directive <directive>Allow</directive> pour permettre
- l'accès en fonction de paramètres comme le <code>User-Agent</code>
+ l'accès en fonction de paramètres comme le <code>User-Agent</code>
(type de navigateur) des clients, le <code>Referer</code>, ou
- d'autres champs d'en-tête de la requête HTTP.</p>
+ d'autres champs d'en-tête de la requête HTTP.</p>
<highlight language="config">
SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
</Directory>
</highlight>
- <p>Dans cet exemple, les navigateurs dont la chaîne user-agent
+ <p>Dans cet exemple, les navigateurs dont la chaîne user-agent
commence par <code>KnockKnock/2.0</code> se verront accorder
- l'accès, alors que tous les autres seront rejetés.</p>
+ l'accès, alors que tous les autres seront rejetés.</p>
<note><title>Fusion des sections de configuration</title>
- <p>Lorsqu'une directive fournie par ce module est utilisée dans
- une nouvelle section de configuration, cette dernière n'hérite
- d'aucune directive définie dans une section précédente.</p>
+ <p>Lorsqu'une directive fournie par ce module est utilisée dans
+ une nouvelle section de configuration, cette dernière n'hérite
+ d'aucune directive définie dans une section précédente.</p>
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>Deny</name>
-<description>Définit quels hôtes ne sont pas autorisés à accéder au
+<description>Définit quels hôtes ne sont pas autorisés à accéder au
serveur</description>
-<syntax> Deny from all|<var>hôte</var>|env=[!]<var>variable
+<syntax> Deny from all|<var>hôte</var>|env=[!]<var>variable
d'environnement</var>
-[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
+[<var>hôte</var>|env=[!]<var>variable d'environnement</var>] ...</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>Limit</override>
<usage>
- <p>Cette directive permet de restreindre l'accès au serveur en
- fonction du nom d'hôte, de l'adresse IP ou de variables
+ <p>Cette directive permet de restreindre l'accès au serveur en
+ fonction du nom d'hôte, de l'adresse IP ou de variables
d'environnement. Les arguments de la directive
<directive>Deny</directive> sont identiques aux arguments de la
directive <directive
<directivesynopsis>
<name>Order</name>
-<description>Définit le statut d'accès par défaut et l'ordre dans lequel
+<description>Définit le statut d'accès par défaut et l'ordre dans lequel
les directives <directive>Allow</directive> et
-<directive>Deny</directive> sont évaluées.</description>
+<directive>Deny</directive> sont évaluées.</description>
<syntax> Order <var>ordre</var></syntax>
<default>Order Deny,Allow</default>
<contextlist><context>directory</context><context>.htaccess</context>
<usage>
- <p>La directive <directive>Order</directive>, associée aux
+ <p>La directive <directive>Order</directive>, associée aux
directives <directive module="mod_access_compat">Allow</directive>
et <directive module="mod_access_compat">Deny</directive>,
- implémente un système de contrôle d'accès en trois passes. Au cours
- de la première passe, ce sont soit toutes les directives <directive
+ implémente un système de contrôle d'accès en trois passes. Au cours
+ de la première passe, ce sont soit toutes les directives <directive
module="mod_access_compat">Allow</directive>, soit toutes les
directives <directive
- module="mod_access_compat">Deny</directive> qui sont traitées, selon
- la définition de la directive <directive
+ module="mod_access_compat">Deny</directive> qui sont traitées, selon
+ la définition de la directive <directive
module="mod_access_compat">Order</directive>. Le reste des
directives (<directive module="mod_access_compat">Deny</directive>
ou <directive module="mod_access_compat">Allow</directive>) est
- traité au cours de la seconde passe. La troisième passe s'applique à
- toutes les requêtes qui ne sont concernées par aucune des deux
- premières passes.</p>
+ traité au cours de la seconde passe. La troisième passe s'applique à
+ toutes les requêtes qui ne sont concernées par aucune des deux
+ premières passes.</p>
<p>Notez que toutes les directives <directive
module="mod_access_compat">Allow</directive> et <directive
- module="mod_access_compat">Deny</directive> sont traitées, à la
- différence d'un pare-feu classique où seule la première règle qui
- correspond est utilisée. La dernière directive qui correspond
- s'applique ( à la différence là encore d'un pare-feu classique). De
+ module="mod_access_compat">Deny</directive> sont traitées, à la
+ différence d'un pare-feu classique où seule la première règle qui
+ correspond est utilisée. La dernière directive qui correspond
+ s'applique ( à la différence là encore d'un pare-feu classique). De
plus, l'ordre dans lequel les lignes apparaissent dans le fichier de
configuration n'a pas d'incidence -- toutes les lignes <directive
- module="mod_access_compat">Allow</directive> sont considérées comme
+ module="mod_access_compat">Allow</directive> sont considérées comme
un groupe, toutes les lignes <directive
module="mod_access_compat">Deny</directive> comme un autre, et le
- statut par défaut a son existence propre.</p>
+ statut par défaut a son existence propre.</p>
- <p><em>Ordre</em> peut être :</p>
+ <p><em>Ordre</em> peut être :</p>
<dl>
<dt><code>Allow,Deny</code></dt>
<dd>Dans un premier temps, toutes les directives <directive
- module="mod_access_compat">Allow</directive> sont évaluées ; au
- moins une d'entre elles doit correspondre, sinon la requête est
- rejetée. Ensuite, toutes les directives <directive
- module="mod_access_compat">Deny</directive> sont évaluées. Si au
- moins l'une d'entre elles correspond, la requête est rejetée.
- Enfin, toute requête qui ne correspond à aucune directive
+ module="mod_access_compat">Allow</directive> sont évaluées ; au
+ moins une d'entre elles doit correspondre, sinon la requête est
+ rejetée. Ensuite, toutes les directives <directive
+ module="mod_access_compat">Deny</directive> sont évaluées. Si au
+ moins l'une d'entre elles correspond, la requête est rejetée.
+ Enfin, toute requête qui ne correspond à aucune directive
<directive module="mod_access_compat">Allow</directive> ou
- <directive module="mod_access_compat">Deny</directive> est rejetée
- par défaut.</dd>
+ <directive module="mod_access_compat">Deny</directive> est rejetée
+ par défaut.</dd>
<dt><code>Deny,Allow</code></dt>
<dd>Dans un premier temps, toutes les directives <directive
- module="mod_access_compat">Deny</directive> sont évaluées ; Si au
- moins une d'entre elles correspond, la requête est rejetée,
- <strong>à moins</strong> qu'elle corresponde aussi à une directive
+ module="mod_access_compat">Deny</directive> sont évaluées ; Si au
+ moins une d'entre elles correspond, la requête est rejetée,
+ <strong>à moins</strong> qu'elle corresponde aussi à une directive
<directive module="mod_access_compat">Allow</directive>. Toute
- requête qui ne correspond à aucune directive <directive
+ requête qui ne correspond à aucune directive <directive
module="mod_access_compat">Allow</directive> ou <directive
- module="mod_access_compat">Deny</directive> est autorisée.</dd>
+ module="mod_access_compat">Deny</directive> est autorisée.</dd>
<dt><code>Mutual-failure</code></dt>
- <dd>Cet argument a le même effet que <code>Allow,Deny</code> et
- est devenu de ce fait obsolète.</dd>
+ <dd>Cet argument a le même effet que <code>Allow,Deny</code> et
+ est devenu de ce fait obsolète.</dd>
</dl>
- <p>Les mots-clés ne peuvent être séparés que par des virgules ;
+ <p>Les mots-clés ne peuvent être séparés que par des virgules ;
<em>aucun espace</em> ne doit s'intercaler entre eux.</p>
<table border="1">
<tr>
<th>Match</th>
- <th>Résultat Allow,Deny</th>
- <th>Résultat Deny,Allow</th>
+ <th>Résultat Allow,Deny</th>
+ <th>Résultat Deny,Allow</th>
</tr><tr>
- <th>Correspond à Allow seulement</th>
- <td>Requête autorisée</td>
- <td>Requête autorisée</td>
+ <th>Correspond à Allow seulement</th>
+ <td>Requête autorisée</td>
+ <td>Requête autorisée</td>
</tr><tr>
- <th>Correspond à Deny seulement</th>
- <td>Requête rejetée</td>
- <td>Requête rejetée</td>
+ <th>Correspond à Deny seulement</th>
+ <td>Requête rejetée</td>
+ <td>Requête rejetée</td>
</tr><tr>
<th>Aucune correspondance</th>
- <td>Par défaut la seconde directive : rejet</td>
- <td>Par défaut la seconde directive : autorisation</td>
+ <td>Par défaut la seconde directive : rejet</td>
+ <td>Par défaut la seconde directive : autorisation</td>
</tr><tr>
- <th>Correspond à Allow & Deny</th>
- <td>La dernière correspondance l'emporte : rejet</td>
- <td>La dernière correspondance l'emporte : autorisation</td>
+ <th>Correspond à Allow & Deny</th>
+ <td>La dernière correspondance l'emporte : rejet</td>
+ <td>La dernière correspondance l'emporte : autorisation</td>
</tr>
</table>
- <p>Dans cet exemple, tous les hôtes du domaine example.org ont
- l'autorisation d'accès ; tous les autres voient leur accès
- refusé.</p>
+ <p>Dans cet exemple, tous les hôtes du domaine example.org ont
+ l'autorisation d'accès ; tous les autres voient leur accès
+ refusé.</p>
<highlight language="config">
Order Deny,Allow
Allow from example.org
</highlight>
- <p>Dans l'exemple suivant, tous les hôtes du domaine example.org ont
- l'autorisation d'accès, sauf ceux du sous-domaine foo.example.org qui
- voient leur accès refusé. Tous les hôtes qui ne sont pas dans le
- domaine example.org sont rejetés car le statut par défaut est positionné
+ <p>Dans l'exemple suivant, tous les hôtes du domaine example.org ont
+ l'autorisation d'accès, sauf ceux du sous-domaine foo.example.org qui
+ voient leur accès refusé. Tous les hôtes qui ne sont pas dans le
+ domaine example.org sont rejetés car le statut par défaut est positionné
sur <directive
module="mod_access_compat">Deny</directive>, et consiste donc en un
- refus d'accès.</p>
+ refus d'accès.</p>
<highlight language="config">
Order Allow,Deny
</highlight>
<p>Par contre, si la valeur de la directive
- <directive>Order</directive>, dans l'exemple précédent, est
- <code>Deny,Allow</code>, tout le monde a l'autorisation d'accès.
- Ceci est dû au fait que <code>Allow from example.org</code> sera
- évalué en dernier, sans tenir compte de l'ordre réel dans lequel les
+ <directive>Order</directive>, dans l'exemple précédent, est
+ <code>Deny,Allow</code>, tout le monde a l'autorisation d'accès.
+ Ceci est dû au fait que <code>Allow from example.org</code> sera
+ évalué en dernier, sans tenir compte de l'ordre réel dans lequel les
directives apparaissent dans le fichier de configuration, et va
- l'emporter sur <code>Deny from foo.example.org</code>. Tout hôte qui
+ l'emporter sur <code>Deny from foo.example.org</code>. Tout hôte qui
n'est pas dans le domaine <code>example.org</code> aura aussi
- l'autorisation d'accès car le statut par défaut est positionné sur
+ l'autorisation d'accès car le statut par défaut est positionné sur
<directive
module="mod_access_compat">Allow</directive> et constitue donc une
- autorisation d'accès.</p>
+ autorisation d'accès.</p>
- <p>La présence d'une directive <directive>Order</directive> peut
- affecter le contrôle d'accès à une partie du serveur même en
+ <p>La présence d'une directive <directive>Order</directive> peut
+ affecter le contrôle d'accès à une partie du serveur même en
l'abscence de directives <directive
module="mod_access_compat">Allow</directive> et <directive
- module="mod_access_compat">Deny</directive> associées, à cause de
- son influence sur le statut par défaut. Par exemple,</p>
+ module="mod_access_compat">Deny</directive> associées, à cause de
+ son influence sur le statut par défaut. Par exemple,</p>
<highlight language="config">
<Directory "/www">
</Directory>
</highlight>
- <p>va interdire tout accès au répertoire <code>/www</code> à cause
- du statut d'accès par défaut qui est défini à <directive
+ <p>va interdire tout accès au répertoire <code>/www</code> à cause
+ du statut d'accès par défaut qui est défini à <directive
module="mod_access_compat">Deny</directive>.</p>
- <p>La directive <directive>Order</directive> ne contrôle l'ordre
- dans lequel sont traitées les directives d'accès qu'au cours de
+ <p>La directive <directive>Order</directive> ne contrôle l'ordre
+ dans lequel sont traitées les directives d'accès qu'au cours de
chaque phase du traitement de la configuration du serveur. Ceci
implique, par exemple, qu'une directive <directive
module="mod_access_compat">Allow</directive> ou <directive
- module="mod_access_compat">Deny</directive> située dans une section
+ module="mod_access_compat">Deny</directive> située dans une section
<directive module="core" type="section">Location</directive> sera
- toujours évaluée après une directive <directive
+ toujours évaluée après une directive <directive
module="mod_access_compat">Allow</directive> ou <directive
- module="mod_access_compat">Deny</directive> située dans une section
+ module="mod_access_compat">Deny</directive> située dans une section
<directive module="core" type="section">Directory</directive> ou un
fichier <code>.htaccess</code>, sans tenir compte de la
- définition de la directive <directive>Order</directive>. Pour plus
- de détails à propos de la fusion des sections de configuration, voir
+ définition de la directive <directive>Order</directive>. Pour plus
+ de détails à propos de la fusion des sections de configuration, voir
le document <a
href="../sections.html">Comment fonctionnent les sections Directory,
Location et Files</a>.</p>
<note><title>Fusion des sections de configuration</title>
- <p>Lorsqu'une directive fournie par ce module est utilisée dans
- une nouvelle section de configuration, cette dernière n'hérite
- d'aucune directive définie dans une section précédente.</p>
+ <p>Lorsqu'une directive fournie par ce module est utilisée dans
+ une nouvelle section de configuration, cette dernière n'hérite
+ d'aucune directive définie dans une section précédente.</p>
</note>
</usage>
</directivesynopsis>
<directivesynopsis>
<name>Satisfy</name>
-<description>Interaction entre le contrôle d'accès en fonction de l'hôte
+<description>Interaction entre le contrôle d'accès en fonction de l'hôte
et l'authentification utilisateur</description>
<syntax>Satisfy Any|All</syntax>
<default>Satisfy All</default>
</contextlist>
<override>AuthConfig</override>
<usage>
- <p>Politique d'accès dans le cas où on utilise à la fois <directive
+ <p>Politique d'accès dans le cas où on utilise à la fois <directive
module="mod_access_compat">Allow</directive> et <directive
module="mod_authz_core">Require</directive>. L'argument est soit
<code>All</code>, soit <code>Any</code>. L'utilisation de cette
- directive n'a de sens que si l'accès à une zone particulière du
+ directive n'a de sens que si l'accès à une zone particulière du
serveur est restreinte par utilisateur/mot de passe et en fonction
- de l'adresse IP de l'hôte client. Dans ce cas, par
- défaut (<code>All</code>), le client doit satisfaire à la
+ de l'adresse IP de l'hôte client. Dans ce cas, par
+ défaut (<code>All</code>), le client doit satisfaire à la
restriction d'adresse, <em>et</em> fournir un couple
utilisateur/mot de passe valide. Avec l'argument <code>Any</code>,
- le client se verra accorder l'accès s'il satisfait à la restriction
+ le client se verra accorder l'accès s'il satisfait à la restriction
d'adresse ou fournit un couple utilisateur/mot de passe valide. On
- peut utiliser cette dernière définition pour restreindre l'accès à
- une zone par mot de passe, mais accorder l'accès aux clients
- possédant certaines adresses IP sans qu'ils aient à fournir de mot
+ peut utiliser cette dernière définition pour restreindre l'accès à
+ une zone par mot de passe, mais accorder l'accès aux clients
+ possédant certaines adresses IP sans qu'ils aient à fournir de mot
de passe.</p>
<p>Par exemple, si vous souhaitez que les utilisateurs de votre
- réseau accèdent à une zone de votre site web sans restriction, mais
- que l'accès à cette zone nécessite un mot de passe pour les autres
+ réseau accèdent à une zone de votre site web sans restriction, mais
+ que l'accès à cette zone nécessite un mot de passe pour les autres
utilisateurs, vous pouvez utiliser une configuration du style :</p>
<highlight language="config">
</highlight>
<p>
- Une autre utilisation fréquente de la directive
- <directive>Satisfy</directive> est l'allègement des restrictions
- d'accès à un sous-répertoire par rapport aux restrictions d'accès au
- répertoire parent :
+ Une autre utilisation fréquente de la directive
+ <directive>Satisfy</directive> est l'allègement des restrictions
+ d'accès à un sous-répertoire par rapport aux restrictions d'accès au
+ répertoire parent :
</p>
<highlight language="config">
</Directory>
</highlight>
- <p>Dans l'exemple ci-dessus, l'accès au répertoire
- <code>/var/www/private</code> nécessitera une authentification,
- alors que l'accès au répertoire <code>/var/www/private/public</code>
- sera accordé sans restriction.</p>
+ <p>Dans l'exemple ci-dessus, l'accès au répertoire
+ <code>/var/www/private</code> nécessitera une authentification,
+ alors que l'accès au répertoire <code>/var/www/private/public</code>
+ sera accordé sans restriction.</p>
<p>Depuis la version 2.0.51, les directives
- <directive>Satisfy</directive> peuvent être restreintes à certaines
- méthodes particulières à l'aide des sections <directive
+ <directive>Satisfy</directive> peuvent être restreintes à certaines
+ méthodes particulières à l'aide des sections <directive
module="core" type="section">Limit</directive> et <directive
module="core" type="section">LimitExcept</directive>.</p>
<note><title>Fusion des sections de configuration</title>
- <p>Lorsqu'une directive fournie par ce module est utilisée dans
- une nouvelle section de configuration, cette dernière n'hérite
- d'aucune directive définie dans une section précédente.</p>
+ <p>Lorsqu'une directive fournie par ce module est utilisée dans
+ une nouvelle section de configuration, cette dernière n'hérite
+ d'aucune directive définie dans une section précédente.</p>
</note>
</usage>
<seealso><directive module="mod_access_compat">Allow</directive></seealso>
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
-<!-- English Revision: 1734260:1737774 (outdated) -->
+<!-- English Revision: 1737774 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
hôte virtuel pour lequel vous souhaitez utiliser des règles
de réécriture.</p>
- <p>Les directives <directive>RewriteMap</directive> du type
+ <p>Les directives <directive module="mod_rewrite">RewriteMap</directive> du type
<code>prg</code> ne sont pas prises en compte au cours de
l'initialisation du serveur si elle ont été définies dans un
contexte où la directive <directive>RewriteEngine</directive> n'a
<p>La directive <directive>RewriteBase</directive> permet de
spécifier le préfixe d'URL à utiliser dans un contexte de
répertoire (htaccess) pour les directives
- <directive>RewriteRule</directive> qui réécrivent vers un chemin
+ <directive module="mod_rewrite">RewriteRule</directive> qui réécrivent vers un chemin
relatif.</p>
<p>Cette directive est <em>obligatoire</em> si vous utilisez un
chemin relatif dans une substitution, et dans un contexte de
une directive telle qu'<directive
module="mod_alias">Alias</directive>).</li>
<li>Le chemin du système de fichiers vers le répertoire
- contenant la <directive>RewriteRule</directive>, suffixé par
+ contenant la <directive module="mod_rewrite">RewriteRule</directive>, suffixé par
la substitution relative est aussi valide en tant qu'URL sur
le serveur (ce qui est rare).</li>
<li>A partir de la version 2.4.11 du serveur HTTP Apache,
en utilisant la variante the <strong>-L</strong> ou
<strong>-h</strong>.</dd>
+ <dt><strong>-ne</strong></dt>
+ <dd>Est numériquement <strong>n</strong>on <strong>é</strong>gal à<br />
+ La <em>Chaîne de test</em> est considérée comme un entier et est
+ numériquement comparée à l'<em>expression de comparaison</em>. Vrai
+ si les deux éléments comparés sont numériquement différents.
+ Equivalent à <code>!-eq</code>.</dd>
+
</dl>
</li>
utiliser avec précautions car les performances du serveur
peuvent s'en trouver affectées !</dd>
- <dt><strong>-H</strong></dt>
+ <dt><strong>-h</strong></dt>
<dd>est un lien symbolique, selon la convention bash<br />
Voir <strong>-l</strong>.</dd>
l'intégralité du
chemin de l'URL dans un contexte de répertoire (htaccess), vous devez
utiliser la variable <code>%{REQUEST_URI}</code> dans la directive
-<directive>RewriteCond</directive>.</li>
+<directive module="mod_rewrite">RewriteCond</directive>.</li>
<li>Le prefixe supprimé se termine toujours par un slash, ce qui
signifie que la comparaison s'effectue avec une chaîne qui ne comporte
seront remplacés par le contenu du <strong>N</strong>ème groupe
du <em>Modèle</em> qui correspondait. Les variables du serveur
sont les mêmes que dans la <em>Chaîne_de_test</em> d'une
- directive <code>RewriteCond</code>. Les fonctions de comparaison
- sont issues de la directive <code>RewriteMap</code> dans la
+ directive <directive module="mod_rewrite">RewriteCond</directive>. Les
+ fonctions de comparaison sont issues de la directive <directive
+ module="mod_rewrite">RewriteMap</directive> dans la
section de laquelle elles sont décrites. Ces trois types de
variables sont évaluées dans l'ordre ci-dessus.</p>
des
<strong><code>[</code><em>drapeaux</em><code>]</code></strong>
comme troisième argument de la directive
- <code>RewriteRule</code>. Séparés par des virgules au sein d'une
+ <directive>RewriteRule</directive>. Séparés par des virgules au sein d'une
liste encadrée par des crochets, les <em>drapeaux</em> peuvent
être choisis dans la table suivante. Vous trouverez plus de
détails, et des exemples pour chaque drapeau dans le <a
-<?xml version="1.0" encoding="ISO-8859-1" ?>
+<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->
-<!-- English Revision: 1686712:1738217 (outdated) -->
+<!-- English Revision: 1738217 -->
<!--
Licensed to the Apache Software Foundation (ASF) under one or more
<manualpage metafile="upgrading.xml.meta">
-<title>Mise à jour de la version 2.2 vers la version 2.4</title>
+<title>Mise à jour de la version 2.2 vers la version 2.4</title>
<summary>
- <p>Afin d'assister les utilisateurs lors de leurs opérations de mise à
+ <p>Afin d'assister les utilisateurs lors de leurs opérations de mise à
jour, nous maintenons un document
- qui comporte des informations critiques à l'attention des personnes qui
- utilisent déjà le serveur HTTP Apache. Ces informations
- ne sont que de brèves notes, et vous
+ qui comporte des informations critiques à l'attention des personnes qui
+ utilisent déjà le serveur HTTP Apache. Ces informations
+ ne sont que de brèves notes, et vous
trouverez plus d'informations dans le document <a
- href="new_features_2_4.html">Nouvelles fonctionnalités</a>, ou dans
- le fichier <code>src/CHANGES</code>. Les développeurs d'applications
- et de modules trouveront un résumé des modifications de l'API dans la
- vue d'ensemble <a href="developer/new_api_2_4.html">Mises à jour de
+ href="new_features_2_4.html">Nouvelles fonctionnalités</a>, ou dans
+ le fichier <code>src/CHANGES</code>. Les développeurs d'applications
+ et de modules trouveront un résumé des modifications de l'API dans la
+ vue d'ensemble <a href="developer/new_api_2_4.html">Mises à jour de
l'API</a>.</p>
- <p>Ce document présente les changements de comportement du serveur qui
- peuvent nécessiter une modification de la configuration, et la manière
- d'utiliser la version 2.4 du serveur en parallèle avec la
- version 2.2. Pour tirer parti des nouvelles fonctionnalités de la
- version 2.4, reportez-vous au document "Nouvelles fonctionnalités".</p>
+ <p>Ce document présente les changements de comportement du serveur qui
+ peuvent nécessiter une modification de la configuration, et la manière
+ d'utiliser la version 2.4 du serveur en parallèle avec la
+ version 2.2. Pour tirer parti des nouvelles fonctionnalités de la
+ version 2.4, reportez-vous au document "Nouvelles fonctionnalités".</p>
- <p>Ce document ne décrit que les modifications intervenues entre les versions
- 2.2 et 2.4. Si vous effectuez une mise à jour depuis la version 2.0, vous
+ <p>Ce document ne décrit que les modifications intervenues entre les versions
+ 2.2 et 2.4. Si vous effectuez une mise à jour depuis la version 2.0, vous
devez aussi consulter le
<a href="http://httpd.apache.org/docs/2.2/upgrading.html">document de mise
- à jour de 2.0 vers 2.2.</a></p>
+ à jour de 2.0 vers 2.2.</a></p>
</summary>
<seealso><a href="new_features_2_4.html">Vue d'ensemble des nouvelles
-fonctionnalités du serveur HTTP Apache 2.4</a></seealso>
+fonctionnalités du serveur HTTP Apache 2.4</a></seealso>
<section id="compile-time">
- <title>Modifications des paramètres de compilation</title>
- <p>Le processus de compilation est très similaire à celui de la
+ <title>Modifications des paramètres de compilation</title>
+ <p>Le processus de compilation est très similaire à celui de la
version 2.2. Dans la plupart des cas, vous pourrez utiliser votre
ancienne ligne de commande <code>configure</code> (telle qu'elle
- est enregistrée dans le fichier <code>build/config.nice</code>
- situé dans le répertoire de compilation du serveur). Voici certains
- changements intervenus dans la configuration par défaut :</p>
+ est enregistrée dans le fichier <code>build/config.nice</code>
+ situé dans le répertoire de compilation du serveur). Voici certains
+ changements intervenus dans la configuration par défaut :</p>
<ul>
- <li>Les modules suivants ont été supprimés : mod_authn_default,
+ <li>Les modules suivants ont été supprimés : mod_authn_default,
mod_authz_default et mod_mem_cache. Si vous utilisiez
mod_mem_cache sous la version 2.2, vous devez maintenant utiliser
<module>mod_cache_disk</module> dans la version 2.4.</li>
- <li>Toutes les implémentations de répartition de charge ont été
- déplacées vers des sous-modules spécifiques de mod_proxy, comme
+ <li>Toutes les implémentations de répartition de charge ont été
+ déplacées vers des sous-modules spécifiques de mod_proxy, comme
<module>mod_lbmethod_bybusyness</module>. Vous devrez compiler et
- chargés tous les modules correspondants que votre configuration
+ chargés tous les modules correspondants que votre configuration
utilise.</li>
<li>Le support de BeOS, TPF, et des anciennes plates-formes telles
- que A/UX, Next, et Tandem a été supprimé, car
- elles ne sont plus considérées comme maintenues.</li>
+ que A/UX, Next, et Tandem a été supprimé, car
+ elles ne sont plus considérées comme maintenues.</li>
- <li>configure: les modules dynamiques (DSO) sont compilés par
- défaut</li>
+ <li>configure: les modules dynamiques (DSO) sont compilés par
+ défaut</li>
- <li>configure: par défaut, seul un jeu de modules de base est
- chargé. Les autres directives <directive>LoadModule</directive>
+ <li>configure: par défaut, seul un jeu de modules de base est
+ chargé. Les autres directives <directive>LoadModule</directive>
sont mises en commentaires dans le fichier de configuration.</li>
- <li>configure: le jeu de modules "most" est compilé par défaut</li>
+ <li>configure: le jeu de modules "most" est compilé par défaut</li>
<li>configure: le jeu de modules "reallyall" ajoute les modules de
- développeur au jeu "all".</li>
+ développeur au jeu "all".</li>
</ul>
</section>
<section id="run-time">
- <title>Modifications de la configuration à l'exécution</title>
+ <title>Modifications de la configuration à l'exécution</title>
<p>Des changements significatifs dans la configuration de
l'autorisation, ainsi que quelques changements mineurs, peuvent
-nécessiter une mise à jour des fichiers de configuration de la version
+nécessiter une mise à jour des fichiers de configuration de la version
2.2 avant de les utiliser sous la version 2.4.</p>
<section id="authz">
<title>Autorisation</title>
- <p>Tout fichier de configuration qui gère des autorisations devra
- probablement être mis à jour.</p>
+ <p>Tout fichier de configuration qui gère des autorisations devra
+ probablement être mis à jour.</p>
<p>Vous devez vous reporter au document <a
- href="howto/auth.html">Authentification, autorisation et contrôle
- d'acc
ès</a>, et plus particulièrement à la section <a
+ href="howto/auth.html">Authentification, autorisation et contrôle
+ d'acc
ès</a>, et plus particulièrement à la section <a
href="howto/auth.html#beyond">Plus loin qu'une simple
- autorisation</a> qui explique les nouveaux mécanismes permettant de
- contrôler l'ordre dans lequel les directives d'autorisation sont
- appliquées.</p>
+ autorisation</a> qui explique les nouveaux mécanismes permettant de
+ contrôler l'ordre dans lequel les directives d'autorisation sont
+ appliquées.</p>
- <p>Les directives qui contrôlent la manière dont les modules
- d'autorisation réagissent lorsqu'ils ne reconnaissent pas
- l'utilisateur authentifié ont été supprimées : elles comprennent les
+ <p>Les directives qui contrôlent la manière dont les modules
+ d'autorisation réagissent lorsqu'ils ne reconnaissent pas
+ l'utilisateur authentifié ont été supprimées : elles comprennent les
directives AuthzLDAPAuthoritative, AuthzDBDAuthoritative,
AuthzDBMAuthoritative, AuthzGroupFileAuthoritative,
AuthzUserAuthoritative et AuthzOwnerAuthoritative. Ces directives
- ont été remplacées par les directives plus explicites <directive
+ ont été remplacées par les directives plus explicites <directive
module="mod_authz_core">RequireAny</directive>, <directive
module="mod_authz_core">RequireNone</directive>, et <directive
module="mod_authz_core">RequireAll</directive>.</p>
<p>Si vous utilisez <module>mod_authz_dbm</module>, vous devez
- mettre à jour votre configuration en remplaçant les directives du
+ mettre à jour votre configuration en remplaçant les directives du
style <code>Require group ...</code> par des directives du style
<code>Require dbm-group ...</code>.</p>
<section id="access">
- <title>Contrôle d'accès</title>
+ <title>Contrôle d'accès</title>
- <p>Dans la version 2.2, le contrôle d'accès basé sur le nom d'hôte
- du client, son adresse IP, ou d'autres caractéristiques de la
- requête était assuré via les directives <directive
+ <p>Dans la version 2.2, le contrôle d'accès basé sur le nom d'hôte
+ du client, son adresse IP, ou d'autres caractéristiques de la
+ requête était assuré via les directives <directive
module="mod_access_compat">Order</directive>, <directive
module="mod_access_compat">Allow</directive>, <directive
module="mod_access_compat">Deny</directive>, et <directive
module="mod_access_compat">Satisfy</directive>.</p>
- <p>Dans la version 2.4, ce contrôle d'accès est assuré, comme tout
- contrôle d'autorisation, par le nouveau module
+ <p>Dans la version 2.4, ce contrôle d'accès est assuré, comme tout
+ contrôle d'autorisation, par le nouveau module
<module>mod_authz_host</module>. Bien que le module
- <module>mod_access_compat</module> soit fourni à des fins de
- compatibilité avec les anciennes configurations, les anciennes
- directives de contrôle d'accès devront être remplacées par les
- nouveaux mécanismes d'authentification.</p>
+ <module>mod_access_compat</module> assure la
+ compatibilité avec les anciennes configurations, les anciennes
+ directives de contrôle d'accès devront être remplacées par les
+ nouveaux mécanismes d'authentification.</p>
- <p>Voici quelques exemples de contrôle d'accès avec l'ancienne et
- la nouvelle méthode :</p>
-
- <p>Dans cet exemple, toutes les requêtes sont rejetées :</p>
+ <note><title>Mélanger anciennes et nouvelles directives</title>
+ <p>Mélanger d'anciennes directives comme <directive
+ module="mod_access_compat">Order</directive>, <directive
+ module="mod_access_compat">Allow</directive> ou <directive
+ module="mod_access_compat">Deny</directive> avec des nouvelles comme
+ <directive module="mod_authz_core">Require</directive> est techniquement
+ possible mais déconseillé. En effet, <module>mod_access_compat</module> a
+ été conçu pour supporter des configurations ne contenant que des anciennes
+ directives afin de faciliter le passage à la version 2.4. Les
+ exemples ci-dessous vous permettront de vous faire une meilleure idée des
+ problèmes qui peuvent survenir.
+ </p>
+ </note>
+
+ <p>Voici quelques exemples de contrôle d'accès avec l'ancienne et
+ la nouvelle méthode :</p>
+
+ <p>Dans cet exemple, toutes les requêtes sont rejetées :</p>
<example>
<title>version 2.2 :</title>
<highlight language="config">
</highlight>
</example>
- <p>Dans cet exemple, toutes les requêtes sont acceptées :</p>
+ <p>Dans cet exemple, toutes les requêtes sont acceptées :</p>
<example>
<title>version 2.2 :</title>
<highlight language="config">
</highlight>
</example>
- <p>Dans l'exemple suivant, tous les hôtes du domaine example.org
- ont l'autorisation d'accès, tous les autres sont rejetés :</p>
+ <p>Dans l'exemple suivant, tous les hôtes du domaine example.org
+ ont l'autorisation d'accès, tous les autres sont rejetés :</p>
<example>
<title>version 2.2 :</title>
Require host example.org
</highlight>
</example>
+
+ <p>Dans l'exemple suivant, le mélange d'anciennes et de nouvelles
+ directives produit des résultats inattendus.</p>
+
+ <example>
+ <title>Mélange d'anciennes et de nouvelles directives : RESULTAT
+ INATTENDU</title>
+ <highlight language="config">
+DocumentRoot "/var/www/html"
+
+<Directory "/">
+ AllowOverride None
+ Order deny,allow
+ Deny from all
+</Directory>
+
+<Location "/server-status">
+ SetHandler server-status
+ Require 127.0.0.1
+</Location>
+
+access.log - GET /server-status 403 127.0.0.1
+error.log - AH01797: client denied by server configuration: /var/www/html/server-status
+ </highlight>
+ </example>
+ <p>Pourquoi httpd interdit l'accès à server-status alors que la
+ configuration semble l'autoriser ? Parce que dans ce scénario de <a
+ href="sections.html#merging">fusion</a> de configuration, les
+ directives de <module>mod_access_compat</module> sont prioritaires par
+ rapport à celles de <module>mod_authz_host</module>.</p>
+
+ <p>L'exemple suivant quant à lui produit un résultat conforme :</p>
+
+ <example>
+ <title>Mélange d'anciennes et de nouvelles directives : RESULTAT
+ CONFORME</title>
+ <highlight language="config">
+DocumentRoot "/var/www/html"
+
+<Directory "/">
+ AllowOverride None
+ Require all denied
+</Directory>
+
+<Location "/server-status">
+ SetHandler server-status
+ Order deny,allow
+ Deny from all
+ Allow From 127.0.0.1
+</Location>
+
+access.log - GET /server-status 200 127.0.0.1
+ </highlight>
+ </example>
+ <p>En conclusion, même si une configuration hybride peut fonctionner,
+ essayez de l'éviter lors de la mise à jour : soit conservez les anciennes
+ directives, puis migrez-les vers les nouvelles ultérieurement, soit
+ effectuez une migration immédiate de toutes les anciennes directives vers
+ les nouvelles.
+ </p>
</section>
</section>
<section id="config">
<title>Autres changements dans la configuration</title>
- <p>D'autres ajustements mineurs peuvent s'avérer nécessaires pour
- certaines configurations particulières, comme décrit ci-dessous.</p>
+ <p>D'autres ajustements mineurs peuvent s'avérer nécessaires pour
+ certaines configurations particulières, comme décrit ci-dessous.</p>
<ul>
- <li><directive>MaxRequestsPerChild</directive> a été renommée en
+ <li><directive>MaxRequestsPerChild</directive> a été renommée en
<directive module="mpm_common">MaxConnectionsPerChild</directive>;
- ce nouveau nom reflète mieux l'usage de cette directive.
- L'ancien nom est encore supporté.</li>
+ ce nouveau nom reflète mieux l'usage de cette directive.
+ L'ancien nom est encore supporté.</li>
<li>La directive <directive>MaxClients</directive> a
- été renommée en <directive
+ été renommée en <directive
module="mpm_common">MaxRequestWorkers</directive>; ce nouveau
- nom reflète mieux l'usage de cette directive. Pour les
+ nom reflète mieux l'usage de cette directive. Pour les
modules multiprocessus asynchrones, comme <module>event</module>, le nombre
- maximal de clients n'est pas équivalent au nombre de threads du
- worker. L'ancien nom est encore supporté.</li>
+ maximal de clients n'est pas équivalent au nombre de threads du
+ worker. L'ancien nom est encore supporté.</li>
<li>La directive <directive
module="core">DefaultType</directive> ne produit plus aucun
- effet, si ce n'est d'émettre un avertissement si elle est
- définie à une valeur autre que <code>none</code>. D'autres
+ effet, si ce n'est d'émettre un avertissement si elle est
+ définie à une valeur autre que <code>none</code>. D'autres
directives de configuration la remplacent dans la version 2.4.
</li>
- <li>La valeur par défaut de la directive <directive
+ <li>La valeur par défaut de la directive <directive
module="core">AllowOverride</directive> est maintenant
<code>None</code>.</li>
- <li>La valeur par défaut de la directive <directive
+ <li>La valeur par défaut de la directive <directive
module="core">EnableSendfile</directive> est maintenant Off.</li>
- <li>La valeur par défaut de la directive <directive
+ <li>La valeur par défaut de la directive <directive
module="core">FileETag</directive> est maintenant "MTime Size"
(sans INode).</li>
<li><module>mod_dav_fs</module>: le format du fichier <directive
- module="mod_dav_fs">DavLockDB</directive> a changé pour les systèmes
+ module="mod_dav_fs">DavLockDB</directive> a changé pour les systèmes
avec inodes. L'ancien fichier <directive
- module="mod_dav_fs">DavLockDB</directive> doit être supprimé dans le
- cadre de la mise à jour.
+ module="mod_dav_fs">DavLockDB</directive> doit être supprimé dans le
+ cadre de la mise à jour.
</li>
<li>La directive <directive module="core">KeepAlive</directive>
n'accepte que les valeurs <code>On</code> ou <code>Off</code>.
- Avant, toute valeur autre que "Off" ou "0" était traitée comme
+ Avant, toute valeur autre que "Off" ou "0" était traitée comme
"On".</li>
<li>Les directives AcceptMutex, LockFile, RewriteLock, SSLMutex,
- SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la
+ SSLStaplingMutex et WatchdogMutexPath ont été remplacées par la
directive unique <directive module="core">Mutex</directive>.
- Vous devez évaluer l'impact de ces directives obsolètes dans
- votre configuration version 2.2 afin de déterminer si elles
- peuvent être simplement supprimées, ou si elles doivent être
- remplacées par la directive <directive
+ Vous devez évaluer l'impact de ces directives obsolètes dans
+ votre configuration version 2.2 afin de déterminer si elles
+ peuvent être simplement supprimées, ou si elles doivent être
+ remplacées par la directive <directive
module="core">Mutex</directive>.</li>
<li><module>mod_cache</module>: la directive <directive
module="mod_cache">CacheIgnoreURLSessionIdentifiers</directive>
- effectue maintenant une correspondance exacte dans la chaîne de
- paramètres au lieu d'une correspondance partielle. Si votre
- configuration mettait en jeu des sous-chaînes comme
- <code>sessionid</code> pour correspondre à
+ effectue maintenant une correspondance exacte dans la chaîne de
+ paramètres au lieu d'une correspondance partielle. Si votre
+ configuration mettait en jeu des sous-chaînes comme
+ <code>sessionid</code> pour correspondre à
<code>/une-application/image.gif;jsessionid=123456789</code>,
- vous devez maintenant utiliser la chaîne de correspondance
- complète <code>jsessionid</code>.
+ vous devez maintenant utiliser la chaîne de correspondance
+ complète <code>jsessionid</code>.
</li>
- <li><module>mod_cache</module>: le second paramètre de la
+ <li><module>mod_cache</module>: le second paramètre de la
directive <directive module="mod_cache">CacheEnable</directive>
- ne concerne les contenus en mandat direct que s'ils débutent par
- le protocole approprié. Dans les versions 2.2 et antérieures, un
- paramètre tel que '/' concernait tous les contenus.</li>
+ ne concerne les contenus en mandat direct que s'ils débutent par
+ le protocole approprié. Dans les versions 2.2 et antérieures, un
+ paramètre tel que '/' concernait tous les contenus.</li>
<li><module>mod_ldap</module>: la directive <directive
module="mod_ldap">LDAPTrustedClientCert</directive> s'utilise
maintenant exclusivement au sein d'une configuration de niveau
- répertoire. Si vous utilisez cette directive, passez en revue
- votre configuration pour vous assurer qu'elle est bien présente
- dans tous les contextes de répertoire nécessaires.</li>
+ répertoire. Si vous utilisez cette directive, passez en revue
+ votre configuration pour vous assurer qu'elle est bien présente
+ dans tous les contextes de répertoire nécessaires.</li>
<li><module>mod_filter</module>: la syntaxe de la directive
<directive module="mod_filter">FilterProvider</directive> utilise
- maintenant une expression booléenne pour déterminer si un filtre
+ maintenant une expression booléenne pour déterminer si un filtre
s'applique.
</li>
<li><module>mod_include</module>:
<ul>
- <li>L'élément <code>#if expr</code> utilise maintenant le
- nouvel <a href="expr.html">interpréteur d'expressions</a>.
- L'ancienne syntaxe peut être réactivée via la directive
+ <li>L'élément <code>#if expr</code> utilise maintenant le
+ nouvel <a href="expr.html">interpréteur d'expressions</a>.
+ L'ancienne syntaxe peut être réactivée via la directive
<directive
module="mod_include">SSILegacyExprParser</directive>.
</li>
- <li>Dans la portée du répertoire, une directive de
- configuration SSI* ne provoque plus la réinitialisation à
- leur valeur par défaut de toutes les directives SSI* de
- niveau répertoire.</li>
+ <li>Dans la portée du répertoire, une directive de
+ configuration SSI* ne provoque plus la réinitialisation à
+ leur valeur par défaut de toutes les directives SSI* de
+ niveau répertoire.</li>
</ul>
</li>
<li><module>mod_charset_lite</module> : l'option
- <code>DebugLevel</code> a été supprimée en faveur d'une
+ <code>DebugLevel</code> a été supprimée en faveur d'une
configuration de la directive <directive
- module="core">LogLevel</directive> au niveau répertoire.
+ module="core">LogLevel</directive> au niveau répertoire.
</li>
<li><module>mod_ext_filter</module> : l'option
- <code>DebugLevel</code> a été supprimée en faveur d'une
+ <code>DebugLevel</code> a été supprimée en faveur d'une
configuration de la directive <directive
- module="core">LogLevel</directive> au niveau répertoire.
+ module="core">LogLevel</directive> au niveau répertoire.
</li>
<li><module>mod_proxy_scgi</module>: certaines applications web
ne fonctionneront plus correctement avec la nouvelle
- configuration de <code>PATH_INFO</code> qui est différente de
+ configuration de <code>PATH_INFO</code> qui est différente de
celle de la version 2.2. La configuration
- précédente peut être
- restaurée en définissant la variable
+ précédente peut être
+ restaurée en définissant la variable
<code>proxy-scgi-pathinfo</code>.</li>
- <li><module>mod_ssl</module>: le contrôle de révocation des
- certificats basé sur les CRL doit être maintenant explicitement
- configuré via la directive <directive
+ <li><module>mod_ssl</module>: le contrôle de révocation des
+ certificats basé sur les CRL doit être maintenant explicitement
+ configuré via la directive <directive
module="mod_ssl">SSLCARevocationCheck</directive>.
</li>
ligne est maintenant 1Mo.
</li>
- <li><module>mod_reqtimeout</module>: si ce module est chargé, il
- définit maintenant certains temps d'attente par défaut.</li>
+ <li><module>mod_reqtimeout</module>: si ce module est chargé, il
+ définit maintenant certains temps d'attente par défaut.</li>
<li><module>mod_dumpio</module>: la directive
- <directive>DumpIOLogLevel</directive> n'est plus supportée. Les
- données sont toujours enregistrées au niveau <code>trace7</code>
+ <directive>DumpIOLogLevel</directive> n'est plus supportée. Les
+ données sont toujours enregistrées au niveau <code>trace7</code>
de <directive module="core">LogLevel</directive></li>
- <li>Jusqu'à la version 2.2, sur les plateformes de style Unix,
- les commandes de redirection des logs définies via <directive
+ <li>Jusqu'à la version 2.2, sur les plateformes de style Unix,
+ les commandes de redirection des logs définies via <directive
module="core">ErrorLog</directive> ou <directive
- module="mod_log_config">CustomLog</directive> étaient invoquées
+ module="mod_log_config">CustomLog</directive> étaient invoquées
en utilisant <code>/bin/sh -c</code>. A
partir de la version 2.4, les commandes de redirection des logs
- sont exécutées directement. Pour retrouver l'ancien
+ sont exécutées directement. Pour retrouver l'ancien
comportement, voir la <a href="logs.html#piped">documentation
sur la redirection des logs</a></li>
<ul>
<li><module>mod_auto_index</module>: extrait maintenant les titres
- et affiche la description pour les fichiers .xhtml qui étaient
- jusqu'alors ignorés.</li>
+ et affiche la description pour les fichiers .xhtml qui étaient
+ jusqu'alors ignorés.</li>
- <li><module>mod_ssl</module> : le format par défaut des variables
- <code>*_DN</code> a changé. Il est cependant encore possible
+ <li><module>mod_ssl</module> : le format par défaut des variables
+ <code>*_DN</code> a changé. Il est cependant encore possible
d'utiliser l'ancien format via la nouvelle option
<code>LegacyDNStringFormat</code> de la directive <directive
module="mod_ssl">SSLOptions</directive>. Le protocole SSLv2 n'est
- plus supporté. Les directives <directive
+ plus supporté. Les directives <directive
module="mod_ssl">SSLProxyCheckPeerCN</directive> et
<directive module="mod_ssl">SSLProxyCheckPeerExpire</directive>
- sont maintenant définies par défaut à On, et les requêtes mandatées
- vers des serveurs HTTPS possèdant des certificats non conformes ou
- périmés échoueront donc avec un code d'erreur 502 (Bad gateway).</li>
+ sont maintenant définies par défaut à On, et les requêtes mandatées
+ vers des serveurs HTTPS possèdant des certificats non conformes ou
+ périmés échoueront donc avec un code d'erreur 502 (Bad gateway).</li>
- <li><program>htpasswd</program> utilise maintenant par défaut les
- condensés MD5 sur toutes les plates-formes.</li>
+ <li><program>htpasswd</program> utilise maintenant par défaut les
+ condensés MD5 sur toutes les plates-formes.</li>
<li>La directive <directive
module="core">NameVirtualHost</directive> n'a plus aucun effet, si
- ce n'est l'émission d'un avertissement. Toute combinaison
+ ce n'est l'émission d'un avertissement. Toute combinaison
adresse/port apparaissant dans plusieurs serveurs virtuels est
- traitée implicitement comme un serveur virtuel basé sur le nom.
+ traitée implicitement comme un serveur virtuel basé sur le nom.
</li>
<li><module>mod_deflate</module> n'effectue plus de compression
- s'il s'aperçoit que la quantité de données ajoutée par la
- compression est supérieure à la quantité de données à compresser.
+ s'il s'aperçoit que la quantité de données ajoutée par la
+ compression est supérieure à la quantité de données à compresser.
</li>
<li>Les pages d'erreur multilingues de la version 2.2.x ne
- fonctionneront qu'après avoir été corrigées pour
- respecter la nouvelle syntaxe de l'élément <code>#if expr=</code>
+ fonctionneront qu'après avoir été corrigées pour
+ respecter la nouvelle syntaxe de l'élément <code>#if expr=</code>
du module <module>mod_include</module>, ou si la directive
<directive module="mod_include">SSILegacyExprParser</directive> a
- été activée pour le répertoire contenant les pages d'erreur.
+ été activée pour le répertoire contenant les pages d'erreur.
</li>
- <li>La fonctionnalité fournie par <code>mod_authn_alias</code>
- dans les précédentes versions (en fait la directive
+ <li>La fonctionnalité fournie par <code>mod_authn_alias</code>
+ dans les précédentes versions (en fait la directive
<directive module="mod_authn_core">AuthnProviderAlias</directive>)
est maintenant fournie par <module>mod_authn_core</module>.
</li>
<li><module>mod_cgid</module> utilise la valeur de la directive
<directive module="core">Timeout</directive> du serveur pour
limiter le temps d'attente entre les sorties d'un programme CGI.
- La valeur de ce temps d'attente peut maintenant être modifiée via
+ La valeur de ce temps d'attente peut maintenant être modifiée via
la directive <directive
module="mod_cgid">CGIDScriptTImeout</directive>.
</li>
<section id="third-party">
<title>Modules tiers</title>
- <p>Tous les modules tiers doivent être recompilés pour la
- version 2.4 avant d'être chargés.</p>
+ <p>Tous les modules tiers doivent être recompilés pour la
+ version 2.4 avant d'être chargés.</p>
- <p>De nombreux modules tiers conçus pour la version 2.2
+ <p>De nombreux modules tiers conçus pour la version 2.2
fonctionneront sans changement avec le serveur HTTP Apache
- version 2.4. Certains nécessiteront cependant des modifications ; se
- reporter
à la vue d'ensemble <a
- href="developer/new_api_2_4.html">Mise à jour de l'API</a>.</p>
+ version 2.4. Certains nécessiteront cependant des modifications ; se
+ reporter
à la vue d'ensemble <a
+ href="developer/new_api_2_4.html">Mise à jour de l'API</a>.</p>
</section>
<section id="commonproblems">
- <title>Problèmes de mise à jour courants</title>
- <ul><li>Erreurs au démarrage :
+ <title>Problèmes de mise à jour courants</title>
+ <ul><li>Erreurs au démarrage :
<ul>
<li><code>Invalid command 'User', perhaps misspelled or defined by
a module not included in the server configuration</code> - chargez
by a module not included in the server configuration</code>, ou
<code>Invalid command 'Order', perhaps misspelled or defined by a
module not included in the server configuration</code> - chargez
- le module <module>mod_access_compat</module>, ou mettez à jour
+ le module <module>mod_access_compat</module>, ou mettez à jour
vers la version 2.4 les directives d'autorisation.</li>
<li><code>Ignoring deprecated use of DefaultType in line NN of
/path/to/httpd.conf</code> - supprimez la directive <directive
module="core">DefaultType</directive> et remplacez-la par les
- directives de configuration appropriées.</li>
+ directives de configuration appropriées.</li>
<li><code>Invalid command 'AddOutputFilterByType', perhaps misspelled
or defined by a module not included in the server configuration
</code> - la directive <directive
- module="mod_filter">AddOutputFilterByType</directive> qui était
- jusqu'alors implémentée par le module core, l'est maintenant par
- le module mod_filter, qui doit donc être chargé.</li>
+ module="mod_filter">AddOutputFilterByType</directive> qui était
+ jusqu'alors implémentée par le module core, l'est maintenant par
+ le module mod_filter, qui doit donc être chargé.</li>
</ul></li>
- <li>Erreurs de traitement des requêtes :
+ <li>Erreurs de traitement des requêtes :
<ul>
<li><code>configuration error: couldn't check user: /path</code> -
chargez le module <module>mod_authn_core</module>.</li>
- <li>Les fichiers <code>.htaccess</code> ne sont pas traités -
- Vérifiez la présence d'une directive <directive
- module="core">AllowOverride</directive> appropriée ; sa valeur par
- défaut est maintenant <code>None</code>.</li>
+ <li>Les fichiers <code>.htaccess</code> ne sont pas traités -
+ Vérifiez la présence d'une directive <directive
+ module="core">AllowOverride</directive> appropriée ; sa valeur par
+ défaut est maintenant <code>None</code>.</li>
</ul>
</li>
</ul>
projects / apache / commitdiff