Authentification et autorisation

Les prérequis -

Les directives décrites dans cet article devront être insérées +

Les prÃ©requis +

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 Directory), soit au niveau de la - configuration des répertoires (fichiers .htaccess)

+ configuration des rÃ©pertoires (fichiers .htaccess)

Si vous envisagez l'utilisation de fichiers .htaccess, la configuration de votre serveur devra permettre l'ajout de directives d'authentification dans ces fichiers. Pour ce faire, on utilise la directive AllowOverride, qui spécifie quelles - directives pourront éventuellement contenir les fichiers de - configuration de niveau répertoire.

+ module="core">AllowOverride, qui spÃ©cifie quelles + directives pourront Ã©ventuellement contenir les fichiers de + configuration de niveau rÃ©pertoire.

Comme il est ici question d'authentification, vous aurez besoin d'une directive AllowOverride @@ -139,47 +139,47 @@ module de chaque groupe.

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.

+ possÃ©der les droits en Ã©criture sur ce fichier.

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 +

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.

Enfin, vous devrez vous assurer que les modules mod_authn_core et mod_authz_core - 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.

Mise en oeuvre -

Nous décrivons ici les bases de la protection par mot de passe - d'un répertoire de votre serveur.

Nous dÃ©crivons ici les bases de la protection par mot de passe + d'un rÃ©pertoire de votre serveur.

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 +

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.

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 +

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 /usr/local/apache/htdocs, vous pouvez enregistrer le fichier des mots de passe dans /usr/local/apache/passwd.

L'utilitaire htpasswd 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 bin 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.

+ installÃ© Apache Ã partir d'un paquetage tiers, il sera probablement + dans le chemin par dÃ©faut de vos exÃ©cutables.

Pour créer le fichier, tapez :

Pour crÃ©er le fichier, tapez :

htpasswd -c /usr/local/apache/passwd/passwords rbowen @@ -196,19 +196,19 @@ module de chaque groupe.

Si htpasswd 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 à /usr/local/apache2/bin/htpasswd.

- -

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 + 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 Ã /usr/local/apache2/bin/htpasswd.

+ +

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 httpd.conf, soit utiliser un fichier - .htaccess. Par exemple, si vous voulez protéger le - répertoire /usr/local/apache/htdocs/secret, vous pouvez + .htaccess. Par exemple, si vous voulez protÃ©ger le + rÃ©pertoire /usr/local/apache/htdocs/secret, vous pouvez utiliser les directives suivantes, soit dans le fichier /usr/local/apache/htdocs/secret/.htaccess, soit dans le - fichier httpd.conf à l'intérieur d'une section <Directory + fichier httpd.conf Ã l'intÃ©rieur d'une section <Directory "/usr/local/apache/htdocs/secret"> :

@@ -220,106 +220,106 @@ AuthUserFile "/usr/local/apache/passwd/p Require user rbowen -

Examinons ces directives une à une. La directive AuthType définit la méthode - utilisée pour authentifier l'utilisateur. La méthode la plus - courante est Basic, et elle est implémentée par - mod_auth_basic. Il faut cependant garder à l'esprit +

Examinons ces directives une Ã une. La directive AuthType dÃ©finit la mÃ©thode + utilisÃ©e pour authentifier l'utilisateur. La mÃ©thode la plus + courante est Basic, et elle est implÃ©mentÃ©e par + mod_auth_basic. 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 mod_ssl. Apache - supporte une autre méthode d'authentification : AuthType - Digest. Cette méthode est implémentée - par le module mod_auth_digest 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 mod_ssl. Apache + supporte une autre mÃ©thode d'authentification : AuthType + Digest. Cette mÃ©thode est implÃ©mentÃ©e + par le module mod_auth_digest 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 mod_ssl.

La directive AuthName définit - l'Identificateur (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.

- -

Ainsi par exemple, une fois un client authentifié dans la zone - "Fichiers réservés", il soumettra à nouveau - automatiquement le même mot de passe pour toute zone du même serveur - marquée de l'identificateur "Fichiers réservés". 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é.

+ module="mod_authn_core">AuthName dÃ©finit + l'Identificateur (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.

+ +

Ainsi par exemple, une fois un client authentifiÃ© dans la zone + "Fichiers rÃ©servÃ©s", il soumettra Ã nouveau + automatiquement le mÃªme mot de passe pour toute zone du mÃªme serveur + marquÃ©e de l'identificateur "Fichiers rÃ©servÃ©s". 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Ã©.

La directive AuthBasicProvider est, dans ce - cas, facultative, car file est la valeur par défaut + cas, facultative, car file est la valeur par dÃ©faut pour cette directive. Par contre, cette directive sera obligatoire si vous utilisez une autre source d'authentification comme mod_authn_dbm ou mod_authn_dbd.

La directive AuthUserFile définit le chemin - du fichier de mots de passe que nous venons de créer avec - htpasswd. 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 dÃ©finit le chemin + du fichier de mots de passe que nous venons de crÃ©er avec + htpasswd. 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 mod_authn_dbm fournit la directive AuthDBMUserFile. Les programmes dbmmanage et htdbm 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 Base de données des modules + href="http://modules.apache.org/">Base de donnÃ©es des modules d'Apache.

Enfin, la directive Require 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 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 Require.

Autorisation d'accès à +<section id="lettingmorethanonepersonin"><title>Autorisation d'accÃ¨s Ã plusieurs personnes

Les directives ci-dessus n'autorisent qu'une personne (quelqu'un - possédant le nom d'utilisateur rbowen) à 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 rbowen) Ã 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 AuthGroupFile.

Si vous voulez autoriser l'accès à plusieurs personnes, vous - devez créer un fichier de groupes qui associe des noms de groupes +

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 :

+ est trÃ¨s simple, et vous pouvez le crÃ©er avec votre Ã©diteur favori. + Son contenu se prÃ©sente comme suit :

Nom-de-groupe: rbowen dpitts sungo rshersey

Il s'agit simplement une liste des membres du groupe sous la - forme d'une ligne séparée par des espaces.

+ forme d'une ligne sÃ©parÃ©e par des espaces.

Pour ajouter un utilisateur à votre fichier de mots de passe - préexistant, entrez :

Pour ajouter un utilisateur Ã votre fichier de mots de passe + prÃ©existant, entrez :

htpasswd /usr/local/apache/passwd/passwords dpitts -

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 -c qui permet de créer un nouveau fichier de +

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 -c qui permet de crÃ©er un nouveau fichier de mots de passe)..

Maintenant, vous devez modifier votre fichier @@ -336,65 +336,65 @@ Require group GroupName

Maintenant, quiconque appartient au groupe - Nom-de-groupe, et possède une entrée dans le fichier - password pourra accéder au répertoire s'il tape le bon + Nom-de-groupe, et possÃ¨de une entrÃ©e dans le fichier + password pourra accÃ©der au rÃ©pertoire s'il tape le bon mot de passe.

Il existe une autre méthode moins contraignante pour autoriser - l'accès à plusieurs personnes. Plutôt que de créer un fichier de +

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 :

Require valid-user

Le remplacement de la ligne Require user rbowen par - la ligne Require valid-user 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 Require valid-user 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 AuthUserFile.

Problèmes possibles -

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 +

ProblÃ¨mes possibles +

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.

+ 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.

En conséquence, ce ralentissement impose une limite pratique au +

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.

+ d'utilisateurs, et serez alors appelÃ©s Ã utiliser une mÃ©thode + d'authentification diffÃ©rente.

Autre méthode de stockage des mots de +<section id="dbmdbd"><title>Autre mÃ©thode de stockage des mots de passe -

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.

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.

Pour y parvenir, on peut utiliser les modules mod_authn_dbm ou mod_authn_dbd. Vous pouvez choisir comme format de stockage dbm ou - dbd à la place de file pour la directive + dbd Ã la place de file pour la directive AuthBasicProvider.

Par exemple, pour sélectionner un fichier dbm à la place d'un +

Par exemple, pour sÃ©lectionner un fichier dbm Ã la place d'un fichier texte :

@@ -408,18 +408,18 @@ passe

D'autres options sont disponibles. Consultez la documentation de - mod_authn_dbm pour plus de détails.

+ mod_authn_dbm pour plus de dÃ©tails.

Utilisation de plusieurs fournisseurs d'authentification -

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 +

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 :

@@ -436,18 +436,18 @@ d'authentification

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.

+ basÃ©e sur un fichier de mots de passe peut permettre l'attribution + d'autorisations basÃ©e sur un annuaire LDAP.

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 +

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.

@@ -463,46 +463,46 @@ d'authentification </Directory> -

Pour un scénario d'autorisation un peu plus avancé, des +

Pour un scÃ©nario d'autorisation un peu plus avancÃ©, des directives de conteneur d'autorisation comme RequireAll et RequireAny 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 Conteneurs - d'autorisations pour un exemple de ce contrôle.

+ d'autorisations pour un exemple de ce contrÃ´le.

Pour aller plus loin qu'une simple autorisation -

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.

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.

Appliquer logique et ordonnancement -

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 +

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 - Require 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 + Require 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 Require apparaissent dans la configuration.

@@ -512,56 +512,56 @@ autorisation type="section">RequireAll et RequireAny, 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 Conteneurs - d'autorisations pour un exemple de la manière de les + d'autorisations pour un exemple de la maniÃ¨re de les utiliser pour exprimer des logiques d'autorisation complexes.

Par défaut, toutes les directives Par dÃ©faut, toutes les directives Require sont - traitées comme si elles étaient contenues dans une directive + traitÃ©es comme si elles Ã©taient contenues dans une directive RequireAny. En d'autres termes, il suffit - qu'une méthode d'autorisation s'applique avec succès pour que - l'autorisation soit accordée.

+ qu'une mÃ©thode d'autorisation s'applique avec succÃ¨s pour que + l'autorisation soit accordÃ©e.

Utilisation de fournisseurs - d'autorisation pour le contrôle d'accès -

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 +

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.

Les fournisseurs d'autorisation all, env, host et ip 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.

+ 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.

L'utilisation de ces fournisseurs est spécifiée à l'aide de +

L'utilisation de ces fournisseurs est spÃ©cifiÃ©e Ã l'aide de la directive Require. 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 :

+ seront appelÃ©s dans le processus d'autorisation au cours du + traitement de la requÃªte. Par exemple :

Require ip address -

où adresse est une adresse IP (ou une adresse IP +

oÃ¹ adresse est une adresse IP (ou une adresse IP partielle) ou :

Require host domain_name -

où nom_domaine 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.

oÃ¹ nom_domaine 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.

Par exemple, si vous voulez rejeter les spams dont une machine vous inonde, vous pouvez utiliser ceci :

@@ -574,7 +574,7 @@ autorisation

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 :

@@ -585,8 +585,8 @@ autorisation </RequireAll> -

Et si vous voulez interdire l'accès à toutes les machines - d'un domaine, vous pouvez spécifier une partie seulement de +

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 :

@@ -601,61 +601,76 @@ autorisation

L'utilisation de la directive RequireAll avec de multiples directives Require, toutes avec la négation - not, 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.

+ type="section">Require, toutes avec la nÃ©gation + not, 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.

Compatibilité ascendante du contrôle - d'accès -

L'adoption d'un mécanisme à base de fournisseurs pour - l'authentification, a pour effet colatéral de rendre inutiles +

CompatibilitÃ© ascendante du contrÃ´le + d'accÃ¨s +

L'adoption d'un mÃ©canisme Ã base de fournisseurs pour + l'authentification, a pour effet colatÃ©ral de rendre inutiles les directives Order, Allow, Deny et Satisfy. 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. Cependant, et Ã + des fins de compatibilitÃ© ascendante vers les anciennes + configurations, ces directives ont Ã©tÃ© dÃ©placÃ©es vers le module mod_access_compat.

+ Note +

Les directives fournies par le module + mod_access_compat sont devenues obsolÃ¨tes depuis + la refonte du module mod_authz_host. MÃ©langer d'anciennes + directives comme Order, Allow ou Deny avec des nouvelles comme + Require est techniquement + possible mais dÃ©conseillÃ©. En effet, mod_access_compat 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 + upgrading pour plus de dÃ©tails. +

Mise en cache de l'authentification

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 mod_authn_dbd (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, mod_authn_socache, 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.

Cette mise en cache apportera un gain en performance substantiel - à certains utilisateurs.

+ Ã certains utilisateurs.

Pour aller plus loin . . .

Vous pouvez aussi lire la documentation de mod_auth_basic et mod_authz_host - 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 AuthnProviderAlias.

Les différents algorithmes de chiffrement supportés par Apache - pour authentifier les données sont expliqués dans Les diffÃ©rents algorithmes de chiffrement supportÃ©s par Apache + pour authentifier les donnÃ©es sont expliquÃ©s dans PasswordEncryptions.

Enfin vous pouvez consulter la recette Contrôle - d'accès, qui décrit un certain nombre de situations en relation +

Enfin vous pouvez consulter la recette ContrÃ´le + d'accÃ¨s, qui dÃ©crit un certain nombre de situations en relation avec le sujet.

Modified: httpd/httpd/trunk/docs/manual/mod/mod_access_compat.xml.fr URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/mod_access_compat.xml.fr?rev=1738361&r1=1738360&r2=1738361&view=diff ============================================================================== --- httpd/httpd/trunk/docs/manual/mod/mod_access_compat.xml.fr (original) +++ httpd/httpd/trunk/docs/manual/mod/mod_access_compat.xml.fr Sat Apr 9 16:19:31 2016 @@ -1,7 +1,7 @@ - + - + @@ -25,15 +25,15 @@ mod_access_compat -Autorisations de groupe à base de nom d'hôte (nom ou +Autorisations de groupe Ã base de nom d'hÃ´te (nom ou adresse IP) Extension mod_access_compat.c access_compat_module 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 mod_authz_host

@@ -44,46 +44,56 @@ ce module sont devenues obsolètes Location, ainsi que dans les fichiers .htaccess 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 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 variables d'environnement. Les directives Allow et Deny permettent de spécifier - quels clients sont ou ne sont pas autorisés à accéder au serveur, + module="mod_access_compat">Deny permettent de spÃ©cifier + quels clients sont ou ne sont pas autorisÃ©s Ã accÃ©der au serveur, alors que la directive Order définit le statut - d'accès par défaut, et détermine la manière dont les directives + module="mod_access_compat">Order dÃ©finit le statut + d'accÃ¨s par dÃ©faut, et dÃ©termine la maniÃ¨re dont les directives Allow et Deny interagissent entre elles.

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 Satisfy pour déterminer la - manière dont ces deux modes de restrictions interagissent.

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 Satisfy pour dÃ©terminer la + maniÃ¨re dont ces deux modes de restrictions interagissent.

Note

Les directives fournies par le module - mod_access_compat sont devenues obsolètes depuis - la refonte d'authz. Voir mod_authz_host.

+ mod_access_compat sont devenues obsolÃ¨tes depuis + la refonte du module mod_authz_host. MÃ©langer d'anciennes + directives comme Order, Allow ou Deny avec des nouvelles comme + Require est techniquement + possible mais dÃ©conseillÃ©. En effet, mod_access_compat 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 + upgrading pour plus de dÃ©tails. +

En général, les directives de restriction d'accès s'appliquent à - toutes les méthodes d'accès (GET, PUT, +

En gÃ©nÃ©ral, les directives de restriction d'accÃ¨s s'appliquent Ã + toutes les mÃ©thodes d'accÃ¨s (GET, PUT, POST, 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 Limit.

Fusion des sections de configuration -

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.

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.

@@ -93,30 +103,30 @@ ce module sont devenues obsolètes Allow -Spécifie quels hôtes peuvent accéder à une certaine zone du +SpÃ©cifie quels hÃ´tes peuvent accÃ©der Ã une certaine zone du serveur - Allow from all|hôte|env=[!]variable + Allow from all|hÃ´te|env=[!]variable d'environnement -[hôte|env=[!]variable d'environnement] ... +[hÃ´te|env=[!]variable d'environnement] ... directory.htaccess Limit -

La directive Allow 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.

La directive Allow 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.

Le premier argument de cette directive est toujours from. Les arguments suivants peuvent prendre trois - formes différentes. Si Allow from all est spécifié, - tout hôte se voit accordé l'accès, en tenant compte des directives + formes diffÃ©rentes. Si Allow from all est spÃ©cifiÃ©, + tout hÃ´te se voit accordÃ© l'accÃ¨s, en tenant compte des directives Deny et Order 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 nom d'hôte sous + module="mod_access_compat">Order 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 nom d'hÃ´te sous une des formes suivantes :

Une adresse IP complète
Une adresse IP complÃ¨te: Allow from 10.1.2.3 Allow from 192.168.1.104 192.168.1.205 -
L'adresse IP d'un hôte auquel on a accordé l'accès
Une adresse IP partielle
Une paire réseau/masque de sous-réseau
Une paire rÃ©seau/masque de sous-rÃ©seau: Allow from 10.1.0.0/255.255.0.0 -
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.
Une spécification CIDR réseau/nnn
Une spÃ©cification CIDR rÃ©seau/nnn: Allow from 10.1.0.0/16 -
Identique au cas précédent, mis à part que le masque est - constitué des nnn bits de poids fort.

Notez que les trois derniers exemples désignent le même ensemble - d'hôtes.

On peut spécifier des adresses et sous-réseaux IPv6 de la manière +

@@ -193,23 +203,23 @@ Allow from 2001:db8::a00:20ff:fea7:ccea Allow from 2001:db8::a00:20ff:fea7:ccea/10 -

Le troisième format d'argument de la directive - Allow permet de contrôler l'accès au serveur +

Le troisiÃ¨me format d'argument de la directive + Allow permet de contrÃ´ler l'accÃ¨s au serveur en fonction de l'existence d'une variable d'environnement. Lorsque Allow - from env=variable d'environnement est spécifié, la - requête est autorisée si la variable d'environnement variable + from env=variable d'environnement est spÃ©cifiÃ©, la + requÃªte est autorisÃ©e si la variable d'environnement variable d'environnement existe. En revanche, lorsque Allow from - env=!env-variable est spécifié, la - requête est autorisée si la variable d'environnement variable - d'environnement n'existe pas. Le serveur permet de définir + env=!env-variable est spÃ©cifiÃ©, la + requÃªte est autorisÃ©e si la variable d'environnement variable + d'environnement 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 mod_setenvif. Ainsi, on peut utiliser la directive Allow pour permettre - l'accès en fonction de paramètres comme le User-Agent + l'accÃ¨s en fonction de paramÃ¨tres comme le User-Agent (type de navigateur) des clients, le Referer, ou - d'autres champs d'en-tête de la requête HTTP.

+ d'autres champs d'en-tÃªte de la requÃªte HTTP.

SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in @@ -220,32 +230,32 @@ SetEnvIf User-Agent ^KnockKnock/2\.0 let </Directory> -

Dans cet exemple, les navigateurs dont la chaîne user-agent +

Dans cet exemple, les navigateurs dont la chaÃ®ne user-agent commence par KnockKnock/2.0 se verront accorder - l'accès, alors que tous les autres seront rejetés.

Fusion des sections de configuration -

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.

Deny -Définit quels hôtes ne sont pas autorisés à accéder au +DÃ©finit quels hÃ´tes ne sont pas autorisÃ©s Ã accÃ©der au serveur - Deny from all|hôte|env=[!]variable + Deny from all|hÃ´te|env=[!]variable d'environnement -[hôte|env=[!]variable d'environnement] ... +[hÃ´te|env=[!]variable d'environnement] ... directory.htaccess Limit -

Cette directive permet de restreindre l'accès au serveur en - fonction du nom d'hôte, de l'adresse IP ou de variables +

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 Deny sont identiques aux arguments de la directive Order -Définit le statut d'accès par défaut et l'ordre dans lequel +DÃ©finit le statut d'accÃ¨s par dÃ©faut et l'ordre dans lequel les directives Allow et -Deny sont évaluées. +Deny sont Ã©valuÃ©es. Order ordre Order Deny,Allow directory.htaccess @@ -266,98 +276,98 @@ les directives Allow -

La directive Order, associée aux +

La directive Order, associÃ©e aux directives Allow et Deny, - 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 Allow, soit toutes les directives Deny qui sont traitées, selon - la définition de la directive Deny qui sont traitÃ©es, selon + la dÃ©finition de la directive Order. Le reste des directives (Deny ou Allow) 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.

+ 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.

Notez que toutes les directives Allow et Deny 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 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 Allow sont considérées comme + module="mod_access_compat">Allow sont considÃ©rÃ©es comme un groupe, toutes les lignes Deny comme un autre, et le - statut par défaut a son existence propre.

Ordre peut être :

Ordre peut Ãªtre :

Allow,Deny: Dans un premier temps, toutes les directives Allow sont évaluées ; au - moins une d'entre elles doit correspondre, sinon la requête est - rejetée. Ensuite, toutes les directives Deny 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 sont Ã©valuÃ©es ; au + moins une d'entre elles doit correspondre, sinon la requÃªte est + rejetÃ©e. Ensuite, toutes les directives Deny 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 Allow ou - Deny est rejetée - par défaut.
Deny,Allow: Dans un premier temps, toutes les directives Deny sont évaluées ; Si au - moins une d'entre elles correspond, la requête est rejetée, - à moins qu'elle corresponde aussi à une directive + module="mod_access_compat">Deny sont Ã©valuÃ©es ; Si au + moins une d'entre elles correspond, la requÃªte est rejetÃ©e, + Ã moins qu'elle corresponde aussi Ã une directive Allow. Toute - requête qui ne correspond à aucune directive Allow ou Deny est autorisée.
Mutual-failure: Cet argument a le même effet que Allow,Deny et - est devenu de ce fait obsolète.; Cet argument a le mÃªme effet que Allow,Deny et + est devenu de ce fait obsolÃ¨te.

Les mots-clés ne peuvent être séparés que par des virgules ; +

- - + + - - - + + + - - - + + + - - + + - - - + + +

Match	Résultat Allow,Deny	Résultat Deny,Allow	RÃ©sultat Allow,Deny	RÃ©sultat Deny,Allow
Correspond à Allow seulement	Requête autorisée	Requête autorisée	Correspond Ã Allow seulement	RequÃªte autorisÃ©e	RequÃªte autorisÃ©e
Correspond à Deny seulement	Requête rejetée	Requête rejetée	Correspond Ã Deny seulement	RequÃªte rejetÃ©e	RequÃªte rejetÃ©e
Aucune correspondance	Par défaut la seconde directive : rejet	Par défaut la seconde directive : autorisation	Par dÃ©faut la seconde directive : rejet	Par dÃ©faut la seconde directive : autorisation
Correspond à Allow & Deny	La dernière correspondance l'emporte : rejet	La dernière correspondance l'emporte : autorisation	Correspond Ã Allow & Deny	La derniÃ¨re correspondance l'emporte : rejet	La derniÃ¨re correspondance l'emporte : autorisation

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é.

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Ã©.

Order Deny,Allow @@ -365,13 +375,13 @@ Deny from all Allow from example.org -

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é +

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 Deny, et consiste donc en un - refus d'accès.

+ refus d'accÃ¨s.

Order Allow,Deny @@ -380,24 +390,24 @@ Deny from foo.example.org

Par contre, si la valeur de la directive - Order, dans l'exemple précédent, est - Deny,Allow, tout le monde a l'autorisation d'accès. - Ceci est dû au fait que Allow from example.org sera - évalué en dernier, sans tenir compte de l'ordre réel dans lequel les + Order, dans l'exemple prÃ©cÃ©dent, est + Deny,Allow, tout le monde a l'autorisation d'accÃ¨s. + Ceci est dÃ» au fait que Allow from example.org 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 Deny from foo.example.org. Tout hôte qui + l'emporter sur Deny from foo.example.org. Tout hÃ´te qui n'est pas dans le domaine example.org 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 Allow et constitue donc une - autorisation d'accès.

+ autorisation d'accÃ¨s.

La présence d'une directive Order peut - affecter le contrôle d'accès à une partie du serveur même en +

La prÃ©sence d'une directive Order peut + affecter le contrÃ´le d'accÃ¨s Ã une partie du serveur mÃªme en l'abscence de directives Allow et Deny associées, à cause de - son influence sur le statut par défaut. Par exemple,

<Directory "/www"> @@ -405,39 +415,39 @@ Deny from foo.example.org </Directory> -

va interdire tout accès au répertoire /www à cause - du statut d'accès par défaut qui est défini à va interdire tout accÃ¨s au rÃ©pertoire /www Ã cause + du statut d'accÃ¨s par dÃ©faut qui est dÃ©fini Ã Deny.

La directive Order ne contrôle l'ordre - dans lequel sont traitées les directives d'accès qu'au cours de +

La directive Order 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 Allow ou Deny située dans une section + module="mod_access_compat">Deny situÃ©e dans une section Location sera - toujours évaluée après une directive Allow ou Deny située dans une section + module="mod_access_compat">Deny situÃ©e dans une section Directory ou un fichier .htaccess, sans tenir compte de la - définition de la directive Order. Pour plus - de détails à propos de la fusion des sections de configuration, voir + dÃ©finition de la directive Order. Pour plus + de dÃ©tails Ã propos de la fusion des sections de configuration, voir le document Comment fonctionnent les sections Directory, Location et Files.

Fusion des sections de configuration -

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.

Satisfy -Interaction entre le contrôle d'accès en fonction de l'hôte +Interaction entre le contrÃ´le d'accÃ¨s en fonction de l'hÃ´te et l'authentification utilisateur Satisfy Any|All Satisfy All @@ -445,26 +455,26 @@ et l'authentification utilisateur AuthConfig -

Politique d'accès dans le cas où on utilise à la fois Politique d'accÃ¨s dans le cas oÃ¹ on utilise Ã la fois Allow et Require. L'argument est soit All, soit Any. 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 (All), le client doit satisfaire à la + de l'adresse IP de l'hÃ´te client. Dans ce cas, par + dÃ©faut (All), le client doit satisfaire Ã la restriction d'adresse, et fournir un couple utilisateur/mot de passe valide. Avec l'argument Any, - 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.

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 :

@@ -474,10 +484,10 @@ Satisfy Any

- Une autre utilisation fréquente de la directive - Satisfy 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 + Satisfy est l'allÃ¨gement des restrictions + d'accÃ¨s Ã un sous-rÃ©pertoire par rapport aux restrictions d'accÃ¨s au + rÃ©pertoire parent :

@@ -491,22 +501,22 @@ Satisfy Any </Directory> -

Dans l'exemple ci-dessus, l'accès au répertoire - /var/www/private nécessitera une authentification, - alors que l'accès au répertoire /var/www/private/public - sera accordé sans restriction.

Dans l'exemple ci-dessus, l'accÃ¨s au rÃ©pertoire + /var/www/private nÃ©cessitera une authentification, + alors que l'accÃ¨s au rÃ©pertoire /var/www/private/public + sera accordÃ© sans restriction.

Depuis la version 2.0.51, les directives - Satisfy peuvent être restreintes à certaines - méthodes particulières à l'aide des sections Satisfy peuvent Ãªtre restreintes Ã certaines + mÃ©thodes particuliÃ¨res Ã l'aide des sections Limit et LimitExcept.

Fusion des sections de configuration -

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.

Allow