From: Lucien Gentis Date: Sat, 2 Apr 2016 16:20:05 +0000 (+0000) Subject: XML updates. X-Git-Tag: 2.5.0-alpha~1789 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8d82fe51665d360817d223ea6aaa9519ea67eeb3;p=thirdparty%2Fapache%2Fhttpd.git XML updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1737515 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/howto/index.xml.fr b/docs/manual/howto/index.xml.fr index 27508c68cd5..27c36804ba9 100644 --- a/docs/manual/howto/index.xml.fr +++ b/docs/manual/howto/index.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -34,25 +34,25 @@
Authentification et autorisation
-

L'authentification représente tout processus par lequel vous - vérifiez si quelqu'un correspond bien à l'identité qu'il - déclare posséder. L'autorisation représente tout processus - permettant de savoir si une personne est autorisée à aller là où - elle veut aller, ou à obtenir les informations qu'elle demande.

+

L'authentification représente tout processus par lequel vous + vérifiez si quelqu'un correspond bien à l'identité qu'il + déclare posséder. L'autorisation représente tout processus + permettant de savoir si une personne est autorisée à aller là où + elle veut aller, ou à obtenir les informations qu'elle demande.

Voir Authentification, Autorisation

-
Contrôle d'accès
+
Contrôle d'accès
-

Le contrôle d'accès se réfère au processus permettant - d'interdire ou d'accorder l'accès à une ressource en fonction de - certains critères, et il existe de nombreuses façons d'y +

Le contrôle d'accès se réfère au processus permettant + d'interdire ou d'accorder l'accès à une ressource en fonction de + certains critères, et il existe de nombreuses façons d'y parvenir.

-

Voir Contrôle d'accès

+

Voir Contrôle d'accès

@@ -60,13 +60,13 @@
Contenu dynamique avec CGI

L'Interface Passerelle Commune CGI (Common Gateway Interface) - définit pour le serveur web une méthode d'interaction avec des - programmes externes générateurs de contenu, souvent nommés - programmes CGI ou scripts CGI. Il s'agit d'une méthode + définit pour le serveur web une méthode d'interaction avec des + programmes externes générateurs de contenu, souvent nommés + programmes CGI ou scripts CGI. Il s'agit d'une méthode simple permettant d'ajouter du contenu - dynamique à votre site web. Ce document se veut une introduction - à la configuration de CGI sur votre serveur web Apache et à - l'écriture de programmes CGI.

+ dynamique à votre site web. Ce document se veut une introduction + à la configuration de CGI sur votre serveur web Apache et à + l'écriture de programmes CGI.

Voir CGI : contenu dynamique

@@ -76,24 +76,40 @@
Fichiers .htaccess

Les fichiers .htaccess permettent de modifier la - configuration du serveur au niveau de chaque répertoire. À cet - effet, un fichier est placé dans un répertoire particulier du site - web, et les directives de configuration qu'il contient s'appliquent à ce - répertoire et à tous ses sous-répertoires.

+ configuration du serveur au niveau de chaque répertoire. À cet + effet, un fichier est placé dans un répertoire particulier du site + web, et les directives de configuration qu'il contient s'appliquent à ce + répertoire et à tous ses sous-répertoires.

Voir Fichiers .htaccess

-
Introduction au Inclusions côté Serveur (Server Side Includes +
HTTP/2 avec httpd
+
+

HTTP/2 est une évolution du protocole de la couche application le plus + connu au monde, HTTP. Les efforts se sont concentrés sur une amélioration + de l'efficacité de l'utilisation des ressources réseau sans modifier la + sémantique de HTTP. Ce guide explique la manière dont HTTP/2 est + implémenté dans httpd, donne des conseils pour une configuration de base + ainsi qu'une liste de recommandations. +

+ +

Voir le guide HTTP/2

+
+
+ + +
+
Introduction au Inclusions côté Serveur (Server Side Includes ou SSI)

Les SSI sont des directives que l'on place dans des pages - HTML, et qui sont évaluées par le serveur lorsque ces pages sont - servies. Elles vous permettent d'ajouter du contenu généré - dynamiquement à une page HTML existante, sans avoir à servir - l'intégralité de la page via un programme CGI, ou toute autre + HTML, et qui sont évaluées par le serveur lorsque ces pages sont + servies. Elles vous permettent d'ajouter du contenu généré + dynamiquement à une page HTML existante, sans avoir à servir + l'intégralité de la page via un programme CGI, ou toute autre technologie dynamique.

Voir Server Side Includes (SSI)

@@ -101,20 +117,20 @@
-
Répertoires web de l'utilisateur
+
Répertoires web de l'utilisateur
-

Sur les systèmes multi-utilisateurs, vous pouvez laisser - chaque utilisateur disposer d'un site web dans son répertoire home +

Sur les systèmes multi-utilisateurs, vous pouvez laisser + chaque utilisateur disposer d'un site web dans son répertoire home via la directive UserDir. Les visiteurs de l'URL http://example.com/~nom-utilisateur/ vont recevoir - du contenu situé dans le répertoire home de l'utilisateur - "nom-utilisateur", et dans le sous-répertoire - spécifié par la directive nom-utilisateur", et dans le sous-répertoire + spécifié par la directive UserDir.

Voir Répertoires web des utilisateurs (public_html)

+ >Répertoires web des utilisateurs (public_html)

diff --git a/docs/manual/mod/core.xml.fr b/docs/manual/mod/core.xml.fr index 869faa2be68..a80240d0950 100644 --- a/docs/manual/mod/core.xml.fr +++ b/docs/manual/mod/core.xml.fr @@ -1,7 +1,7 @@ - + @@ -1442,12 +1442,12 @@ host l'interprétation de toute expression. Exemples :

-ErrorDocument 500 http://foo.example.com/cgi-bin/tester -ErrorDocument 404 /cgi-bin/bad_urls.pl +ErrorDocument 500 http://example.com/cgi-bin/server-error.cgi +ErrorDocument 404 /errors/bad_urls.php ErrorDocument 401 /subscription_info.html ErrorDocument 403 "Désolé, nous ne pouvons pas vous accorder l'accès aujourd'hui" ErrorDocument 403 Forbidden! -ErrorDocument 403 /cgi-bin/forbidden.pl?referrer=%{escape:%{HTTP_REFERER}} +ErrorDocument 403 /errors/forbidden.py?referrer=%{escape:%{HTTP_REFERER}}

De plus, on peut spécifier la valeur spéciale default diff --git a/docs/manual/mod/mod_authnz_ldap.xml.fr b/docs/manual/mod/mod_authnz_ldap.xml.fr index a69d14ad745..403b3d192bf 100644 --- a/docs/manual/mod/mod_authnz_ldap.xml.fr +++ b/docs/manual/mod/mod_authnz_ldap.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -36,29 +36,29 @@ HTTP de base. mod_auth_basic d'authentifier les utilisateurs via un annuaire ldap.

-

mod_authnz_ldap supporte les fonctionnalités +

mod_authnz_ldap supporte les fonctionnalités suivantes :

Lorsqu'on utilise mod_auth_basic, ce module est - invoqué en affectant la valeur ldap à la directive + invoqué en affectant la valeur ldap à la directive AuthBasicProvider.

@@ -70,8 +70,8 @@ HTTP de base.
Sommaire
-
Mises en garde à caractère général -

Ce module effectue une mise en cache des résultats du processus +

Mises en garde à caractère général +

Ce module effectue une mise en cache des résultats du processus d'authentification et d'autorisation en fonction de la configuration du -module mod_ldap. Les modifications effectuées au niveau -du serveur LDAP d'arrière-plan comme les -verrouillages ou révocations d'utilisateurs, les changements de mot de -passe, ou les changements d'appartenance à un groupe (et cette liste -n'est pas exhaustive), ne seront pas immédiatement propagées jusqu'au +module mod_ldap. Les modifications effectuées au niveau +du serveur LDAP d'arrière-plan comme les +verrouillages ou révocations d'utilisateurs, les changements de mot de +passe, ou les changements d'appartenance à un groupe (et cette liste +n'est pas exhaustive), ne seront pas immédiatement propagées jusqu'au serveur HTTP. Consultez les directives du module -mod_ldap pour plus de détails à propos de la +mod_ldap pour plus de détails à propos de la configuration de la mise en cache.

-
Mode opératoire +
Mode opératoire -

L'utilisateur se voit accorder l'accès selon un processus en deux - phases. La première phase est l'authentification, au cours de +

L'utilisateur se voit accorder l'accès selon un processus en deux + phases. La première phase est l'authentification, au cours de laquelle le fournisseur d'authentification - mod_authnz_ldap vérifie que les informations de + mod_authnz_ldap vérifie que les informations de connexion de l'utilisateur sont valides. Elle est aussi connue sous le nom de phase de recherche/connexion (NdT : en anglais ou - dans le code source : search/bind). La deuxième + dans le code source : search/bind). La deuxième phase est l'autorisation, au cours de laquelle - mod_authnz_ldap détermine si l'utilisateur - authentifié a la permission d'accéder à la ressource considérée. + mod_authnz_ldap détermine si l'utilisateur + authentifié a la permission d'accéder à la ressource considérée. Elle est aussi connue sous le nom de phase de comparaison (compare).

mod_authnz_ldap comporte un fournisseur d'authentification authn_ldap et un gestionnaire d'autorisation - authz_ldap. Le fournisseur d'authentification authn_ldap peut être - invoqué en affectant la valeur ldap à la directive + authz_ldap. Le fournisseur d'authentification authn_ldap peut être + invoqué en affectant la valeur ldap à la directive AuthBasicProvider. Le gestionnaire d'autorisation authz_ldap enrichit la liste des types d'autorisations de la directive La phase d'authentification

Au cours de la phase d'authentification, - mod_authnz_ldap recherche une entrée de l'annuaire + mod_authnz_ldap recherche une entrée de l'annuaire LDAP qui correspond au nom d'utilisateur fourni par le client HTTP. - Si une correspondance unique est trouvée, + Si une correspondance unique est trouvée, mod_authnz_ldap tente de se connecter au serveur - hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot + hébergeant l'annuaire LDAP en utilisant le DN de l'entrée et le mot de passe fourni par le client HTTP. Comme ce processus effectue tout d'abord une recherche, puis une connexion, il est aussi connu sous - le nom de phase de recherche/connexion. Voici le détail des étapes + le nom de phase de recherche/connexion. Voici le détail des étapes constituant la phase de recherche/connexion :

  1. Confection d'un filtre de recherche en combinant les attribut - et filtre définis par la directive AuthLDAPURL avec le nom d'utilisateur et le mot de passe fournis par le client HTTP.
  2. Recherche dans l'annuaire LDAP en utilisant le filtre - confectionné précédemment. Si le résultat de la recherche est - négatif ou comporte plusieurs entrées, refus ou restriction de - l'accès.
    3. + confectionné précédemment. Si le résultat de la recherche est + négatif ou comporte plusieurs entrées, refus ou restriction de + l'accès. -
  3. Extraction du DN (distinguished name) de l'entrée issue du - résultat de la recherche, et tentative de connexion au serveur +
  4. Extraction du DN (distinguished name) de l'entrée issue du + résultat de la recherche, et tentative de connexion au serveur LDAP en utilisant ce DN et le mot de passe fournis par le client - HTTP. Si la connexion échoue, refus ou restriction de - l'accès.
    5. + HTTP. Si la connexion échoue, refus ou restriction de + l'accès.
-

Les directives utilisées durant la phase de recherche/connexion +

Les directives utilisées durant la phase de recherche/connexion sont les suivantes :

@@ -192,9 +192,9 @@ configuration de la mise en cache. - + supplémentaires. @@ -218,76 +218,76 @@ configuration de la mise en cache.
La phase d'autorisation

Au cours de la phase d'autorisation, - mod_authnz_ldap tente de déterminer si - l'utilisateur est autorisé à accéder à la ressource considérée. Une - grande partie de cette vérification consiste pour - mod_authnz_ldap en des opérations de comparaison au + mod_authnz_ldap tente de déterminer si + l'utilisateur est autorisé à accéder à la ressource considérée. Une + grande partie de cette vérification consiste pour + mod_authnz_ldap en des opérations de comparaison au niveau du serveur LDAP. C'est pourquoi cette phase est aussi connue sous le nom de phase de comparaison. mod_authnz_ldap accepte les directives Require suivantes pour - déterminer si les informations de connexion permettent d'accorder - l'accès à l'utilisateur :

+ déterminer si les informations de connexion permettent d'accorder + l'accès à l'utilisateur :

  • Avec la directive Require ldap-user, - l'autorisation d'accès est accordée si le nom d'utilisateur - spécifié par la directive correspond au nom d'utilisateur fourni + l'autorisation d'accès est accordée si le nom d'utilisateur + spécifié par la directive correspond au nom d'utilisateur fourni par le client.
  • Avec la directive Require - ldap-dn, l'autorisation d'accès est accordée si le DN - spécifié par la directive correspond au DN extrait du résultat de + ldap-dn, l'autorisation d'accès est accordée si le DN + spécifié par la directive correspond au DN extrait du résultat de la recherche dans l'annuaire LDAP.
  • Avec la directive Require ldap-group, - l'autorisation d'accès est accordée si le DN extrait du résultat de + l'autorisation d'accès est accordée si le DN extrait du résultat de la recherche dans l'annuaire LDAP (ou le nom d'utilisateur fourni - par le client) appartient au groupe LDAP spécifié par la - directive, ou éventuellement à un de ses sous-groupes.
    • + par le client) appartient au groupe LDAP spécifié par la + directive, ou éventuellement à un de ses sous-groupes.
  • Avec la directive - Require ldap-attribute, l'autorisation d'accès - est accordée si la valeur de l'attribut extraite de la recherche - dans l'annuaire LDAP correspond à la valeur spécifiée par la + Require ldap-attribute, l'autorisation d'accès + est accordée si la valeur de l'attribut extraite de la recherche + dans l'annuaire LDAP correspond à la valeur spécifiée par la directive.
  • Avec la directive - Require ldap-filter, l'autorisation d'accès - est accordée si le filtre de recherche renvoie un objet + Require ldap-filter, l'autorisation d'accès + est accordée si le filtre de recherche renvoie un objet utilisateur unique qui corresponde au DN de l'utilisateur - authentifié.
    • + authentifié.
  • Avec la directive - Require ldap-search, l'autorisation d'accès - est accordée si le filtre de recherche renvoie avec succès - un seul objet correspondant aux critères avec tout nom distinctif + Require ldap-search, l'autorisation d'accès + est accordée si le filtre de recherche renvoie avec succès + un seul objet correspondant aux critères avec tout nom distinctif (DN).
  • dans tous les autres cas, refus ou restriction de - l'accès.
    • + l'accès.
-

Sous réserve du chargement de modules d'autorisation - supplémentaires, d'autres valeurs de la directive Require peuvent être - spécifiées.

+

Sous réserve du chargement de modules d'autorisation + supplémentaires, d'autres valeurs de la directive Require peuvent être + spécifiées.

    -
  • L'accès est accordé à tous les utilisateurs authentifiés si +
  • L'accès est accordé à tous les utilisateurs authentifiés si une directive Require - valid-user est présente (nécessite le module + valid-user est présente (nécessite le module mod_authz_user).
  • Avec la directive Require group, l'autorisation - d'accès est accordée si le module - mod_authz_groupfile a été chargé et si la + d'accès est accordée si le module + mod_authz_groupfile a été chargé et si la directive AuthGroupFile a été - définie.
    • + module="mod_authz_groupfile">AuthGroupFile a été + définie.
  • etc...
@@ -302,8 +302,8 @@ configuration de la mise en cache.
- @@ -311,7 +311,7 @@ configuration de la mise en cache. - @@ -319,8 +319,8 @@ configuration de la mise en cache. - @@ -328,8 +328,8 @@ configuration de la mise en cache. - @@ -337,9 +337,9 @@ configuration de la mise en cache. - @@ -347,9 +347,9 @@ configuration de la mise en cache. - @@ -357,10 +357,10 @@ configuration de la mise en cache. -
AuthLDAPURLSpécifie le serveur LDAP, le DN de base, l'attribut à + Spécifie le serveur LDAP, le DN de base, l'attribut à utiliser pour la recherche, ainsi que les filtres de recherche - supplémentaires.
AuthLDAPURL On utilise l'attribut spécifié dans l'URL pour les - opérations de comparaison initiées par la directive + On utilise l'attribut spécifié dans l'URL pour les + opérations de comparaison initiées par la directive Require ldap-user.
AuthLDAPCompareDNOnServerDétermine le comportement de la directive Require + Détermine le comportement de la directive Require ldap-dn.
AuthLDAPGroupAttributeDétermine l'attribut utilisé pour les opérations de - comparaison initiées par la directive Require + Détermine l'attribut utilisé pour les opérations de + comparaison initiées par la directive Require ldap-group.
AuthLDAPGroupAttributeIsDNSpécifie si l'on doit utiliser le DN ou le nom de - l'utilisateur lors des opérations de comparaison initiées par la + Spécifie si l'on doit utiliser le DN ou le nom de + l'utilisateur lors des opérations de comparaison initiées par la directive Require ldap-group.
AuthLDAPMaxSubGroupDepthDétermine la profondeur maximale de l'arborescence des - sous-groupes qui seront évalués au cours des opérations de - comparaisons initiées par la directive Require + Détermine la profondeur maximale de l'arborescence des + sous-groupes qui seront évalués au cours des opérations de + comparaisons initiées par la directive Require ldap-group.
AuthLDAPSubGroupAttributeDétermine l'attribut à utiliser lors de l'extraction de + Détermine l'attribut à utiliser lors de l'extraction de membres de sous-groupes du groupe courant au cours des - opérations de comparaison initiées par la directive + opérations de comparaison initiées par la directive Require ldap-group.
AuthLDAPSubGroupClassSpécifie les valeurs de classe d'objet LDAP à utiliser pour - déterminer si les objets extraits de l'annuaire sont bien des + Spécifie les valeurs de classe d'objet LDAP à utiliser pour + déterminer si les objets extraits de l'annuaire sont bien des objets de type groupe (et non des objets de type utilisateur), - au cours du traitement des sous-groupes initié par la directive + au cours du traitement des sous-groupes initié par la directive Require ldap-group.
@@ -370,38 +370,38 @@ configuration de la mise en cache.
Les directives requises

Les directives Require d'Apache sont utilisées + module="mod_authz_core">Require d'Apache sont utilisées au cours de la phase d'autorisation afin de s'assurer que - l'utilisateur est autorisé à accéder à une ressource. + l'utilisateur est autorisé à accéder à une ressource. mod_authnz_ldap enrichit la liste des types d'autorisations avec les valeurs ldap-user, ldap-dn, ldap-group, ldap-attribute et ldap-filter. D'autres types d'autorisations sont - disponibles, sous réserve du chargement de modules d'autorisation - supplémentaires.

+ disponibles, sous réserve du chargement de modules d'autorisation + supplémentaires.

A partir de la version 2.4.8, les directives require LDAP supportent les expressions.

Require ldap-user -

La directive Require ldap-user permet de spécifier - les noms des utilisateurs autorisés à accéder à la ressource. +

La directive Require ldap-user permet de spécifier + les noms des utilisateurs autorisés à accéder à la ressource. Lorsque mod_authnz_ldap a extrait un DN unique de - l'annuaire LDAP, il effectue une opération de comparaison LDAP en - utilisant le nom d'utilisateur spécifié par la directive - Require ldap-user, pour vérifier si ce nom - d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder - l'accès à plusieurs utilisateurs en plaçant plusieurs nom - d'utilisateurs sur la même ligne séparés par des espaces. Si un nom - d'utilisateur contient des espaces, il doit être entouré de - guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs + l'annuaire LDAP, il effectue une opération de comparaison LDAP en + utilisant le nom d'utilisateur spécifié par la directive + Require ldap-user, pour vérifier si ce nom + d'utilisateur correspond à l'entrée LDAP extraite. On peut accorder + l'accès à plusieurs utilisateurs en plaçant plusieurs nom + d'utilisateurs sur la même ligne séparés par des espaces. Si un nom + d'utilisateur contient des espaces, il doit être entouré de + guillemets. On peut aussi accorder l'accès à plusieurs utilisateurs en utilisant une directive Require ldap-user par utilisateur. Par exemple, avec la directive AuthLDAPURL définie à - ldap://ldap/o=Example?cn (spécifiant donc que l'attribut - cn sera utilisé pour les recherches), on pourra - utiliser les directives Require suivantes pour restreindre l'accès + module="mod_authnz_ldap">AuthLDAPURL définie à + ldap://ldap/o=Example?cn (spécifiant donc que l'attribut + cn sera utilisé pour les recherches), on pourra + utiliser les directives Require suivantes pour restreindre l'accès :

Require ldap-user "Barbara Jenson" @@ -409,26 +409,26 @@ Require ldap-user "Fred User" Require ldap-user "Joe Manager" -

De par la manière dont mod_authnz_ldap traite +

De par la manière dont mod_authnz_ldap traite cette directive, Barbara Jenson peut s'authentifier comme Barbara Jenson, Babs Jenson ou tout autre - cn sous lequel elle est enregistrée dans l'annuaire + cn sous lequel elle est enregistrée dans l'annuaire LDAP. Une seule ligne Require ldap-user suffit pour - toutes les valeurs de l'attribut dans l'entrée LDAP de + toutes les valeurs de l'attribut dans l'entrée LDAP de l'utilisateur.

-

Si l'attribut uid avait été spécifié à la place de - l'attribut cn dans l'URL précédente, les trois lignes - ci-dessus auraient pû être condensées en une seule ligne :

+

Si l'attribut uid avait été spécifié à la place de + l'attribut cn dans l'URL précédente, les trois lignes + ci-dessus auraient pû être condensées en une seule ligne :

Require ldap-user bjenson fuser jmanager
Require ldap-group -

Cette directive permet de spécifier un groupe LDAP dont les - membres auront l'autorisation d'accès. Elle prend comme argument le +

Cette directive permet de spécifier un groupe LDAP dont les + membres auront l'autorisation d'accès. Elle prend comme argument le DN du groupe LDAP. Note : n'entourez pas le nom du groupe avec des - guillemets. Par exemple, supposons que l'entrée suivante existe dans + guillemets. Par exemple, supposons que l'entrée suivante existe dans l'annuaire LDAP :

 dn: cn=Administrators, o=Example
@@ -437,15 +437,15 @@ uniqueMember: cn=Barbara Jenson, o=Example
 uniqueMember: cn=Fred User, o=Example
-

La directive suivante autoriserait alors l'accès à Fred et +

La directive suivante autoriserait alors l'accès à Fred et Barbara :

Require ldap-group cn=Administrators, o=Example

Les membres peuvent aussi se trouver dans les sous-groupes du - groupe LDAP spécifié si la directive AuthLDAPMaxSubGroupDepth a été - définie à une valeur supérieure à 0. Par exemple, supposons que les - entrées suivantes existent dans l'annuaire LDAP :

+ groupe LDAP spécifié si la directive AuthLDAPMaxSubGroupDepth a été + définie à une valeur supérieure à 0. Par exemple, supposons que les + entrées suivantes existent dans l'annuaire LDAP :

 dn: cn=Employees, o=Example
 objectClass: groupOfUniqueNames
@@ -475,17 +475,17 @@ uniqueMember: cn=Jim Swenson, o=Example
 uniqueMember: cn=Elliot Rhodes, o=Example
-

Les directives suivantes autoriseraient alors l'accès à Bob +

Les directives suivantes autoriseraient alors l'accès à Bob Ellis, Tom Jackson, Barbara Jenson, Fred User, Allan Jefferson, et - Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes - (car ils sont situés dans un sous-groupe de niveau de profondeur 2) + Paul Tilley, mais l'interdiraient à Jim Swenson, ou Elliot Rhodes + (car ils sont situés dans un sous-groupe de niveau de profondeur 2) :

Require ldap-group cn=Employees, o=Example AuthLDAPMaxSubGroupDepth 1 -

Le comportement de cette directive est modifié par les directives +

Le comportement de cette directive est modifié par les directives AuthLDAPGroupAttribute, Require ldap-dn -

La directive Require ldap-dn permet à - l'administrateur d'accorder l'utorisation d'accès en fonction du DN. - Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si +

La directive Require ldap-dn permet à + l'administrateur d'accorder l'utorisation d'accès en fonction du DN. + Elle permet de spécifier un DN pour lequel l'accès est autorisé. Si le DN extrait de - l'annuaire correspond au DN spécifié par la directive Require - ldap-dn, l'autorisation d'accès est accordée. Note : + l'annuaire correspond au DN spécifié par la directive Require + ldap-dn, l'autorisation d'accès est accordée. Note : n'entourez pas Le DN de guillemets.

-

La directive suivante accorderait l'accès à un DN spécifique +

La directive suivante accorderait l'accès à un DN spécifique :

Require ldap-dn cn=Barbara Jenson, o=Example -

Le comportement ce cette directive est modifié par la directive +

Le comportement ce cette directive est modifié par la directive AuthLDAPCompareDNOnServer.

Require ldap-attribute -

La directive Require ldap-attribute permet à - l'administrateur d'accorder l'autorisation d'accès en fonction des - attributs de l'utilisateur authentifié dans l'annuaire LDAP. Si la - valeur de l'attribut dans l'annuaire correspond à la valeur - spécifiée par la directive, l'autorisation d'accès est accordée.

+

La directive Require ldap-attribute permet à + l'administrateur d'accorder l'autorisation d'accès en fonction des + attributs de l'utilisateur authentifié dans l'annuaire LDAP. Si la + valeur de l'attribut dans l'annuaire correspond à la valeur + spécifiée par la directive, l'autorisation d'accès est accordée.

-

La directive suivante accorderait l'autorisation d'accès à tout +

La directive suivante accorderait l'autorisation d'accès à tout utilisateur dont l'attribut employeeType a pour valeur "actif" :

Require ldap-attribute "employeeType=active" -

Plusieurs paires attribut/valeur peuvent être spécifiées par une - même directive en les séparant par des espaces, ou en définissant +

Plusieurs paires attribut/valeur peuvent être spécifiées par une + même directive en les séparant par des espaces, ou en définissant plusieurs directives Require ldap-attribute. La logique - sous-jacente à une liste de paires attribut/valeur est une opération - OU. L'autorisation d'accès sera accordée si au moins une paire - attribut/valeur de la liste spécifiée correspond à la paire - attribut/valeur de l'utilisateur authentifié. Si elle contient des - espaces, la valeur, et seulement la valeur, doit être entourée de + sous-jacente à une liste de paires attribut/valeur est une opération + OU. L'autorisation d'accès sera accordée si au moins une paire + attribut/valeur de la liste spécifiée correspond à la paire + attribut/valeur de l'utilisateur authentifié. Si elle contient des + espaces, la valeur, et seulement la valeur, doit être entourée de guillemets.

-

La directive suivante accorderait l'autorisation d'accès à tout +

La directive suivante accorderait l'autorisation d'accès à tout utilisateur dont l'attribut city aurait pour valeur "San Jose", ou donc l'attribut status aurait pour valeur "actif" :

@@ -552,32 +552,32 @@ AuthLDAPMaxSubGroupDepth 1
Require ldap-filter -

La directive Require ldap-filter permet à - l'administrateur d'accorder l'autorisation d'accès en fonction d'un - filtre de recherche LDAP complexe. L'autorisation d'accès est - accordée si le DN renvoyé par le filtre de recherche correspond au - DN de l'utilisateur authentifié.

+

La directive Require ldap-filter permet à + l'administrateur d'accorder l'autorisation d'accès en fonction d'un + filtre de recherche LDAP complexe. L'autorisation d'accès est + accordée si le DN renvoyé par le filtre de recherche correspond au + DN de l'utilisateur authentifié.

-

La directive suivante accorderait l'autorisation d'accès à tout - utilisateur possédant un téléphone cellulaire et faisant partie du - département "marketing" :

+

La directive suivante accorderait l'autorisation d'accès à tout + utilisateur possédant un téléphone cellulaire et faisant partie du + département "marketing" :

Require ldap-filter "&(cell=*)(department=marketing)"

Alors que la directive Require ldap-attribute se contente d'une simple comparaison d'attributs, la directive - Require ldap-filter effectue une opération de recherche - dans l'annuaire LDAP en utilisant le filtre de recherche spécifié. - Si une simple comparaison d'attributs suffit, l'opération de - comparaison effectuée par ldap-attribute sera plus - rapide que l'opération de recherche effectuée par + Require ldap-filter effectue une opération de recherche + dans l'annuaire LDAP en utilisant le filtre de recherche spécifié. + Si une simple comparaison d'attributs suffit, l'opération de + comparaison effectuée par ldap-attribute sera plus + rapide que l'opération de recherche effectuée par ldap-filter, en particulier dans le cas d'un annuaire LDAP de grande taille.

Lorsqu'on utilise une expression rationnelle au sein d'un filtre, il faut bien s'assurer que les - filtres LDAP sont correctement échappés afin de se prémunir contre + filtres LDAP sont correctement échappés afin de se prémunir contre toute injection LDAP. A cet effet, il est possible d'utiliser la fonction ldap.

@@ -592,15 +592,15 @@ AuthLDAPMaxSubGroupDepth 1
Require ldap-search -

La directive Require ldap-search permet à - l'administrateur d'autoriser l'accès en fonction d'un filtre de - recherche LDAP générique contenant une La directive Require ldap-search permet à + l'administrateur d'autoriser l'accès en fonction d'un filtre de + recherche LDAP générique contenant une expression rationnelle. Si le filtre de - recherche renvoie une et une seule correspondance, l'accès est - accordé sans tenir compte du DN.

+ recherche renvoie une et une seule correspondance, l'accès est + accordé sans tenir compte du DN.

-

La directive suivante accorderait l'accès aux URLs correspondant - aux objets spécifiés dans le serveur LDAP :

+

La directive suivante accorderait l'accès aux URLs correspondant + aux objets spécifiés dans le serveur LDAP :

<LocationMatch "^/dav/(?<SITENAME>[^/]+)/"> @@ -610,7 +610,7 @@ Website)"

Note : il faut bien s'assurer que les - expressions sont correctement échappés afin de se prémunir contre + expressions sont correctement échappés afin de se prémunir contre toute injection LDAP. A cet effet, il est possible d'utiliser la fonction ldap comme dans l'exemple ci-dessus.

@@ -622,7 +622,7 @@ Website)"
  • - Accorde l'autorisation d'accès à tout utilisateur présent dans + Accorde l'autorisation d'accès à tout utilisateur présent dans l'annuaire LDAP, en utilisant son UID pour effectuer la recherche : @@ -632,23 +632,23 @@ Require valid-user
  • - L'exemple suivant est similaire au précédent, mais les champs - dont les valeurs par défaut conviennent sont omis. Notez aussi - la présence d'un annuaire LDAP redondant : + L'exemple suivant est similaire au précédent, mais les champs + dont les valeurs par défaut conviennent sont omis. Notez aussi + la présence d'un annuaire LDAP redondant : AuthLDAPURL "ldap://ldap1.example.com ldap2.example.com/ou=People, o=Example" Require valid-user
  • - Encore un exemple similaire aux précédents, mais cette fois, - c'est l'attribut cn qui est utilisé pour la recherche à la place - de l'UID. Notez que ceci peut poser problème si plusieurs - utilisateurs de l'annuaire partagent le même cn, + Encore un exemple similaire aux précédents, mais cette fois, + c'est l'attribut cn qui est utilisé pour la recherche à la place + de l'UID. Notez que ceci peut poser problème si plusieurs + utilisateurs de l'annuaire partagent le même cn, car une recherche sur le cn doit - retourner une entrée et une seule. C'est pourquoi cette - approche n'est pas recommandée : il est préférable de choisir un - attribut de votre annuaire dont l'unicité soit garantie, comme + retourner une entrée et une seule. C'est pourquoi cette + approche n'est pas recommandée : il est préférable de choisir un + attribut de votre annuaire dont l'unicité soit garantie, comme uid. AuthLDAPURL "ldap://ldap.example.com/ou=People, o=Example?cn" @@ -657,7 +657,7 @@ Require valid-user
  • - Accorde l'autorisation d'accès à tout utilisateur appartenant au + Accorde l'autorisation d'accès à tout utilisateur appartenant au groupe Administrateurs. Les utilisateurs doivent s'authentifier en utilisant leur UID : @@ -667,8 +667,8 @@ Require ldap-group cn=Administrators, o=Example
  • - Accorde l'accès à tout utilisateur appartenant au groupe dont le - nom correspond au nom d'hôte du serveur virtuel. Dans cet exemple, + Accorde l'accès à tout utilisateur appartenant au groupe dont le + nom correspond au nom d'hôte du serveur virtuel. Dans cet exemple, on utilise une expression pour construire le filtre. @@ -679,10 +679,10 @@ Require ldap-group cn=%{SERVER_NAME}, o=Example
  • Pour l'exemple suivant, on suppose que tout utilisateur de chez - Example qui dispose d'un bippeur alphanumérique possèdera un + Example qui dispose d'un bippeur alphanumérique possèdera un attribut LDAP qpagePagerID. Seuls ces utilisateurs - (authentifiés via leur UID) se verront accorder l'autorisation - d'accès : + (authentifiés via leur UID) se verront accorder l'autorisation + d'accès : AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(qpagePagerID=*) Require valid-user @@ -691,36 +691,36 @@ Require valid-user

  • L'exemple suivant illustre la puissance des filtres pour - effectuer des requêtes complexes. Sans les filtres, il aurait - été nécessaire de créer un nouveau groupe LDAP et de s'assurer + effectuer des requêtes complexes. Sans les filtres, il aurait + été nécessaire de créer un nouveau groupe LDAP et de s'assurer de la synchronisation des membres du groupe avec les - utilisateurs possédant un bippeur. Tout devient limpide avec les - filtres. Nous avons pour but d'accorder l'autorisation d'accès à - tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager - qui ne possède pas de bippeur, mais doit tout de même pouvoir - accéder à la ressource :

    + utilisateurs possédant un bippeur. Tout devient limpide avec les + filtres. Nous avons pour but d'accorder l'autorisation d'accès à + tout utilisateur disposant d'un bippeur ainsi qu'à Joe Manager + qui ne possède pas de bippeur, mais doit tout de même pouvoir + accéder à la ressource :

    AuthLDAPURL ldap://ldap.example.com/o=Example?uid??(|(qpagePagerID=*)(uid=jmanager)) Require valid-user

    Ce dernier exemple peut sembler confus au premier abord ; en - fait, il permet de mieux comprendre à quoi doit ressembler le + fait, il permet de mieux comprendre à quoi doit ressembler le filtre en fonction de l'utilisateur qui se connecte. Si Fred User se connecte en tant que fuser, le filtre devra - ressembler à :

    + ressembler à :

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=fuser))

    Un recherche avec le filtre ci-dessus ne retournera un - résultat positif que si fuser dispose d'un bippeur. Si + résultat positif que si fuser dispose d'un bippeur. Si Joe Manager se connecte en tant que jmanager, le filtre - devra ressembler à :

    + devra ressembler à :

    (&(|(qpagePagerID=*)(uid=jmanager))(uid=jmanager))

    Un recherche avec le filtre ci-dessus retournera un - résultat positif que jmanager dispose d'un + résultat positif que jmanager dispose d'un bippeur ou non

@@ -734,12 +734,12 @@ Require valid-user module="mod_ldap">LDAPTrustedGlobalCert et LDAPTrustedMode.

-

Un second paramètre optionnel peut être ajouté à la directive +

Un second paramètre optionnel peut être ajouté à la directive AuthLDAPURL pour - remplacer le type de connexion par défaut défini par la directive + remplacer le type de connexion par défaut défini par la directive LDAPTrustedMode. Ceci - permettra de promouvoir la connexion établie via une URL du type - ldap:// au statut de connection sécurisée sur le même + permettra de promouvoir la connexion établie via une URL du type + ldap:// au statut de connection sécurisée sur le même port.

@@ -751,65 +751,65 @@ Require valid-user module="mod_ldap">LDAPTrustedGlobalCert et LDAPTrustedMode.

-

Pour spécifier un serveur LDAP sécurisé, utilisez +

Pour spécifier un serveur LDAP sécurisé, utilisez ldaps:// au lieu de ldap:// dans la directive AuthLDAPURL.

-
Mise à disposition des informations de +<section id="exposed"><title>Mise à disposition des informations de connexion

Au cours du processus d'authentification, les attributs LDAP - spécifiés par la directive authldapurl sont enregistrés - dans des variables d'environnement préfixées par la chaîne + spécifiés par la directive authldapurl sont enregistrés + dans des variables d'environnement préfixées par la chaîne "AUTHENTICATE_".

Au cours du processus d'autorisation, les attributs LDAP - spécifiés par la directive authldapurl sont enregistrés - dans des variables d'environnement préfixées par la chaîne + spécifiés par la directive authldapurl sont enregistrés + dans des variables d'environnement préfixées par la chaîne "AUTHORIZE_".

-

Si les champs attribut contiennent le nom, le CN et le numéro de - téléphone d'un utilisateur, un programme CGI pourra accéder à ces - informations sans devoir effectuer une autre requête LDAP pour +

Si les champs attribut contiennent le nom, le CN et le numéro de + téléphone d'un utilisateur, un programme CGI pourra accéder à ces + informations sans devoir effectuer une autre requête LDAP pour les extraire de l'annuaire.

-

Ceci a pour effet de simplifier considérablement le code et la - configuration nécessaire de certaines applications web.

+

Ceci a pour effet de simplifier considérablement le code et la + configuration nécessaire de certaines applications web.

Utilisation d'Active Directory -

Active Directory peut supporter plusieurs domaines à la fois. +

Active Directory peut supporter plusieurs domaines à la fois. Pour faire la distinction entre les utilisateurs de plusieurs - domaines, on peut ajouter à l'entrée de l'utilisateur dans - l'annuaire un identifiant appelé Nom + domaines, on peut ajouter à l'entrée de l'utilisateur dans + l'annuaire un identifiant appelé Nom Principal d'Utilisateur (User Principle Name ou UPN). Cet UPN se - compose en général du nom de compte de l'utilisateur, suivi du nom - du domaine considéré, par exemple untel@nz.example.com.

+ compose en général du nom de compte de l'utilisateur, suivi du nom + du domaine considéré, par exemple untel@nz.example.com.

Vous voudrez probablement configurer le module mod_authnz_ldap afin de pouvoir authentifier les - utilisateurs de n'importe quel domaine de la forêt Active Directory. + utilisateurs de n'importe quel domaine de la forêt Active Directory. Ainsi, untel@nz.example.com et - untel@au.example.com pourront être authentifiés en une - seule fois par la même requête.

+ untel@au.example.com pourront être authentifiés en une + seule fois par la même requête.

Pour y parvenir, on utilise le concept de Catalogue Global d'Active Directory. Ce Catalogue Global est une copie en lecture - seule des attributs sélectionnés de tous les serveurs de la forêt - Active Directory. Une requête vers le + seule des attributs sélectionnés de tous les serveurs de la forêt + Active Directory. Une requête vers le Catalogue Global permet donc d'atteindre tous les domaines en une - seule fois, sans avoir à se connecter aux différents serveurs, via - des liaisons dont certaines peuvent être lentes.

+ seule fois, sans avoir à se connecter aux différents serveurs, via + des liaisons dont certaines peuvent être lentes.

-

Lorsqu'il est activé, la Catalogue Global est un serveur - d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL). +

Lorsqu'il est activé, la Catalogue Global est un serveur + d'annuaire indépendant accessible sur le port 3268 (3269 pour SSL). Pour rechercher un utilisateur, effectuez une recherche sur l'attribut userPrincipalName, avec une base de recherche vide, comme suit :

@@ -829,86 +829,86 @@ AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub FrontPage avec mod_authnz_ldap

Normalement, FrontPage utilise des fichiers utilisateur/groupe - spécifiques à FrontPage-web (c'est à dire les modules + spécifiques à FrontPage-web (c'est à dire les modules mod_authn_file et mod_authz_groupfile) pour effectuer toute l'authentification. Malheureusement, il ne suffit pas de modifier - l'authentification LDAP en ajoutant les directives appropriées, car + l'authentification LDAP en ajoutant les directives appropriées, car ceci corromprait les formulaires de Permissions dans le - client FrontPage, qui sont censés modifier les fichiers + client FrontPage, qui sont censés modifier les fichiers d'autorisation standards au format texte.

-

Lorsqu'un site web FrontPage a été créé, lui adjoindre - l'authentification LDAP consiste à ajouter les directives suivantes - à chaque fichier .htaccess qui sera créé dans +

Lorsqu'un site web FrontPage a été créé, lui adjoindre + l'authentification LDAP consiste à ajouter les directives suivantes + à chaque fichier .htaccess qui sera créé dans le site web :

AuthLDAPURL "the url" -AuthGroupFile mygroupfile -Require group mygroupfile +AuthGroupFile "mygroupfile" +Require group "mygroupfile" -
Comment ça marche +
Comment ça marche -

FrontPage restreint l'accès à un site web en ajoutant la +

FrontPage restreint l'accès à un site web en ajoutant la directive Require valid-user aux fichiers .htaccess. La directive Require valid-user - permettra l'accès à tout utilisateur valide du point de vue - LDAP. Cela signifie que tout utilisateur possédant une entrée - dans l'annuaire LDAP sera considéré comme valide, alors que - FrontPage ne considère comme valides que les utilisateurs - enregistrés dans le fichier des utilisateurs local. En remplaçant + permettra l'accès à tout utilisateur valide du point de vue + LDAP. Cela signifie que tout utilisateur possédant une entrée + dans l'annuaire LDAP sera considéré comme valide, alors que + FrontPage ne considère comme valides que les utilisateurs + enregistrés dans le fichier des utilisateurs local. En remplaçant l'autorisation par groupe LDAP par une autorisation par fichier de groupe, Apache sera en mesure de consulter le fichier des - utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP + utilisateurs local (géré par FrontPage) - au lieu de l'annuaire LDAP - lors du processus d'autorisation des utilisateurs.

-

Une fois les directives ajoutées selon ce qui précède, les - utilisateurs FrontPage pourront effectuer toutes les opérations de - gestion à partir du client FrontPage.

+

Une fois les directives ajoutées selon ce qui précède, les + utilisateurs FrontPage pourront effectuer toutes les opérations de + gestion à partir du client FrontPage.

Avertissements
    -
  • Lors du choix de l'URL LDAP, l'attribut à utiliser pour - l'authentification doit aussi être valide pour le fichier des +
  • Lors du choix de l'URL LDAP, l'attribut à utiliser pour + l'authentification doit aussi être valide pour le fichier des utilisateurs de mod_authn_file. A cette fin, - l'UID est idéal.
    • + l'UID est idéal.
  • Lorsqu'ils ajoutent des utilisateurs via FrontPage, les administrateurs de FrontPage doivent choisir des noms - d'utilisateurs qui existent déjà dans l'annuaire LDAP (pour des - raisons évidentes). De même, le mot de passe que l'administrateur - entre dans le formulaire est ignoré, car pour l'authentification, + d'utilisateurs qui existent déjà dans l'annuaire LDAP (pour des + raisons évidentes). De même, le mot de passe que l'administrateur + entre dans le formulaire est ignoré, car pour l'authentification, Apache utilise le mot de passe de l'annuaire LDAP, et non le mot - de passe enregistré dans le fichier des utilisateurs, ce qui peut + de passe enregistré dans le fichier des utilisateurs, ce qui peut semer la confusion parmi les administrateurs web.
    • -
  • Pour supporter FrontPage, Apache doit être compilé avec +
  • Pour supporter FrontPage, Apache doit être compilé avec mod_auth_basic, mod_authn_file - et mod_authz_groupfile. Ceci est dû au fait + et mod_authz_groupfile. Ceci est dû au fait qu'Apache doit utiliser le fichier de groupes de - mod_authz_groupfile pour déterminer le niveau - d'accès d'un utilisateur au site web FrontPage.
    • + mod_authz_groupfile pour déterminer le niveau + d'accès d'un utilisateur au site web FrontPage. -
  • Les directives doivent être placées dans les fichiers +
  • Les directives doivent être placées dans les fichiers .htaccess. Elles ne fonctionneront pas si vous les placez dans une section Location ou Directory. Ceci est dû au fait que pour savoir - où se trouve la liste des utilisateurs valides, - mod_authnz_ldap doit être en mesure d'atteindre + type="section">Directory. Ceci est dû au fait que pour savoir + où se trouve la liste des utilisateurs valides, + mod_authnz_ldap doit être en mesure d'atteindre la directive AuthGroupFile qui se trouve dans les fichiers .htaccess de FrontPage. Si les directives - de mod_authnz_ldap ne sont pas situées dans le - même fichier .htaccess que les directives FrontPage, + de mod_authnz_ldap ne sont pas situées dans le + même fichier .htaccess que les directives FrontPage, la configuration ne fonctionnera pas, car mod_authnz_ldap ne sera jamais en mesure de - traiter le fichier .htaccess, et par conséquent ne - pourra jamais trouver le fichier des utilisateurs géré par + traiter le fichier .htaccess, et par conséquent ne + pourra jamais trouver le fichier des utilisateurs géré par FrontPage.
@@ -916,25 +916,25 @@ Require group mygroupfile AuthLDAPAuthorizePrefix -Spécifie le préfixe ajouté aux variables d'environnement +Spécifie le préfixe ajouté aux variables d'environnement durant la phase d'autorisation -AuthLDAPAuthorizePrefix préfixe +AuthLDAPAuthorizePrefix préfixe AuthLDAPAuthorizePrefix AUTHORIZE_ directory.htaccess AuthConfig Disponible depuis la version 2.3.6 -

Cette directive permet de spécifier le préfixe ajouté aux +

Cette directive permet de spécifier le préfixe ajouté aux variables d'environnement durant la phase d'autorisation. Si la - valeur spécifiée est AUTHENTICATE_, les utilisateurs de ces - variables d'environnement verront les mêmes informations, que le + valeur spécifiée est AUTHENTICATE_, les utilisateurs de ces + variables d'environnement verront les mêmes informations, que le serveur effectue une authentification, une autorisation, ou les deux.

Note - Aucune variable d'autorisation n'est définie lorsqu'un utilisateur - s'est vu autoriser l'accès via la directive Require + Aucune variable d'autorisation n'est définie lorsqu'un utilisateur + s'est vu autoriser l'accès via la directive Require valid-user. @@ -942,32 +942,31 @@ durant la phase d'autorisation AuthLDAPBindAuthoritative -Détermine si l'on doit utiliser d'autres fournisseurs -d'authentification lorsque le serveur ne peut pas valider les données -d'authentification de l'utilisateur, alors que ce dernier possède un +Détermine si l'on doit utiliser d'autres fournisseurs +d'authentification lorsque le serveur ne peut pas valider les données +d'authentification de l'utilisateur, alors que ce dernier possède un DN. -AuthLDAPBindAuthoritativeoff|on +AuthLDAPBindAuthoritative off|on AuthLDAPBindAuthoritative on directory.htaccess AuthConfig -

Par défaut, des fournisseurs d'authentification sont appelés - si un utilisateur ne possède pas de DN, mais ne le sont pas si - l'utilisateur possède un DN et si son mot de passe ne peut pas être - vérifié lors d'une connexion au serveur LDAP. Si la directive - AuthLDAPBindAuthoritative est - définie à off, d'autres modules d'authentification - configurés auront une chance de valider le mot de passe de - l'utilisateur si la tentative de connexion au serveur LDAP échoue - pour une raison quelconque (avec les données d'authentification +

Par défaut, des fournisseurs d'authentification sont appelés + si un utilisateur ne possède pas de DN, mais ne le sont pas si + l'utilisateur possède un DN et si son mot de passe ne peut pas être + vérifié lors d'une connexion au serveur LDAP. Si la directive + AuthLDAPBindAuthoritative est + définie à off, d'autres modules d'authentification + configurés auront une chance de valider le mot de passe de + l'utilisateur si la tentative de connexion au serveur LDAP échoue + pour une raison quelconque (avec les données d'authentification fournies).

-

Ceci permet aux utilisateurs présent à la fois dans l'annuaire +

Ceci permet aux utilisateurs présent à la fois dans l'annuaire LDAP et dans un fichier AuthUserFile de s'authentifier lorsque le serveur LDAP est disponible, alors que le compte de - l'utilisateur est verrouillé ou que son mot de passe est + l'utilisateur est verrouillé ou que son mot de passe est inutilisable pour une raison quelconque.

 AuthUserFile @@ -976,39 +975,39 @@ DN. AuthLDAPInitialBindAsUser -Détermine si le serveur effectue la recherche initiale du +Détermine si le serveur effectue la recherche initiale du DN en utilisant le nom propre de l'utilisateur pour l'authentification de base -et non de manière anonyme, ou en utilisant des données d'authentification -codées en dur pour le serveur -AuthLDAPInitialBindAsUser off|on +et non de manière anonyme, ou en utilisant des données d'authentification +codées en dur pour le serveur +AuthLDAPInitialBindAsUser off|on AuthLDAPInitialBindAsUser off directory.htaccess AuthConfig Disponible depuis la version 2.3.6 -

Par défaut, le serveur convertit le nom d'utilisateur pour +

Par défaut, le serveur convertit le nom d'utilisateur pour l'authentification de base en nom distinctif LDAP (DN) soit de - manière anonyme, soit avec un couple nom/mot de passe dédié. Cette - directive permet de forcer le serveur à utiliser les véritables nom + manière anonyme, soit avec un couple nom/mot de passe dédié. Cette + directive permet de forcer le serveur à utiliser les véritables nom d'utilisateur et mot de passe fournis par l'utilisateur pour effectuer la recherche initiale du DN.

Si le nom d'utilisateur ne peut pas s'authentifier directement - et nécessite de légères modifications, voir la directive AuthLDAPInitialBindPattern.

-

Cette directive ne doit être utilisée que si votre serveur LDAP +

Cette directive ne doit être utilisée que si votre serveur LDAP n'autorise pas les recherches anonymes, ou si vous ne pouvez pas - utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.

Non disponible dans la cas d'une autorisation seule On ne peut utiliser cette directive que si ce module effectue une authentification, et n'a aucun effet si ce module - n'est utilisé que pour les processus d'autorisation. + n'est utilisé que pour les processus d'autorisation. AuthLDAPInitialBindPattern @@ -1019,12 +1018,12 @@ codées en dur pour le serveur AuthLDAPInitialBindPattern -Spécifie la modification a apporter au nom d'utilisateur -pour l'authentification de base lors de l'authentification auprès du +Spécifie la modification a apporter au nom d'utilisateur +pour l'authentification de base lors de l'authentification auprès du serveur LDAP pour effectuer une recherche de DN -AuthLDAPInitialBindPatternregex substitution +AuthLDAPInitialBindPattern regex substitution AuthLDAPInitialBindPattern (.*) $1 (nom de l'utilisateur -distant utilisé tel quel) +distant utilisé tel quel) directory.htaccess AuthConfig @@ -1032,18 +1031,18 @@ distant utilisé tel quel)

Si la directive AuthLDAPInitialBindAsUser est - définie à ON, le nom utilisateur pour l'authentification de - base sera transformé selon l'expression rationnelle - regex et l'argument substitution spécifiés.

+ définie à ON, le nom utilisateur pour l'authentification de + base sera transformé selon l'expression rationnelle + regex et l'argument substitution spécifiés.

-

L'expression rationnelle est comparée au nom d'utilisateur pour +

L'expression rationnelle est comparée au nom d'utilisateur pour l'authentification de base courant. L'argument - substitution peut contenir des références arrières, mais + substitution peut contenir des références arrières, mais n'effectue aucune autre interpolation de variable.

-

Cette directive ne doit être utilisée que si votre serveur LDAP +

Cette directive ne doit être utilisée que si votre serveur LDAP n'autorise pas les recherches anonymes, ou si vous ne pouvez pas - utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.

@@ -1053,12 +1052,12 @@ distant utilisé tel quel) Non disponible dans la cas d'une autorisation seule On ne peut utiliser cette directive que si ce module effectue une authentification, et n'a aucun effet si ce module - n'est utilisé que pour les processus d'autorisation. + n'est utilisé que pour les processus d'autorisation. - Débogage - Le DN de substitution est enregistré dans la variable + Débogage + Le DN de substitution est enregistré dans la variable d'environnement LDAP_BINDASUSER. Si l'expression - rationnelle ne convient pas, le nom d'utilisateur est utilisé + rationnelle ne convient pas, le nom d'utilisateur est utilisé tel quel. @@ -1076,16 +1075,16 @@ LDAP AuthConfig -

Cette directive permet de définir un DN optionnel pour se - connecter au serveur afin d'y rechercher des entrées. Si aucun DN - n'est spécifié, mod_authnz_ldap tentera une +

Cette directive permet de définir un DN optionnel pour se + connecter au serveur afin d'y rechercher des entrées. Si aucun DN + n'est spécifié, mod_authnz_ldap tentera une connexion anonyme.

 AuthLDAPBindPassword -Mot de passe à utiliser en conjonction avec le DN de +Mot de passe à utiliser en conjonction avec le DN de connexion AuthLDAPBindPassword mot-de-passe directory.htaccess @@ -1095,27 +1094,27 @@ connexion serveur HTTP Apache. -

Cette directive permet de spécifier un mot de passe à utiliser en +

Cette directive permet de spécifier un mot de passe à utiliser en conjonction avec le DN de connexion. Notez que ce mot de passe - constitue en général une donnée sensible, et doit donc être protégé - de manière appropriée. Vous ne devez utiliser les directives + constitue en général une donnée sensible, et doit donc être protégé + de manière appropriée. Vous ne devez utiliser les directives AuthLDAPBindDN et AuthLDAPBindPassword que si + module="mod_authnz_ldap">AuthLDAPBindDN et + AuthLDAPBindPassword que si vous en avez vraiment besoin pour effectuer une recherche dans l'annuaire.

-

Si la valeur commence par exec:, la commande résultante sera - exécutée, et la première ligne renvoyée sur la sortie standard sera - utilisée comme mot de passe.

+

Si la valeur commence par exec:, la commande résultante sera + exécutée, et la première ligne renvoyée sur la sortie standard sera + utilisée comme mot de passe.

-#Mot de passe utilisé tel quel +#Mot de passe utilisé tel quel AuthLDAPBindPassword secret -#Exécute /path/to/program pour obtenir le mot de passe +#Exécute /path/to/program pour obtenir le mot de passe AuthLDAPBindPassword exec:/path/to/program -#Exécute /path/to/otherProgram avec un argument pour obtenir le mot de passe +#Exécute /path/to/otherProgram avec un argument pour obtenir le mot de passe AuthLDAPBindPassword "exec:/path/to/otherProgram argument1" @@ -1125,38 +1124,38 @@ AuthLDAPBindPassword "exec:/path/to/otherProgram argument1" AuthLDAPCharsetConfig Chemin du fichier de configuration de la correspondance -langage/jeu de caractères +langage/jeu de caractères AuthLDAPCharsetConfig chemin-fichier server config

La directive AuthLDAPCharsetConfig permet - de définir le chemin du fichier de configuration de la - correspondance langage/jeu de caractères. chemin-fichier - est un chemin relatif au répertoire défini par la directive + de définir le chemin du fichier de configuration de la + correspondance langage/jeu de caractères. chemin-fichier + est un chemin relatif au répertoire défini par la directive ServerRoot. Ce fichier contient une liste - de correspondances extension de langage/jeu de caractères. La + de correspondances extension de langage/jeu de caractères. La plupart des administrateurs utilisent le fichier charset.conv fourni qui associe les extensions de - langage courantes à leurs jeux de caractères.

+ langage courantes à leurs jeux de caractères.

Le fichier contient des lignes au format suivant :

- extension de langage jeu de caractères + extension de langage jeu de caractères [Nom du langage] ... -

L'extension est insensible à la casse. Les lignes vides et les - lignes commençant par un dièse (#) sont ignorées.

+

L'extension est insensible à la casse. Les lignes vides et les + lignes commençant par un dièse (#) sont ignorées.

 AuthLDAPCompareAsUser -Utilisation des données d'authentification de l'utilisateur +Utilisation des données d'authentification de l'utilisateur pour effectuer les comparaisons pour l'attribution des autorisations AuthLDAPCompareAsUser on|off AuthLDAPCompareAsUser off @@ -1166,25 +1165,25 @@ pour effectuer les comparaisons pour l'attribution des autorisationsDisponible depuis la version version 2.3.6 -

Lorsque cette directive est définie, et si - mod_authnz_ldap a authentifié l'utilisateur, les +

Lorsque cette directive est définie, et si + mod_authnz_ldap a authentifié l'utilisateur, les recherches LDAP pour les autorisations utilisent le nom distinctif - trouvé (DN) et le mot de passe d'authentification basique HTTP de - l'utilisateur authentifié au lieu des données d'authentification - configurées au niveau du serveur.

+ trouvé (DN) et le mot de passe d'authentification basique HTTP de + l'utilisateur authentifié au lieu des données d'authentification + configurées au niveau du serveur.

-

Les vérifications d'autorisation ldap-attribute, +

Les vérifications d'autorisation ldap-attribute, ldap-user, et ldap-group (niveau simple seulement) utilisent des comparaisons.

-

Cette directive n'a d'effet sur les comparaisons effectuées au - cours des traitements de groupe imbriqués, et lorsque la directive +

Cette directive n'a d'effet sur les comparaisons effectuées au + cours des traitements de groupe imbriqués, et lorsque la directive AuthLDAPSearchAsUser - est aussi activée.

+ est aussi activée.

-

Cette directive ne doit être utilisée que si votre serveur LDAP +

Cette directive ne doit être utilisée que si votre serveur LDAP n'autorise pas les recherches anonymes, ou si vous ne pouvez pas - utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.

@@ -1202,24 +1201,24 @@ pour effectuer les comparaisons pour l'attribution des autorisationsAuthConfig -

Lorsque cette directive est définie à on, +

Lorsque cette directive est définie à on, mod_authnz_ldap utilise le serveur LDAP pour - comparer les DNs. Il s'agit de la seule méthode infaillible pour + comparer les DNs. Il s'agit de la seule méthode infaillible pour comparer les DNs. mod_authnz_ldap va rechercher - dans l'annuaire le DN spécifié par la directive Require dn, puis extraire ce DN et le - comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette - directive est à off, mod_authnz_ldap effectue une - simple comparaison de chaînes. Cette dernière approche peut produire - des faux négatifs, mais elle est beaucoup plus rapide. Notez - cependant que le cache de mod_ldap peut accélérer + comparer avec le DN extrait de l'entrée de l'utilisateur. Si cette + directive est à off, mod_authnz_ldap effectue une + simple comparaison de chaînes. Cette dernière approche peut produire + des faux négatifs, mais elle est beaucoup plus rapide. Notez + cependant que le cache de mod_ldap peut accélérer la comparaison de DNs dans la plupart des situations.

 AuthLDAPDereferenceAliases -À quel moment le module va déréférencer les +À quel moment le module va déréférencer les alias AuthLDAPDereferenceAliases never|searching|finding|always AuthLDAPDereferenceAliases always @@ -1228,17 +1227,17 @@ alias AuthConfig -

Cette directive permet de spécifier à quel moment - mod_authnz_ldap va déréférencer les alias au cours - des opérations liées à LDAP. La valeur par défaut est +

Cette directive permet de spécifier à quel moment + mod_authnz_ldap va déréférencer les alias au cours + des opérations liées à LDAP. La valeur par défaut est always.

 AuthLDAPGroupAttribute -L'attribut LDAP utilisé pour vérifier l'appartenance d'un -utilisateur à un groupe. +L'attribut LDAP utilisé pour vérifier l'appartenance d'un +utilisateur à un groupe. AuthLDAPGroupAttribute attribut AuthLDAPGroupAttribute member uniquemember directory.htaccess @@ -1246,10 +1245,10 @@ utilisateur à un groupe. AuthConfig -

Cette directive permet de spécifier quel attribut LDAP est - utilisé pour vérifier l'appartenance d'un utilisateur à un - groupe. On peut spécifier plusieurs attributs en répétant cette - directive plusieurs fois. Si la directive n'est pas définie, +

Cette directive permet de spécifier quel attribut LDAP est + utilisé pour vérifier l'appartenance d'un utilisateur à un + groupe. On peut spécifier plusieurs attributs en répétant cette + directive plusieurs fois. Si la directive n'est pas définie, mod_authnz_ldap utilise les attributs member et uniquemember.

 @@ -1257,8 +1256,8 @@ utilisateur à un groupe. AuthLDAPGroupAttributeIsDN -Utilise le DN de l'utilisateur pour vérifier son -appartenance à un groupe +Utilise le DN de l'utilisateur pour vérifier son +appartenance à un groupe AuthLDAPGroupAttributeIsDN on|off AuthLDAPGroupAttributeIsDN on directory.htaccess @@ -1266,22 +1265,22 @@ appartenance à un groupe AuthConfig -

Lorsqu'elle est définie à on, cette directive - indique que c'est le DN de l'utilisateur qui doit être utilisé pour - vérifier son appartenance à un groupe. Dans le cas contraire, c'est - le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que +

Lorsqu'elle est définie à on, cette directive + indique que c'est le DN de l'utilisateur qui doit être utilisé pour + vérifier son appartenance à un groupe. Dans le cas contraire, c'est + le nom de l'utilisateur qui sera utilisé. Par exemple, supposons que le client envoie le nom d'utilisateur bjenson, qui correspond au DN LDAP cn=Babs Jenson,o=Example. Si la - directive est à on, mod_authnz_ldap va - vérifier si cn=Babs Jenson, o=Example est un membre du + directive est à on, mod_authnz_ldap va + vérifier si cn=Babs Jenson, o=Example est un membre du groupe. Dans le cas contraire, mod_authnz_ldap - vérifiera si bjenson est un membre du groupe.

+ vérifiera si bjenson est un membre du groupe.

 AuthLDAPMaxSubGroupDepth -Spécifie la profondeur d'imbrication des sous-groupes +Spécifie la profondeur d'imbrication des sous-groupes maximale prise en compte avant l'abandon de la recherche de l'utilisateur. AuthLDAPMaxSubGroupDepth Nombre @@ -1289,29 +1288,29 @@ l'utilisateur. directory.htaccess AuthConfig -Disponible à partir de la version 2.3.0 du serveur HTTP -Apache ; la valeur par défaut était 10 dans les versions 2.4.x et les -premières versions 2.5 +Disponible à partir de la version 2.3.0 du serveur HTTP +Apache ; la valeur par défaut était 10 dans les versions 2.4.x et les +premières versions 2.5 -

Lorsque cette directive est définie à une valeur X +

Lorsque cette directive est définie à une valeur X non nulle, en combinaison avec l'utilisation de la directive - Require ldap-group DN-groupe, les données de connexion - fournies seront utilisées pour vérifier l'appartenance de - l'utilisateur à l'objet de l'annuaire DN-groupe ou à + Require ldap-group DN-groupe, les données de connexion + fournies seront utilisées pour vérifier l'appartenance de + l'utilisateur à l'objet de l'annuaire DN-groupe ou à tout sous-groupe du groupe courant en tenant compte de la profondeur - d'imbrication maximale X spécifiée par la directive.

-

Se référer à la section Require - ldap-group pour un exemple plus détaillé.

+ d'imbrication maximale X spécifiée par la directive.

+

Se référer à la section Require + ldap-group pour un exemple plus détaillé.

- Performances dans le cas des groupes imbriqués + Performances dans le cas des groupes imbriqués

Lorsque les directives AuthLDAPSubGroupAttribute et AuthLDAPGroupAttribute se recouvrent (comme - c'est le cas par défaut et requis par les schémas LDAP courants), la - recherche de sous-groupes au sein de grands groupes peut être très - longue. Si vos groupes sont très grands et non imbriqués, définissez - la directive AuthLDAPMaxSubGroupDepth à 0.

+ c'est le cas par défaut et requis par les schémas LDAP courants), la + recherche de sous-groupes au sein de grands groupes peut être très + longue. Si vos groupes sont très grands et non imbriqués, définissez + la directive AuthLDAPMaxSubGroupDepth à 0.

 @@ -1319,8 +1318,8 @@ premières versions 2.5 AuthLDAPRemoteUserAttribute -Spécifie l'attribut dont la valeur renvoyée au cours de la -requête de l'utilisateur sera utilisée pour définir la variable +Spécifie l'attribut dont la valeur renvoyée au cours de la +requête de l'utilisateur sera utilisée pour définir la variable d'environnement REMOTE_USER AuthLDAPRemoteUserAttribute uid none @@ -1329,16 +1328,16 @@ d'environnement REMOTE_USER AuthConfig -

Lorsque cette directive est définie, la variable d'environnement - REMOTE_USER sera définie à la valeur de l'attribut - spécifié. Assurez-vous que cet attribut soit bien inclus dans la - liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans +

Lorsque cette directive est définie, la variable d'environnement + REMOTE_USER sera définie à la valeur de l'attribut + spécifié. Assurez-vous que cet attribut soit bien inclus dans la + liste d'attributs spécifiés dans la définition de AuthLDAPUrl ; dans le cas contraire, cette directive n'aurait aucun effet. Si elle est - présente, cette directive l'emporte sur AuthLDAPRemoteUserIsDN. Elle - peut s'avérer utile par exemple, si vous souhaitez que les - utilisateurs se connectent à un site web en utilisant leur adresse - email, alors qu'une application sous-jacente nécessite un nom + peut s'avérer utile par exemple, si vous souhaitez que les + utilisateurs se connectent à un site web en utilisant leur adresse + email, alors qu'une application sous-jacente nécessite un nom d'utilisateur comme identifiant.

Cette directive n'a d'effet que si l'on utilise ce module pour l'authentification.

@@ -1347,7 +1346,7 @@ d'environnement REMOTE_USER AuthLDAPRemoteUserIsDN -Utilise le DN de l'utilisateur pour définir la variable +Utilise le DN de l'utilisateur pour définir la variable d'environnement REMOTE_USER AuthLDAPRemoteUserIsDN on|off AuthLDAPRemoteUserIsDN off @@ -1356,11 +1355,11 @@ d'environnement REMOTE_USER AuthConfig -

Lorsque cette directive est à on, la variable d'environnement - REMOTE_USER sera définie avec la valeur du DN complet - de l'utilisateur authentifié, et non plus avec simplement le nom - d'utilisateur fourni par le client. Elle est définie à off par - défaut.

+

Lorsque cette directive est à on, la variable d'environnement + REMOTE_USER sera définie avec la valeur du DN complet + de l'utilisateur authentifié, et non plus avec simplement le nom + d'utilisateur fourni par le client. Elle est définie à off par + défaut.

Cette directive n'a d'effet que si l'on utilise ce module pour l'authentification.

 @@ -1368,7 +1367,7 @@ d'environnement REMOTE_USER AuthLDAPSearchAsUser -Utilise les données d'authentification de l'utilisateur +Utilise les données d'authentification de l'utilisateur pour la recherche des autorisations AuthLDAPSearchAsUser on|off AuthLDAPSearchAsUser off @@ -1378,25 +1377,25 @@ pour la recherche des autorisations Disponible depuis la version 2.3.6 -

Lorsque cette directive est définie, et si - mod_authnz_ldap a authentifié l'utilisateur, les - recherches LDAP pour définir les autorisations utilisent le nom - distinctif (DN) trouvé et le mot de passe pour l'authentification de - base HTTP de l'utilisateur authentifié, au lieu des données - d'authentification configurées au niveau du serveur.

- -

Les vérifications d'autorisation ldap-filter et +

Lorsque cette directive est définie, et si + mod_authnz_ldap a authentifié l'utilisateur, les + recherches LDAP pour définir les autorisations utilisent le nom + distinctif (DN) trouvé et le mot de passe pour l'authentification de + base HTTP de l'utilisateur authentifié, au lieu des données + d'authentification configurées au niveau du serveur.

+ +

Les vérifications d'autorisation ldap-filter et ldap-dn utilisent des recherches.

-

Cette directive n'a d'effet sur les comparaisons effectuées au - cours des traitements de groupe imbriqués, et lorsque la directive +

Cette directive n'a d'effet sur les comparaisons effectuées au + cours des traitements de groupe imbriqués, et lorsque la directive AuthLDAPCompareAsUser - est aussi activée.

+ est aussi activée.

-

Cette directive ne doit être utilisée que si votre serveur LDAP +

Cette directive ne doit être utilisée que si votre serveur LDAP n'autorise pas les recherches anonymes, ou si vous ne pouvez pas - utiliser de nom d'utilisateur dédié via la directive AuthLDAPBindDN.

@@ -1407,34 +1406,34 @@ pour la recherche des autorisations AuthLDAPSubGroupAttribute -Spécifie les noms d'attribut, un par directive, utilisés -pour différencier les membres du groupe courant qui sont eux-mêmes des +Spécifie les noms d'attribut, un par directive, utilisés +pour différencier les membres du groupe courant qui sont eux-mêmes des groupes. AuthLDAPSubGroupAttribute attribut AuthLDAPSubgroupAttribute member uniquemember directory.htaccess AuthConfig -Disponible à partir de la version 2.3.0 du serveur HTTP +Disponible à partir de la version 2.3.0 du serveur HTTP Apache

Un objet groupe LDAP peut contenir des membres qui sont des - utilisateurs et des membres qui sont eux-mêmes des groupes (appelés - sous-groupes ou groupes imbriqués). La directive - AuthLDAPSubGroupAttribute spécifie l'attribut utilisé - pour identifier les groupes, alors que la directive - AuthLDAPGroupAttribute spécifie l'attribut utilisé - pour identifier les utilisateurs. On peut spécifier plusieurs - attributs en répétant la directive plusieurs fois. Si elle n'est pas - définie, mod_authnz_ldap utilise les attributs + utilisateurs et des membres qui sont eux-mêmes des groupes (appelés + sous-groupes ou groupes imbriqués). La directive + AuthLDAPSubGroupAttribute spécifie l'attribut utilisé + pour identifier les groupes, alors que la directive AuthLDAPGroupAttribute spécifie + l'attribut utilisé pour identifier les utilisateurs. On peut spécifier + plusieurs attributs en répétant la directive plusieurs fois. Si elle n'est + pas définie, mod_authnz_ldap utilise les attributs member et uniqueMember.

 AuthLDAPSubGroupClass -Spécifie quelles valeurs d'objectClass LDAP identifient les +Spécifie quelles valeurs d'objectClass LDAP identifient les objets de l'annuaire qui sont des groupes au cours du traitement des sous-groupes. AuthLDAPSubGroupClass ObjectClass-LDAP @@ -1442,30 +1441,31 @@ sous-groupes. directory.htaccess AuthConfig -Disponible à partir de la version 2.3.0 du serveur HTTP +Disponible à partir de la version 2.3.0 du serveur HTTP Apache

Un objet groupe LDAP peut contenir des membres qui sont des - utilisateurs et des membres qui sont eux-mêmes des groupes (appelés - sous-groupes ou groupes imbriqués). La directive - AuthLDAPSubGroupAttribute permet d'identifier les - membres qui sont des sous-groupes du groupe courant (à l'opposé des + utilisateurs et des membres qui sont eux-mêmes des groupes (appelés + sous-groupes ou groupes imbriqués). La directive + AuthLDAPSubGroupAttribute + permet d'identifier les + membres qui sont des sous-groupes du groupe courant (à l'opposé des membres utilisateurs). La directive - AuthLDAPSubGroupClass permet de spécifier les valeurs - d'objectClass LDAP utilisées pour vérifier que certains membres sont - en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent + AuthLDAPSubGroupClass permet de spécifier les valeurs + d'objectClass LDAP utilisées pour vérifier que certains membres sont + en fait des objets groupe. Les sous-groupes ainsi identifiés peuvent alors faire l'objet d'une recherche d'autres membres utilisateurs ou - sous-groupes. On peut spécifier plusieurs attributs en répétant + sous-groupes. On peut spécifier plusieurs attributs en répétant cette directive plusieurs fois. Si cette directive n'est pas - définie, mod_authnz_ldap utilise les attributs + définie, mod_authnz_ldap utilise les attributs groupOfNames et groupOfUniqueNames.

 AuthLDAPUrl -L'URL permettant de spécifier les paramètres de la +L'URL permettant de spécifier les paramètres de la recherche LDAP AuthLDAPUrl url [NONE|SSL|TLS|STARTTLS] directory.htaccess @@ -1473,134 +1473,135 @@ recherche LDAP AuthConfig -

Une URL conforme à la RFC 2255 qui permet de spécifier les - paramètres à utiliser pour la recherche dans l'annuaire LDAP. La +

Une URL conforme à la RFC 2255 qui permet de spécifier les + paramètres à utiliser pour la recherche dans l'annuaire LDAP. La syntaxe de l'URL est :

-ldap://hôte:port/DN-de-base?attribut?portée?filtre -

Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs +ldap://hôte:port/DN-de-base?attribut?portée?filtre +

Si vous souhaitez mettre à la disposition d'Apache plusieurs URLs LDAP, la syntaxe sera :

AuthLDAPUrl "ldap://ldap1.example.com ldap2.example.com/dc=..." -

Mise en garde : Si vous spécifiez plusieurs +

Mise en garde : Si vous spécifiez plusieurs serveurs, vous devez en entourer la liste avec des guillemets ; dans le -cas contraire, vous générerez une erreur : "AuthLDAPURL takes one +cas contraire, vous générerez une erreur : "AuthLDAPURL takes one argument, URL to define LDAP connection..". Vous pouvez bien -entendu ajouter des paramètres de recherche à chacun des serveurs -spécifiés.

+entendu ajouter des paramètres de recherche à chacun des serveurs +spécifiés.

ldap
-
Pour ldap non sécurisé, utilisez la chaîne - ldap. Pour ldap sécurisé, utilisez à la place la - chaîne ldaps. LDAP sécurisé n'est disponible que si - Apache a été lié avec une bibliothèque LDAP supportant SSL.
+
Pour ldap non sécurisé, utilisez la chaîne + ldap. Pour ldap sécurisé, utilisez à la place la + chaîne ldaps. LDAP sécurisé n'est disponible que si + Apache a été lié avec une bibliothèque LDAP supportant SSL.
-
hôte:port
+
hôte:port

Il s'agit du nom/port du serveur ldap - (dont la valeur par défaut est + (dont la valeur par défaut est localhost:389 pour ldap, et localhost:636 pour ldaps). Pour - spécifier plusieurs serveurs LDAP redondants, indiquez - simplement leur liste en les séparant par des espaces. + spécifier plusieurs serveurs LDAP redondants, indiquez + simplement leur liste en les séparant par des espaces. mod_authnz_ldap tentera alors de se connecter - à chacun des serveurs jusqu'à ce qu'il parvienne à se - connecter avec succès. Notez qu'en cas de multiples serveurs - LDAP, l'ensemble de l'URL LDAP doit être entourée de + à chacun des serveurs jusqu'à ce qu'il parvienne à se + connecter avec succès. Notez qu'en cas de multiples serveurs + LDAP, l'ensemble de l'URL LDAP doit être entourée de guillemets.

-

lorsqu'une connection a été établie avec un serveur, elle - reste active pendant toute la durée de vie du processus - httpd, ou jusqu'à ce que le serveur LDAP +

lorsqu'une connection a été établie avec un serveur, elle + reste active pendant toute la durée de vie du processus + httpd, ou jusqu'à ce que le serveur LDAP cesse de fonctionner.

Si le serveur LDAP cesse de fonctionner, et ainsi interrompt une connexion existante, mod_authnz_ldap tentera - de se reconnecter en commençant par le premier serveur de la + de se reconnecter en commençant par le premier serveur de la liste, et ainsi de suite avec les serveurs redondants - suivants. Notez que ce processus n'a rien à voir avec une - véritable recherche de type round-robin.

+ suivants. Notez que ce processus n'a rien à voir avec une + véritable recherche de type round-robin.

DN-de-base
-
Le DN de la branche de l'annuaire à partir de laquelle - toutes les recherches seront lancées. Il doit au moins - correspondre à la racine de votre annuaire, mais vous pouvez - aussi indiquer une branche plus spécifique.
+
Le DN de la branche de l'annuaire à partir de laquelle + toutes les recherches seront lancées. Il doit au moins + correspondre à la racine de votre annuaire, mais vous pouvez + aussi indiquer une branche plus spécifique.
attribut
-
Il s'agit de l'attribut à utiliser pour la recherche. +
Il s'agit de l'attribut à utiliser pour la recherche. Bien que la RFC - 2255 autorise une liste d'attributs séparés par des virgules, + 2255 autorise une liste d'attributs séparés par des virgules, seul le premier sera retenu, sans tenir compte des autres attributs fournis. Si aucun attribut n'est fourni, l'attribut - par défaut est uid. Il est judicieux de choisir un - attribut dont la valeur sera unique parmi toutes les entrées de - la branche de l'annuaire que vous aurez définie. Tous les - attributs spécifiés seront enregistrés dans des variables - d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir - être utilisés par d'autres modules.
+ par défaut est uid. Il est judicieux de choisir un + attribut dont la valeur sera unique parmi toutes les entrées de + la branche de l'annuaire que vous aurez définie. Tous les + attributs spécifiés seront enregistrés dans des variables + d'environnement avec le préfixe AUTHENTICATE_, afin de pouvoir + être utilisés par d'autres modules. -
portée
+
portée
-
Il s'agit de la portée de la recherche. Elle peut prendre +
Il s'agit de la portée de la recherche. Elle peut prendre les valeurs one ou sub. Notez que la - RFC 2255 supporte aussi une portée de valeur base, - mais cette dernière n'est pas supportée par le module. Si la - portée n'est pas définie, ou si elle est définie à - base, c'est la valeur de portée par défaut - sub qui sera utilisée.
+ RFC 2255 supporte aussi une portée de valeur base, + mais cette dernière n'est pas supportée par le module. Si la + portée n'est pas définie, ou si elle est définie à + base, c'est la valeur de portée par défaut + sub qui sera utilisée.
filtre
Il s'agit d'un filtre de recherche LDAP valide. Si aucun - filtre n'est spécifié, le filtre par défaut - (objectClass=*) sera utilisé, ce qui corrspond à + filtre n'est spécifié, le filtre par défaut + (objectClass=*) sera utilisé, ce qui corrspond à une recherche de tous les types d'objets de l'arborescence. La - taille des filtres est limitée à environ 8000 caractères (valeur + taille des filtres est limitée à environ 8000 caractères (valeur de la macro MAX_STRING_LEN dans le code source - d'Apache), ce qui s'avère plus que suffisant pour la plupart des - applications. Le mot-clé none permet de désactiver - l'utilisation des filtres, ce qui peut s'avérer nécessaire avec + d'Apache), ce qui s'avère plus que suffisant pour la plupart des + applications. A partir de la version 2.4.10 du serveur HTTP Apache, le + mot-clé none permet de désactiver + l'utilisation des filtres, ce qui peut s'avérer nécessaire avec certains serveurs LDAP primitifs.

Pour une recherche, les attribut, filtre et nom d'utilisateur - fournis par le client HTTP sont combinés pour créer un filtre de + fournis par le client HTTP sont combinés pour créer un filtre de recherche du style : (&(filtre)(attribut =nom-utilisateur)).

-

Par exemple, considérons l'URL +

Par exemple, considérons l'URL ldap://ldap.example.com/o=Example?cn?sub?(posixid=*). Lorsqu'un client tentera de se connecter en utilisant le nom d'utilisateur Babs Jenson, le filtre de recherche sera : (&(posixid=*)(cn=Babs Jenson)).

-

On peut encore ajouter un paramètre optionnel pour permettre à - l'URL LDAP de surcharger le type de connexion. Ce paramètre peut +

On peut encore ajouter un paramètre optionnel pour permettre à + l'URL LDAP de surcharger le type de connexion. Ce paramètre peut prendre l'une des valeurs suivantes :

NONE
-
Établit une connexion non sécurisée sur le port LDAP par - défaut, ce qui est équivalent à ldap:// sur le port +
Établit une connexion non sécurisée sur le port LDAP par + défaut, ce qui est équivalent à ldap:// sur le port 389.
SSL
-
Établit une connexion sécurisée sur le port LDAP sécurisé - par défaut, ce qui est équivalent à ldaps://.
+
Établit une connexion sécurisée sur le port LDAP sécurisé + par défaut, ce qui est équivalent à ldaps://.
TLS | STARTTLS
-
Établit une connexion sécurisée par élévation de niveau sur - le port LDAP par défaut. Cette connexion sera initialisée sur le - port 389 par défaut, puis élevée à un niveau de connexion - sécurisée sur le même port.
+
Établit une connexion sécurisée par élévation de niveau sur + le port LDAP par défaut. Cette connexion sera initialisée sur le + port 389 par défaut, puis élevée à un niveau de connexion + sécurisée sur le même port.
-

Voir plus haut pour des exemples d'URLs définies par la directive - AuthLDAPURL.

+

Voir plus haut pour des exemples d'URLs définies par la directive + AuthLDAPUrl.

 diff --git a/docs/manual/mod/mod_headers.xml.fr b/docs/manual/mod/mod_headers.xml.fr index b10f2e9b410..fe88aaf0e9b 100644 --- a/docs/manual/mod/mod_headers.xml.fr +++ b/docs/manual/mod/mod_headers.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -25,30 +25,30 @@ mod_headers -Personnalisation des en-têtes de requêtes et de réponses +Personnalisation des en-têtes de requêtes et de réponses HTTP Extension mod_headers.c headers_module -

Ce module fournit des directives permettant de contrôler et - modifier les en-têtes de requêtes et de réponses HTTP. Les en-têtes - peuvent être fusionnés, remplacés ou supprimés.

+

Ce module fournit des directives permettant de contrôler et + modifier les en-têtes de requêtes et de réponses HTTP. Les en-têtes + peuvent être fusionnés, remplacés ou supprimés.
Chronologie du traitement

Les directives fournies par mod_headers peuvent - s'insérer presque partout dans la configuration du serveur, et on - peut limiter leur portée en les plaçant dans des sections de configuration.

-

La chronologie du traitement est importante et est affectée par +

La chronologie du traitement est importante et est affectée par l'ordre d'apparition des directives dans le fichier de configuration et par leur placement dans les sections de configuration. Ainsi, - ces deux directives ont un effet différent si leur ordre est inversé + ces deux directives ont un effet différent si leur ordre est inversé :

@@ -56,34 +56,34 @@ RequestHeader append MirrorID "mirror 12" RequestHeader unset MirrorID -

Dans cet ordre, l'en-tête MirrorID n'est pas défini. - Si l'ordre des directives était inversé, l'en-tête - MirrorID serait défini à "mirror 12".

+

Dans cet ordre, l'en-tête MirrorID n'est pas défini. + Si l'ordre des directives était inversé, l'en-tête + MirrorID serait défini à "mirror 12".

-
Traitement précoce et traitement +<section id="early"><title>Traitement précoce et traitement tardif -

mod_headers peut agir soir précocement, soit - tardivement au niveau de la requête. Le mode normal est le mode - tardif, lorsque les en-têtes de requête sont définis, immédiatement - avant l'exécution du générateur de contenu, et pour les en-têtes de - réponse, juste au moment où la réponse est envoyée sur le réseau. +

mod_headers peut agir soir précocement, soit + tardivement au niveau de la requête. Le mode normal est le mode + tardif, lorsque les en-têtes de requête sont définis, immédiatement + avant l'exécution du générateur de contenu, et pour les en-têtes de + réponse, juste au moment où la réponse est envoyée sur le réseau. Utilisez toujours le mode tardif sur un serveur en production.

-

Le mode précoce a été conçu à des fins d'aide aux tests et au - débogage pour les développeurs. Les directives définies en utilisant - le mot-clé early sont censées agir au tout début du - traitement de la requête. Cela signifie que l'on peut les utiliser - pour simuler différentes requêtes et définir des situations de test, - tout en gardant à l'esprit que les en-têtes peuvent être modifiés à - tout moment par d'autres modules avant que le réponse ne soit - générée.

- -

Comme les directives précoces sont traitées avant que le - chemin de la requête ne soit parcouru, les en-têtes - précoces ne peuvent être définis que dans un contexte de serveur - principal ou de serveur virtuel. Les directives précoces ne peuvent - pas dépendre d'un chemin de requête, si bien qu'elles échoueront +

Le mode précoce a été conçu à des fins d'aide aux tests et au + débogage pour les développeurs. Les directives définies en utilisant + le mot-clé early sont censées agir au tout début du + traitement de la requête. Cela signifie que l'on peut les utiliser + pour simuler différentes requêtes et définir des situations de test, + tout en gardant à l'esprit que les en-têtes peuvent être modifiés à + tout moment par d'autres modules avant que le réponse ne soit + générée.

+ +

Comme les directives précoces sont traitées avant que le + chemin de la requête ne soit parcouru, les en-têtes + précoces ne peuvent être définis que dans un contexte de serveur + principal ou de serveur virtuel. Les directives précoces ne peuvent + pas dépendre d'un chemin de requête, si bien qu'elles échoueront dans des contextes tels que Directory ou Location.

@@ -93,8 +93,8 @@ tardif
  1. - Copie tous les en-têtes de requête qui commencent par "TS" vers - les en-têtes de la réponse : + Copie tous les en-têtes de requête qui commencent par "TS" vers + les en-têtes de la réponse : Header echo ^TS @@ -102,47 +102,47 @@ tardif
  2. - Ajoute à la réponse un en-tête, mon-en-tête, qui - contient un horodatage permettant de déterminer le moment où la - requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que - la requête ait commencé à être servie. Cet en-tête peut être - utilisé par le client pour estimer la charge du serveur ou - isoler les goulets d'étranglement entre le client et le + Ajoute à la réponse un en-tête, mon-en-tête, qui + contient un horodatage permettant de déterminer le moment où la + requête a été reçue, et le temps qui s'est écoulé jusqu'à ce que + la requête ait commencé à être servie. Cet en-tête peut être + utilisé par le client pour estimer la charge du serveur ou + isoler les goulets d'étranglement entre le client et le serveur. - Header set mon-en-tête "%D %t" + Header set mon-en-tête "%D %t" -

    le résultat est l'ajout à la réponse d'un en-tête du type :

    +

    le résultat est l'ajout à la réponse d'un en-tête du type :

    - mon-en-tête: D=3775428 t=991424704447256 + mon-en-tête: D=3775428 t=991424704447256
  3. - Dit Bonjour à Joe + Dit Bonjour à Joe - Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \
    - à Apache pour servir cette requête." + Header set mon-en-tête "Bonjour Joe. Il a fallu %D microsecondes \
    + à Apache pour servir cette requête."     -

    le résultat est l'ajout à la réponse d'un en-tête du type :

    +

    le résultat est l'ajout à la réponse d'un en-tête du type :

    - Header set MyHeader "Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache - pour servir cette requête." + Header set MyHeader "Bonjour Joe. Il a fallu D=3775428 microsecondes à Apache + pour servir cette requête."
  4. - Ajoute l'en-tête mon-en-tête à la réponse si et - seulement si l'en-tête mon-en-tête-requête est - présent dans la requête. Ceci peut s'avérer utile pour générer - des en-têtes de réponse "à la tête du client". Notez que cet - exemple nécessite les services du module + Ajoute l'en-tête mon-en-tête à la réponse si et + seulement si l'en-tête mon-en-tête-requête est + présent dans la requête. Ceci peut s'avérer utile pour générer + des en-têtes de réponse "à la tête du client". Notez que cet + exemple nécessite les services du module mod_setenvif. @@ -150,20 +150,20 @@ SetEnvIf MyRequestHeader myvalue HAVE_MyRequestHeader Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader -

    Si l'en-tête mon-en-tête-requête: mavaleur est - présent dans la requête HTTP, la réponse contiendra un en-tête +

    Si l'en-tête mon-en-tête-requête: mavaleur est + présent dans la requête HTTP, la réponse contiendra un en-tête du type :

    - mon-en-tête: D=3775428 t=991424704447256 montexte + mon-en-tête: D=3775428 t=991424704447256 montexte
  5. - Permet à DAV de fonctionner avec Apache sur SSL (voir la description - du problème) en remplaçant https: par - http: dans l'en-tête Destination : + du problème) en remplaçant https: par + http: dans l'en-tête Destination : RequestHeader edit Destination ^https: http: early @@ -171,13 +171,13 @@ Header set MyHeader "%D %t mytext" env=HAVE_MyRequestHeader
  6. - Définit la valeur d'un même en-tête sous de multiples conditions - non exclusives, mais ne duplique pas une valeur déjà définie - dans l'en-tête qui en résulte. Si toutes les conditions - suivantes sont satisfaites pour une requête (en d'autres termes, + Définit la valeur d'un même en-tête sous de multiples conditions + non exclusives, mais ne duplique pas une valeur déjà définie + dans l'en-tête qui en résulte. Si toutes les conditions + suivantes sont satisfaites pour une requête (en d'autres termes, si les trois variables d'environnement CGI, NO_CACHE et NO_STORE existent pour la - requête) : + requête) : Header merge Cache-Control no-cache env=CGI @@ -185,14 +185,14 @@ Header merge Cache-Control no-cache env=NO_CACHE Header merge Cache-Control no-store env=NO_STORE -

    alors, la réponse contiendra l'en-tête suivant :

    +

    alors, la réponse contiendra l'en-tête suivant :

    Cache-Control: no-cache, no-store -

    Si append avait été utilisé à la place de - merge, la réponse aurait contenu l'en-tête suivant +

    Si append avait été utilisé à la place de + merge, la réponse aurait contenu l'en-tête suivant :

    @@ -200,15 +200,15 @@ Header merge Cache-Control no-store env=NO_STORE
  7. - Définit un cookie de test si et seulement si le client n'envoie + Définit un cookie de test si et seulement si le client n'envoie pas de cookie Header set Set-Cookie testcookie "expr=-z %{req:Cookie}"
  8. - Ajoute un en-tête de mise en cache pour les réponses avec un - code d'état HTTP de 200 + Ajoute un en-tête de mise en cache pour les réponses avec un + code d'état HTTP de 200 Header append Cache-Control s-maxage=600 "expr=%{REQUEST_STATUS} == 200" @@ -219,9 +219,9 @@ Header merge Cache-Control no-store env=NO_STORE RequestHeader -Configure les en-têtes d'une requête HTTP +Configure les en-têtes d'une requête HTTP RequestHeader add|append|edit|edit*|merge|set|setifempty|unset -en-tête [[expr=]valeur +en-tête [[expr=]valeur [remplacement] [early|env=[!]variable|expr=expression]] @@ -229,124 +229,124 @@ Header merge Cache-Control no-store env=NO_STORE directory.htaccess FileInfo SetIfEmpty est disponible depuis la version 2.4.7 du -serveur HTTP Apache ; le paramètre expr=valeur a été introduit avec la +serveur HTTP Apache ; le paramètre expr=valeur a été introduit avec la version 2.4.10

    Cette directive permet de remplacer, fusionner, modifier ou - supprimer des en-têtes de requête HTTP. L'en-tête est modifié juste - avant que le gestionnaire de contenu ne s'exécute, ce qui permet la - modification des en-têtes entrants. L'action effectuée est - déterminée par le premier argument. Ce dernier accepte les valeurs + supprimer des en-têtes de requête HTTP. L'en-tête est modifié juste + avant que le gestionnaire de contenu ne s'exécute, ce qui permet la + modification des en-têtes entrants. L'action effectuée est + déterminée par le premier argument. Ce dernier accepte les valeurs suivantes :

    add
    -
    L'en-tête est ajouté au jeu d'en-têtes préexistant, même s'il - existe déjà. Ceci peut conduire à la présence de deux (ou plusieurs) - en-têtes possèdant le même nom et donc induire des conséquences - imprévues ; en général, il est préférable d'utiliser +
    L'en-tête est ajouté au jeu d'en-têtes préexistant, même s'il + existe déjà. Ceci peut conduire à la présence de deux (ou plusieurs) + en-têtes possèdant le même nom et donc induire des conséquences + imprévues ; en général, il est préférable d'utiliser set, append ou merge.
    append
    -
    La valeur d'en-tête est ajoutée à tout en-tête existant de même - nom. Lorsqu'une nouvelle valeur est ainsi ajoutée, elle est séparée - de celles qui sont déjà présentes par une virgule. Il s'agit de la - méthode HTTP standard permettant d'affecter plusieurs valeurs à un - en-tête.
    +
    La valeur d'en-tête est ajoutée à tout en-tête existant de même + nom. Lorsqu'une nouvelle valeur est ainsi ajoutée, elle est séparée + de celles qui sont déjà présentes par une virgule. Il s'agit de la + méthode HTTP standard permettant d'affecter plusieurs valeurs à un + en-tête.
    edit
    edit*
    -
    Si l'en-tête existe, sa valeur est modifiée en fonction d'une +
    Si l'en-tête existe, sa valeur est modifiée en fonction d'une expression rationnelle de type recherche/remplacement. L'argument valeur est une expression rationnelle, et - l'argument remplacement une chaîne de caractères de - remplacement qui peut contenir des références - arrières ou des spécificateurs de format. Avec - edit, la chaîne de l'en-tête correspondant au modèle ne - sera recherchée et remplacée qu'une seule fois, alors qu'avec + l'argument remplacement une chaîne de caractères de + remplacement qui peut contenir des références + arrières ou des spécificateurs de format. Avec + edit, la chaîne de l'en-tête correspondant au modèle ne + sera recherchée et remplacée qu'une seule fois, alors qu'avec edit*, elle le sera pour chacune de ses instances si - elle apparaît plusieurs fois.
    + elle apparaît plusieurs fois.
    merge
    -
    La valeur d'en-tête est ajoutée à tout en-tête de même nom, sauf - si elle apparaît déjà dans la liste des valeurs préexistantes de - l'en-tête séparées par des virgules. Lorsqu'une nouvelle valeur est - ainsi ajoutée, elle est séparée de celles qui sont déjà présentes - par une virgule. Il s'agit de la méthode HTTP standard permettant - d'affecter plusieurs valeurs à un en-tête. Les valeurs sont - comparées en tenant compte de la casse, et après le traitement de - tous les spécificateurs de format. Une valeur entourée de guillemets - est considérée comme différente de la même valeur mais sans +
    La valeur d'en-tête est ajoutée à tout en-tête de même nom, sauf + si elle apparaît déjà dans la liste des valeurs préexistantes de + l'en-tête séparées par des virgules. Lorsqu'une nouvelle valeur est + ainsi ajoutée, elle est séparée de celles qui sont déjà présentes + par une virgule. Il s'agit de la méthode HTTP standard permettant + d'affecter plusieurs valeurs à un en-tête. Les valeurs sont + comparées en tenant compte de la casse, et après le traitement de + tous les spécificateurs de format. Une valeur entourée de guillemets + est considérée comme différente de la même valeur mais sans guillemets.
    set
    -
    L'en-tête est défini, remplaçant tout en-tête préexistant avec - le même nom.
    +
    L'en-tête est défini, remplaçant tout en-tête préexistant avec + le même nom.
    setifempty
    -
    L'en-tête est défini, mais seulement s'il n'existe - aucun en-tête avec le même nom.
    +
    L'en-tête est défini, mais seulement s'il n'existe + aucun en-tête avec le même nom.
    Disponible depuis la version 2.4.7 du serveur HTTP Apache.
    unset
    -
    L'en-tête est supprimé s'il existe. Si plusieurs en-têtes - possèdent le même nom, ils seront tous supprimés. L'argument - value ne doit pas apparaître.
    +
    L'en-tête est supprimé s'il existe. Si plusieurs en-têtes + possèdent le même nom, ils seront tous supprimés. L'argument + value ne doit pas apparaître.
    -

    Cet argument est suivi d'un nom d'en-tête qui peut se terminer - par un caractère ':', mais ce n'est pas obligatoire. La casse est - ignorée. Avec set, append, +

    Cet argument est suivi d'un nom d'en-tête qui peut se terminer + par un caractère ':', mais ce n'est pas obligatoire. La casse est + ignorée. Avec set, append, merge et add, une valeur est - fournie en troisième argument. Si une valeur contient des - espaces, elle doit être entourée de guillemets. Avec - unset, aucune valeur ne doit apparaître. - valeur peut être une chaîne de caractères, une chaîne - contenant des spécificateurs de format, ou une combinaison des deux. - Les spécificateurs de format supportés sont les mêmes que ceux de la - directive Header, à - laquelle vous pouvez vous reporter pour plus de détails. Avec + fournie en troisième argument. Si une valeur contient des + espaces, elle doit être entourée de guillemets. Avec + unset, aucune valeur ne doit apparaître. + valeur peut être une chaîne de caractères, une chaîne + contenant des spécificateurs de format, ou une combinaison des deux. + Les spécificateurs de format supportés sont les mêmes que ceux de la + directive Header, à + laquelle vous pouvez vous reporter pour plus de détails. Avec edit, les deux arguments valeur et remplacement sont obligatoires, et correspondent - respectivement à une expression - rationnelle et à une chaîne de remplacement.

    + respectivement à une expression + rationnelle et à une chaîne de remplacement.

    -

    La directive RequestHeader peut être - suivie d'un argument supplémentaire, qui pourra prendre les valeurs +

    La directive RequestHeader peut être + suivie d'un argument supplémentaire, qui pourra prendre les valeurs suivantes :

    early
    -
    Spécifie traitement préalable.
    +
    Spécifie traitement préalable.
    env=[!]variable
    -
    La directive est appliquée si et seulement si la La directive est appliquée si et seulement si la variable d'environnement variable existe. Un ! devant variable inverse le test, et la directive ne - s'appliquera alors que si variable n'est pas définie.
    + s'appliquera alors que si variable n'est pas définie.
    expr=expression
    La directive s'applique si et seulement si expression - est évaluée à true. Vous trouverez plus de détails à propos de la - syntaxe et de l'évaluation des expressions dans la documentation ap_expr.
    -

    Excepté le cas du mode précoce, la directive - RequestHeader est traitée juste avant la - prise en compte de la requête par son gestionnaire, au cours de la - phase de vérification. Ceci permet la modification des en-têtes - générés par le navigateur, ou par les filtres en entrée +

    Excepté le cas du mode précoce, la directive + RequestHeader est traitée juste avant la + prise en compte de la requête par son gestionnaire, au cours de la + phase de vérification. Ceci permet la modification des en-têtes + générés par le navigateur, ou par les filtres en entrée d'Apache.

         Header -Configure les en-têtes d'une réponse HTTP +Configure les en-têtes d'une réponse HTTP Header [condition] add|append|echo|edit|edit*|merge|set|setifempty|unset|note -en-tête [[expr=]valeur +en-tête [[expr=]valeur [remplacement] [early|env=[!]variable|expr=expression]] @@ -354,190 +354,190 @@ version 2.4.10 directory.htaccess FileInfo SetIfEmpty est disponible depuis la version 2.4.7 du -serveur HTTP Apache ; le paramètre expr=valeur a été introduit avec la +serveur HTTP Apache ; le paramètre expr=valeur a été introduit avec la version 2.4.10

    Cette directive permet de remplacer, fusionner, ou - supprimer des en-têtes de réponse HTTP. L'en-tête est modifié juste - après que le gestionnaire de contenu et les filtres en sortie ne - s'exécutent, ce qui permet la modification des en-têtes + supprimer des en-têtes de réponse HTTP. L'en-tête est modifié juste + après que le gestionnaire de contenu et les filtres en sortie ne + s'exécutent, ce qui permet la modification des en-têtes sortants.

    -

    L'argument optionnel condition permet de déterminer - sur quelle table interne d'en-têtes de réponses cette directive va - opérer. En dépit du nom, la valeur par défaut de +

    L'argument optionnel condition permet de déterminer + sur quelle table interne d'en-têtes de réponses cette directive va + opérer. En dépit du nom, la valeur par défaut de onsuccess ne limite pas une action - aux réponses avec un code d'état de 2xx. Les en-têtes définis sous - cette condition sont encore utilisés quand par exemple une requête - est mandatée ou générée par un programme CGI avec succès, - et ceci même dans le cas où ils ont généré un code d'échec.

    + aux réponses avec un code d'état de 2xx. Les en-têtes définis sous + cette condition sont encore utilisés quand par exemple une requête + est mandatée ou générée par un programme CGI avec succès, + et ceci même dans le cas où ils ont généré un code d'échec.

    -

    Lorsque votre action est une fonction agissant sur un en-tête - existant, vous pourrez être amené à spécifier une condition +

    Lorsque votre action est une fonction agissant sur un en-tête + existant, vous pourrez être amené à spécifier une condition always, en fonction de la table interne dans laquelle - l'en-tête original a été défini. La table qui correspond à - always est utilisée pour les réponses d'erreur générées - localement ainsi que pour les réponses qui ont abouti. - Notez aussi que la répétition - de cette directive avec les deux conditions peut être pertinente - dans certains scénarios, car always n'englobe pas - onsuccess en ce qui concerne les en-têtes existants :

    + l'en-tête original a été défini. La table qui correspond à + always est utilisée pour les réponses d'erreur générées + localement ainsi que pour les réponses qui ont abouti. + Notez aussi que la répétition + de cette directive avec les deux conditions peut être pertinente + dans certains scénarios, car always n'englobe pas + onsuccess en ce qui concerne les en-têtes existants :

      -
    • Vous ajoutez un en-tête à une réponse - générée localement et échouée (non-2xx), +
    • Vous ajoutez un en-tête à une réponse + générée localement et échouée (non-2xx), une redirection par exemple, et dans ce cas, seule la table - correspondant à always est utilisée dans la réponse - définitive.
      • -
    • Vous modifiez ou supprimez un en-tête généré par un script + correspondant à always est utilisée dans la réponse + définitive.
      • +
    • Vous modifiez ou supprimez un en-tête généré par un script CGI, et dans ce cas, les scripts CGI sont dans la table - correspondant à always et non dans la table par - défaut.
      • -
    • Vous modifiez ou supprimez un en-tête généré par tel ou tel - composant du serveur, mais cet en-tête n'est pas trouvé par la - condition par défaut onsuccess.
      • + correspondant à always et non dans la table par + défaut. +
    • Vous modifiez ou supprimez un en-tête généré par tel ou tel + composant du serveur, mais cet en-tête n'est pas trouvé par la + condition par défaut onsuccess.
    -

    Outre le paramètre condition décrit ci-dessus, vous - pouvez limiter une action en fonction de codes d'état HTTP, par - exemple pour les requêtes mandatées ou générées par un programme +

    Outre le paramètre condition décrit ci-dessus, vous + pouvez limiter une action en fonction de codes d'état HTTP, par + exemple pour les requêtes mandatées ou générées par un programme CGI. Voir l'exemple qui utilise %{REQUEST_STATUS} dans la section ci-dessus.

    -

    L'action que cette directive provoque est déterminée par le +

    L'action que cette directive provoque est déterminée par le premier argument (ou par le second argument si une - condition est spécifiée). Il peut prendre + condition est spécifiée). Il peut prendre une des valeurs suivantes :

    add
    -
    L'en-tête est ajouté au jeu d'en-têtes préexistant, même s'il - existe déjà. Ceci peut conduire à la présence de deux (ou plusieurs) - en-têtes possèdant le même nom et donc induire des conséquences - imprévues ; en général, il est préférable d'utiliser +
    L'en-tête est ajouté au jeu d'en-têtes préexistant, même s'il + existe déjà. Ceci peut conduire à la présence de deux (ou plusieurs) + en-têtes possèdant le même nom et donc induire des conséquences + imprévues ; en général, il est préférable d'utiliser set, append ou merge.
    append
    -
    La valeur d'en-tête est ajoutée à tout en-tête existant de même - nom. Lorsqu'une nouvelle valeur est ainsi ajoutée, elle est séparée - de celles qui sont déjà présentes par une virgule. Il s'agit de la - méthode HTTP standard permettant d'affecter plusieurs valeurs à un - en-tête.
    +
    La valeur d'en-tête est ajoutée à tout en-tête existant de même + nom. Lorsqu'une nouvelle valeur est ainsi ajoutée, elle est séparée + de celles qui sont déjà présentes par une virgule. Il s'agit de la + méthode HTTP standard permettant d'affecter plusieurs valeurs à un + en-tête.
    echo
    -
    Les en-têtes de la requête possédant le nom spécifié sont - recopiés vers les en-têtes de la réponse. en-tête peut - être une expression rationnelle, et - valeur ne doit pas être présent.
    +
    Les en-têtes de la requête possédant le nom spécifié sont + recopiés vers les en-têtes de la réponse. en-tête peut + être une expression rationnelle, et + valeur ne doit pas être présent.
    edit
    edit*
    -
    Si l'en-tête existe, sa valeur est modifiée en fonction d'une +
    Si l'en-tête existe, sa valeur est modifiée en fonction d'une expression rationnelle de type recherche/remplacement. L'argument valeur est une expression rationnelle, et - l'argument remplacement une chaîne de caractères de - remplacement qui peut contenir des références - arrières ou des spécificateurs de format. La forme edit n'effectuera une + l'argument remplacement une chaîne de caractères de + remplacement qui peut contenir des références + arrières ou des spécificateurs de format. La forme edit n'effectuera une recherche/remplacement qu'une seule fois dans la valeur de - l'en-tête, alors que la forme edit* en effectuera autant - que le nombre d'apparition de la chaîne à remplacer.
    + l'en-tête, alors que la forme edit* en effectuera autant + que le nombre d'apparition de la chaîne à remplacer.
    merge
    -
    La valeur d'en-tête est ajoutée à tout en-tête de même nom, sauf - si elle apparaît déjà dans la liste des valeurs préexistantes de - l'en-tête séparées par des virgules. Lorsqu'une nouvelle valeur est - ainsi ajoutée, elle est séparée de celles qui sont déjà présentes - par une virgule. Il s'agit de la méthode HTTP standard permettant - d'affecter plusieurs valeurs à un en-tête. Les valeurs sont - comparées en tenant compte de la casse, et après le traitement de - tous les spécificateurs de format. Une valeur entourée de guillemets - est considérée comme différente de la même valeur mais sans +
    La valeur d'en-tête est ajoutée à tout en-tête de même nom, sauf + si elle apparaît déjà dans la liste des valeurs préexistantes de + l'en-tête séparées par des virgules. Lorsqu'une nouvelle valeur est + ainsi ajoutée, elle est séparée de celles qui sont déjà présentes + par une virgule. Il s'agit de la méthode HTTP standard permettant + d'affecter plusieurs valeurs à un en-tête. Les valeurs sont + comparées en tenant compte de la casse, et après le traitement de + tous les spécificateurs de format. Une valeur entourée de guillemets + est considérée comme différente de la même valeur mais sans guillemets.
    set
    -
    L'en-tête est défini, remplaçant tout en-tête préexistant avec - le même nom. L'argument valeur peut être une chaîne de +
    L'en-tête est défini, remplaçant tout en-tête préexistant avec + le même nom. L'argument valeur peut être une chaîne de formatage.
    setifempty
    -
    L'en-tête est défini, mais seulement s'il n'existe - aucun en-tête avec le même nom.
    +
    L'en-tête est défini, mais seulement s'il n'existe + aucun en-tête avec le même nom.
    Disponible depuis la version 2.4.7 du serveur HTTP Apache.
    unset
    -
    L'en-tête est supprimé s'il existe. Si plusieurs en-têtes - possèdent le même nom, ils seront tous supprimés. L'argument - value ne doit pas apparaître.
    +
    L'en-tête est supprimé s'il existe. Si plusieurs en-têtes + possèdent le même nom, ils seront tous supprimés. L'argument + value ne doit pas apparaître.
    note
    -
    La valeur de l'en-tête considéré est copiée dans une - note interne dont le nom est spécifié via l'argument - valeur. Ceci permet de journaliser la valeur d'un en-tête - envoyé par un programme CGI ou une ressource mandatée, même s'il - est prévu de l'effacer.
    - Disponible à partir de la version 2.4.7 du serveur HTTP Apache.
    +
    La valeur de l'en-tête considéré est copiée dans une + note interne dont le nom est spécifié via l'argument + valeur. Ceci permet de journaliser la valeur d'un en-tête + envoyé par un programme CGI ou une ressource mandatée, même s'il + est prévu de l'effacer.
    + Disponible à partir de la version 2.4.7 du serveur HTTP Apache.
    -

    Cet argument est suivi d'un nom d'en-tête qui peut se - terminer par un caractère ':', mais ce n'est pas obligatoire. La - casse est ignorée avec set, append, +

    Cet argument est suivi d'un nom d'en-tête qui peut se + terminer par un caractère ':', mais ce n'est pas obligatoire. La + casse est ignorée avec set, append, merge, add, unset et - edit. Le nom d'en-tête est sensible à la - casse pour echo et peut être une edit. Le nom d'en-tête est sensible à la + casse pour echo et peut être une expression rationnelle.

    Avec set, append, merge et - add, une valeur est spécifiée comme + add, une valeur est spécifiée comme argument suivant. Si valeur contient des espaces, elle - doit être entourée de guillemets. valeur peut être une - chaîne de caractères, une chaîne contenant des spécificateurs de - format propres à mod_headers (et des caractères - littéraux), ou une expression ap_expr - préfixée par expr=.

    + doit être entourée de guillemets. valeur peut être une + chaîne de caractères, une chaîne contenant des spécificateurs de + format propres à mod_headers (et des caractères + littéraux), ou une expression ap_expr + préfixée par expr=.

    -

    valeur supporte les spécificateurs de format suivants :

    +

    valeur supporte les spécificateurs de format suivants :

    - + - - + - - @@ -548,33 +548,33 @@ version 2.4.10 + mod_ssl est activé.
    FormatDescription
    %%Le caractère pourcentage
    Le caractère pourcentage
    %tLe moment de réception de la requête en temps - universel coordonné depuis le temps epoch (Jan. 1, 1970) et - exprimé en microsecondes. La valeur est précédée de + Le moment de réception de la requête en temps + universel coordonné depuis le temps epoch (Jan. 1, 1970) et + exprimé en microsecondes. La valeur est précédée de t=.
    %DLe temps écoulé entre la réception de la requête et l'envoi - des en-têtes sur le réseau. Il s'agit de la durée de traitement - de la requête. La valeur est précédée de D=. La - valeur est exprimée en microsecondes.
    Le temps écoulé entre la réception de la requête et l'envoi + des en-têtes sur le réseau. Il s'agit de la durée de traitement + de la requête. La valeur est précédée de D=. La + valeur est exprimée en microsecondes.
    %l La charge moyenne courante du serveur proprement dit. Ce sont les valeurs obtenues par getloadavg() qui - représentent la charge moyenne courante, sur 5 minutes et sur 15 - minutes. Chaque valeur est précédée de l= et - séparée de la suivante par un /.
    + représentent la charge moyenne courante, sur 5 minutes et sur 15 + minutes. Chaque valeur est précédée de l= et + séparée de la suivante par un /.
    Disponible depuis la version 2.4.4 du serveur HTTP Apache.
    %iLe pourcentage courant de httpd au repos (de 0 à 100) + Le pourcentage courant de httpd au repos (de 0 à 100) en se basant sur le nombre de processus et threads disponibles. - La valeur est précédée de i=.
    + La valeur est précédée de i=.
    Disponible depuis la version 2.4.4 du serveur HTTP Apache.
    %bLe pourcentage courant de httpd utilisé (de 0 à 100) + Le pourcentage courant de httpd utilisé (de 0 à 100) en se basant sur le nombre de processus et threads disponibles. - La valeur est précédée de b=.
    + La valeur est précédée de b=.
    Disponible depuis la version 2.4.4 du serveur HTTP Apache.
    %{NOM_VARIABLE}s Le contenu de la variable d'environnement SSL NOM_VARIABLE, si - mod_ssl est activé.
    Note -

    Le spécificateur de format %s est disponible - depuis la version 2.1 d'Apache ; il peut être utilisé à la place - de %e pour éviter de devoir spécifier +

    Le spécificateur de format %s est disponible + depuis la version 2.1 d'Apache ; il peut être utilisé à la place + de %e pour éviter de devoir spécifier SSLOptions +StdEnvVars. Cependant, si - SSLOptions +StdEnvVars doit tout de même être - spécifié pour une raison quelconque, %e sera plus + SSLOptions +StdEnvVars doit tout de même être + spécifié pour une raison quelconque, %e sera plus efficace que %s.

     - Note à propos des valeurs des expressions -

    Lorsque le paramètre valeur utilise l'interpréteur Note à propos des valeurs des expressions +

    Lorsque le paramètre valeur utilise l'interpréteur ap_expr, certaines syntaxes d'expressions - seront différentes des exemples qui évaluent des expressions - booléennes telles que <If> :

    + seront différentes des exemples qui évaluent des expressions + booléennes telles que <If> :

      -
    • Le point de départ de la syntaxe est 'string' au lieu de +
    • Le point de départ de la syntaxe est 'string' au lieu de 'expr'.
    • Les appels de fonction utilisent la syntaxe %{funcname:arg} au lieu de funcname(arg).
    • Les fonctions multi-arguments ne sont pas encore disponibles - depuis le point de départ 'string'.
      • -
    • Il faut mettre entre guillemets l'ensemble du paramètre, comme + depuis le point de départ 'string'.
      • +
    • Il faut mettre entre guillemets l'ensemble du paramètre, comme dans l'exemple suivant : Header set foo-checksum "expr=%{md5:foo}" @@ -584,45 +584,45 @@ version 2.4.10
    -

    editnécessite les deux arguments +

    editnécessite les deux arguments valeur, qui est une expression - rationnelle, et une chaîne additionnelle - remplacement. Depuis la version 2.4.7, la chaîne de + rationnelle, et une chaîne additionnelle + remplacement. Depuis la version 2.4.7, la chaîne de remplacement peut aussi - contenir des spécificateurs de format.

    + contenir des spécificateurs de format.

    -

    La directive Header peut être suivie d'un +

    La directive Header peut être suivie d'un argument additionnel qui peut prendre les valeurs suivantes :

    early
    -
    Spécifie traitement préalable.
    +
    Spécifie traitement préalable.
    env=[!]variable
    -
    La directive est appliquée si et seulement si la La directive est appliquée si et seulement si la variable d'environnement variable existe. Un ! devant variable inverse le test, et la directive ne - s'appliquera alors que si variable n'est pas définie.
    + s'appliquera alors que si variable n'est pas définie.
    expr=expression
    La directive s'applique si et seulement si expression - est évaluée à true. Vous trouverez plus de détails à propos de la - syntaxe et de l'évaluation des expressions dans la documentation ap_expr. - - # Cet exemple retarde l'évaluation de la clause de condition par - # rapport à <If> + + # Cet exemple retarde l'évaluation de la clause de condition par + # rapport à <If> Header always set CustomHeader my-value "expr=%{REQUEST_URI} =~ m#^/special_path.php$#" - +
    -

    Excepté le cas du mode précoce, les - directives Header sont traitées juste avant - l'envoi de la réponse sur le réseau. Cela signifie qu'il est - possible de définir et/ou modifier la plupart des en-têtes, à - l'exception de certains en-têtes qui sont ajoutés par le filtre - d'en-tête HTTP. Avant la version 2.2.12, il n'était pas - possible de modifier l'en-tête Content-Type avec cette directive.

    +

    Excepté le cas du mode précoce, les + directives Header sont traitées juste avant + l'envoi de la réponse sur le réseau. Cela signifie qu'il est + possible de définir et/ou modifier la plupart des en-têtes, à + l'exception de certains en-têtes qui sont ajoutés par le filtre + d'en-tête HTTP. Avant la version 2.2.12, il n'était pas + possible de modifier l'en-tête Content-Type avec cette directive.

    diff --git a/docs/manual/mod/mod_macro.xml.fr b/docs/manual/mod/mod_macro.xml.fr index b2b82492929..f8e1abd0c6c 100644 --- a/docs/manual/mod/mod_macro.xml.fr +++ b/docs/manual/mod/mod_macro.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -34,23 +34,23 @@ de configuration Apache.

    Ce module permet d'utiliser des macros dans les fichiers de - configuration à l'exécution du serveur HTTP Apache afin de faciliter - la création de nombreux blocs de configuration similaires. Quand le - serveur démarre, les macros sont exécutées avec les paramètres - fournis, et le résultat obtenu est traité au même titre que le reste + configuration à l'exécution du serveur HTTP Apache afin de faciliter + la création de nombreux blocs de configuration similaires. Quand le + serveur démarre, les macros sont exécutées avec les paramètres + fournis, et le résultat obtenu est traité au même titre que le reste du fichier de configuration.
    Utilisation -

    On définit une macro à l'aide des blocs On définit une macro à l'aide des blocs Macro qui contiennent la portion de votre -configuration qui intervient de manière répétitive, y compris les -variables pour les parties qui devront être substituées.

    +configuration qui intervient de manière répétitive, y compris les +variables pour les parties qui devront être substituées.

    -

    Par exemple, vous pouvez utiliser une macro pour définir un bloc -VirtualHost, afin de pouvoir -définir de nombreux serveurs virtuels similaires :

    +

    Par exemple, vous pouvez utiliser une macro pour définir un bloc +VirtualHost, afin de pouvoir +définir de nombreux serveurs virtuels similaires :

    <Macro VHost $name $domain> @@ -66,11 +66,11 @@ définir de nombreux serveurs virtuels similaires :

    Comme les directives de configuration httpd, les noms des macros sont -insensibles à la casse, à la différence des variables qui y sont, elles, +insensibles à la casse, à la différence des variables qui y sont, elles, sensibles.

    Vous pouvez alors invoquer cette macro autant de fois que vous le -voulez pour créer des serveurs virtuels

    +voulez pour créer des serveurs virtuels

    Use VHost example example.com @@ -80,44 +80,44 @@ Use VHost apache apache.org UndefMacro VHost -

    Au démarrage du serveur, chacune de ces invocations -Use sera remplacée par une définition de serveur -virtuel complète, comme décrit dans la définition de la -Macro.

    +

    Au démarrage du serveur, chacune de ces invocations +Use sera remplacée par une définition de serveur +virtuel complète, comme décrit dans la définition de la +Macro.

    -

    La directive UndefMacro permet d'éviter les -conflits de définitions qui pourraient provenir de l'utilisation -ultérieure de macros contenant les mêmes noms de variables.

    +

    La directive UndefMacro permet d'éviter les +conflits de définitions qui pourraient provenir de l'utilisation +ultérieure de macros contenant les mêmes noms de variables.

    -

    Vous trouverez une version plus élaborée de cet exemple plus loin +

    Vous trouverez une version plus élaborée de cet exemple plus loin dans la section Exemples.

    Conseils -

    Les noms de paramètres doivent commencer par un sigil tel que -$, %, ou @, de façon à ce qu'ils +

    Les noms de paramètres doivent commencer par un sigil tel que +$, %, ou @, de façon à ce qu'ils soient clairement identifiables, mais aussi afin de faciliter les interactions avec les autres directives, comme la directive de base Define. Dans le cas contraire, vous -recevrez un avertissement. En tout état de cause, il est conseillé +recevrez un avertissement. En tout état de cause, il est conseillé d'avoir une bonne connaissance globale de la configuration du serveur, -afin d'éviter la réutilisation des mêmes variables à différents niveaux, -ce qui peut être à l'origine de confusions.

    +afin d'éviter la réutilisation des mêmes variables à différents niveaux, +ce qui peut être à l'origine de confusions.

    -

    Les paramètres préfixés par $ ou % ne sont -pas échappés. Les paramètres préfixés par @ sont échappés +

    Les paramètres préfixés par $ ou % ne sont +pas échappés. Les paramètres préfixés par @ sont échappés entre guillemets.

    -

    Evitez de préfixer un paramètre par le nom d'un autre paramètre (par -exemple, présence simultanée des paramètres $win et +

    Evitez de préfixer un paramètre par le nom d'un autre paramètre (par +exemple, présence simultanée des paramètres $win et $winter), car ceci peut introduire de la confusion lors de -l'évaluation des expressions. Si cela se produit, c'est le nom de -paramètre le plus long possible qui sera utilisé.

    +l'évaluation des expressions. Si cela se produit, c'est le nom de +paramètre le plus long possible qui sera utilisé.

    -

    Si vous désirez insérer une valeur dans une chaîne, il est conseillé -de l'entourer d'accolades afin d'éviter toute confusion :

    +

    Si vous désirez insérer une valeur dans une chaîne, il est conseillé +de l'entourer d'accolades afin d'éviter toute confusion :

    <Macro DocRoot ${docroot}> @@ -131,13 +131,13 @@ de l'entourer d'accolades afin d'éviter toute confusion :

    Exemples
    -Définition de serveurs virtuels +Définition de serveurs virtuels

    Un exemple typique d'utilisation de mod_macro est la -création dynamique de serveurs virtuels.

    +création dynamique de serveurs virtuels.

    -## Définition d'une macro VHost pour les configurations répétitives +## Définition d'une macro VHost pour les configurations répétitives <Macro VHost $host $port $dir> Listen $port @@ -151,14 +151,14 @@ création dynamique de serveurs virtuels.

    Require all granted </Directory> - # restriction d'accès au sous-répertoire intranet. + # restriction d'accès au sous-répertoire intranet. <Directory "$dir/intranet"> Require ip 10.0.0.0/8 </Directory> </VirtualHost> </Macro> -## Utilisation de la macro VHost avec différents arguments. +## Utilisation de la macro VHost avec différents arguments. Use VHost www.apache.org 80 /vhosts/apache/htdocs Use VHost example.org 8080 /vhosts/example/htdocs @@ -167,11 +167,11 @@ Use VHost www.example.fr 1234 /vhosts/example.fr/htdocs
    -Suppression d'une définition de macro +Suppression d'une définition de macro -

    Il est recommandé de supprimer la définition d'une macro après -l'avoir utilisée. Ceci permet d'éviter les confusions au sein d'un -fichier de configuration complexe où des conflits entre noms de +

    Il est recommandé de supprimer la définition d'une macro après +l'avoir utilisée. Ceci permet d'éviter les confusions au sein d'un +fichier de configuration complexe où des conflits entre noms de variables peuvent survenir.

    @@ -194,7 +194,7 @@ UndefMacro DirGroup Macro -Définition d'une macro dans un fichier de configuration +Définition d'une macro dans un fichier de configuration <Macro nom [par1 .. parN]> ... </Macro> @@ -205,12 +205,12 @@ UndefMacro DirGroup -

    La directive Macro permet de définir une macro +

    La directive Macro permet de définir une macro dans un fichier de configuration Apache. Le premier argument est le nom - de la macro, et les arguments suivants sont les paramètres. Il - est de bon aloi de préfixer les noms des paramètres d'une macro - avec un caractère parmi '$%@', et d'éviter d'en faire - de même avec les noms de macros. + de la macro, et les arguments suivants sont les paramètres. Il + est de bon aloi de préfixer les noms des paramètres d'une macro + avec un caractère parmi '$%@', et d'éviter d'en faire + de même avec les noms de macros.

    @@ -239,10 +239,10 @@ UndefMacro DirGroup

    La directive Use permet d'utiliser une macro. - La macro considérée est expansée. Son nombre d'arguments doit être égal au - nombre de paramètres précisés dans sa définition. Les valeurs passées en - argument sont attribuées aux paramètres correspondants et - substituées avant l'interprétation du texte de la macro.

    + La macro considérée est expansée. Son nombre d'arguments doit être égal au + nombre de paramètres précisés dans sa définition. Les valeurs passées en + argument sont attribuées aux paramètres correspondants et + substituées avant l'interprétation du texte de la macro.

    Use LocalAccessPolicy @@ -250,7 +250,7 @@ Use LocalAccessPolicy Use RestrictedAccessPolicy "192.54.172.0/24 192.54.148.0/24" -

    est équivalent, avec les macros définies ci-dessus à :

    +

    est équivalent, avec les macros définies ci-dessus à :

    Require ip 10.2.16.0/24 @@ -273,8 +273,8 @@ Require ip 192.54.172.0/24 192.54.148.0/24 -

    La directive UndefMacro annule la définition - d'une macro qui doit avoir été définie auparavant.

    +

    La directive UndefMacro annule la définition + d'une macro qui doit avoir été définie auparavant.

    UndefMacro LocalAccessPolicy