From: Lucien Gentis Date: Sun, 7 May 2017 15:48:50 +0000 (+0000) Subject: XML updates. X-Git-Tag: 2.5.0-alpha~420 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=75c95ac18e59275a37c2891aa8569410e965e557;p=thirdparty%2Fapache%2Fhttpd.git XML updates. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1794214 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/index.xml.fr b/docs/manual/index.xml.fr index 4b55f8bd3ea..d32833b797c 100644 --- a/docs/manual/index.xml.fr +++ b/docs/manual/index.xml.fr @@ -3,7 +3,7 @@ - + + @@ -91,10 +91,10 @@ l'authentification AuthType form AuthName "/admin" AuthFormLoginRequiredLocation "http://example.com/login.html" + Session On SessionCookieName session path=/ - SessionCryptoPassphrase secret - + Require valid-user </Location> @@ -109,15 +109,19 @@ l'authentification vérifiés en utilisant le fichier choisi.

Les directives Session, SessionCookieName et - SessionCryptoPassphrase - créent une session chiffrée stockée dans un cookie HTTP au niveau + module="mod_session">Session et SessionCookieName + créent une session stockée dans un cookie HTTP au niveau du navigateur. Pour plus d'informations à propos des différentes options de configuration des sessions, reportez-vous à la documentation du module mod_session.

+

Si vous le souhaitez, vous pouvez ajoutez une directive SessionCryptoPassphrase pour créer + un cookie de session chiffré. Le module + mod_session_crypto doit alors avoir été préalablement + chargé.

+

Dans l'exemple simple ci-dessus, une URL a été protégée par mod_auth_form, mais on doit maintenant fournir à l'utilisateur un moyen d'entrer un nom et un mot de passe. À cet @@ -161,14 +165,13 @@ l'authentification <Location "/dologin.html"> SetHandler form-login-handler AuthFormLoginRequiredLocation "http://example.com/login.html" - AuthFormLoginSuccessLocation "http://example.com/success.html" + AuthFormLoginSuccessLocation "http://example.com/admin/index.html" AuthFormProvider file AuthUserFile "conf/passwd" AuthType form - AuthName realm + AuthName /admin Session On SessionCookieName session path=/ - SessionCryptoPassphrase secret </Location> @@ -243,11 +246,10 @@ AuthFormProvider file ErrorDocument 401 "/login.shtml" AuthUserFile "conf/passwd" AuthType form -AuthName realm +AuthName /admin AuthFormLoginRequiredLocation "http://example.com/login.html" Session On SessionCookieName session path=/ -SessionCryptoPassphrase secret @@ -362,7 +364,6 @@ AuthName realm AuthFormLogoutLocation "http://example.com/loggedout.html" Session On SessionCookieName session path=/ -SessionCryptoPassphrase secret @@ -385,7 +386,6 @@ AuthFormLogoutLocation "http://example.com/loggedout.html" Session On SessionMaxAge 1 SessionCookieName session path=/ -SessionCryptoPassphrase secret @@ -479,6 +479,7 @@ connexion httpd_username directory +AuthConfig Disponible depuis la version 2.3.3 du serveur HTTP Apache @@ -497,6 +498,7 @@ de connexion httpd_password directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache @@ -516,6 +518,7 @@ réussie httpd_location directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache @@ -535,6 +538,7 @@ requête à effectuer en cas de connexion réussie httpd_method directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache @@ -562,6 +566,7 @@ réussie httpd_mimetype directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache @@ -588,6 +593,7 @@ requête à effectuer en cas de connexion réussie httpd_body directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache @@ -644,6 +650,7 @@ authentification est requise none directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache. L'interprétation des expressions rationnelles est supportée depuis la version 2.4.4. @@ -676,6 +683,7 @@ de connexion réussie none directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache. L'interprétation des expressions rationnelles est supportée depuis la version 2.4.4. @@ -705,6 +713,7 @@ depuis la version 2.4.4. AuthFormFakeBasicAuth Off directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache @@ -728,6 +737,7 @@ après s'être déconnecté none directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache. L'interprétation des expressions rationnelles est supportée depuis la version 2.4.4. @@ -772,6 +782,7 @@ connexion AuthFormDisableNoStore Off directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache @@ -796,6 +807,7 @@ trafic none directory +AuthConfig Disponible depuis la version 2.3.0 du serveur HTTP Apache diff --git a/docs/manual/mod/mod_authn_socache.xml.fr b/docs/manual/mod/mod_authn_socache.xml.fr index ebd260b35b5..c61d9cf831c 100644 --- a/docs/manual/mod/mod_authn_socache.xml.fr +++ b/docs/manual/mod/mod_authn_socache.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -25,47 +25,47 @@ mod_authn_socache -Gère un cache des données d'authentification pour diminuer -la charge des serveurs d'arrière-plan +Gère un cache des données d'authentification pour diminuer +la charge des serveurs d'arrière-plan Base mod_authn_socache.c authn_socache_module -Versions 2.3 et ultérieures +Versions 2.3 et ultérieures

-

Maintient un cache des données d'authentification pour limiter - les sollicitations du serveur d'arrière-plan.

+

Maintient un cache des données d'authentification pour limiter + les sollicitations du serveur d'arrière-plan.

 -
Mise en cache des données d'authentification +
Mise en cache des données d'authentification

Certains utilisateurs qui mettent oeuvre une authentification - lourde s'appuyant par exemple sur des requêtes SQL - (mod_authn_dbd) ont signalé une charge induite + lourde s'appuyant par exemple sur des requêtes SQL + (mod_authn_dbd) ont signalé une charge induite inacceptable sur leur fournisseur d'authentification. Cela se - produit typiquement dans le cas où une page HTML contient des + produit typiquement dans le cas où une page HTML contient des centaines d'objets (images, scripts, pages de styles, media, - etc...), et où une requête pour cette page génère des centaines de - sous-requêtes à effet immédiat pour des contenus supplémentaires - authentifiés.

-

Pour résoudre ce problème, mod_authn_socache fournit une solution - qui permet de maintenir un cache des données d'authentification.

+ etc...), et où une requête pour cette page génère des centaines de + sous-requêtes à effet immédiat pour des contenus supplémentaires + authentifiés.

+

Pour résoudre ce problème, mod_authn_socache fournit une solution + qui permet de maintenir un cache des données d'authentification.

Utilisation -

Le cache d'authentification doit être utilisé lorsque les - requêtes d'authentification induisent une charge significative sur le - serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache - n'apportera probablement aucune amélioration dans le cas d'une - authentification à base de fichier (mod_authn_file) - ou de base de données dbm (mod_authn_dbm) car ces - méthodes sont de par leur conception rapides et légères (la mise en - cache peut cependant s'avérer utile dans le cas où le fichier est - situé sur un montage réseau). Les fournisseurs d'authentification - basés sur SQL ou LDAP ont plus de chances de tirer parti de cette - mise en cache, en particulier lorsqu'un problème de performances est - détecté. mod_authnz_ldap gérant son propre cache, - seul mod_authn_dbd est concerné par notre sujet.

-

Les principales règles à appliquer pour la mise en cache sont :

+

Le cache d'authentification doit être utilisé lorsque les + requêtes d'authentification induisent une charge significative sur le + serveur, le serveur d'arrière-plan ou le réseau. Cette mise en cache + n'apportera probablement aucune amélioration dans le cas d'une + authentification à base de fichier (mod_authn_file) + ou de base de données dbm (mod_authn_dbm) car ces + méthodes sont de par leur conception rapides et légères (la mise en + cache peut cependant s'avérer utile dans le cas où le fichier est + situé sur un montage réseau). Les fournisseurs d'authentification + basés sur SQL ou LDAP ont plus de chances de tirer parti de cette + mise en cache, en particulier lorsqu'un problème de performances est + détecté. mod_authnz_ldap gérant son propre cache, + seul mod_authn_dbd est concerné par notre sujet.

+

Les principales règles à appliquer pour la mise en cache sont :

  1. Inclure le fournisseur pour lequel vous voulez effectuer une mise en cache dans une directive AuthnCacheProvideFor.
    2. @@ -75,11 +75,11 @@ la charge des serveurs d'arrière-plan ou AuthDigestProvider.
-

Voici un exemple simple permettant d'accélérer +

Voici un exemple simple permettant d'accélérer mod_authn_dbd et utilisant dbm comme moteur de la mise en cache :

- #AuthnCacheSOCache est optionnel. S'il est défini, il l'est pour + #AuthnCacheSOCache est optionnel. S'il est défini, il l'est pour #l'ensemble du serveur AuthnCacheSOCache dbm <Directory "/usr/www/myhost/private"> @@ -96,14 +96,14 @@ AuthnCacheSOCache dbm
La mise en cache avec les modules tiers -

Les développeurs de modules doivent savoir que la mise en cache - avec mod_authn_socache doit être activée dans leurs modules. La +

Les développeurs de modules doivent savoir que la mise en cache + avec mod_authn_socache doit être activée dans leurs modules. La fonction de l'API ap_authn_cache_store permet de - mettre en cache les données d'authentification qu'un fournisseur - vient de rechercher ou de générer. Vous trouverez des exemples - d'utilisation à r957072, où trois fournisseurs authn sont activés pour la mise + >r957072, où trois fournisseurs authn sont activés pour la mise en cache.

@@ -113,45 +113,43 @@ AuthnCacheSOCache dbm endroit AuthnCacheEnable server config -None -

Normalement, cette directive n'est pas nécessaire : l'activation - est implicite si la mise en cache de l'authentification a été - activée en tout autre endroit du fichier httpd.conf. Par - contre, si cette mise en cache n'a pas été activée, par défaut, elle - ne sera pas initialisée, et ne sera donc pas disponible dans un +

Normalement, cette directive n'est pas nécessaire : l'activation + est implicite si la mise en cache de l'authentification a été + activée en tout autre endroit du fichier httpd.conf. Par + contre, si cette mise en cache n'a pas été activée, par défaut, elle + ne sera pas initialisée, et ne sera donc pas disponible dans un contexte de fichier .htaccess. Cette directive permet - d'être sûr que la mise en cache a bien été activée et pourra - donc être utilisée dans les fichiers .htaccess.

+ d'être sûr que la mise en cache a bien été activée et pourra + donc être utilisée dans les fichiers .htaccess.

 AuthnCacheSOCache -Sélectionne le fournisseur socache d'arrière-plan à +Sélectionne le fournisseur socache d'arrière-plan à utiliser AuthnCacheSOCache nom-fournisseur[:arguments-fournisseur] server config -None Les arguments optionnels du fournisseur sont disponibles -à partir de la version 2.4.7 du serveur HTTP Apache +à partir de la version 2.4.7 du serveur HTTP Apache -

Cette définition s'applique à l'ensemble du serveur et permet de - sélectionner un fournisseur pour le cache - d'objets partagés, ainsi que des arguments éventuels pour ce +

Cette définition s'applique à l'ensemble du serveur et permet de + sélectionner un fournisseur pour le cache + d'objets partagés, ainsi que des arguments éventuels pour ce fournisseur. Les fournisseurs disponibles sont, entre autres, "dbm", - "dc", "memcache", ou "shmcb", chacun d'entre eux nécessitant le chargement - du module approprié. Si elle est - absente, c'est la valeur par défaut pour votre plate-forme qui sera - utilisée.

+ "dc", "memcache", ou "shmcb", chacun d'entre eux nécessitant le chargement + du module approprié. Si elle est + absente, c'est la valeur par défaut pour votre plate-forme qui sera + utilisée.

 AuthnCacheProvideFor -Spécifie le fournisseur pour lequel on veut effectuer une +Spécifie le fournisseur pour lequel on veut effectuer une mise en cache AuthnCacheProvideFor fournisseur-authn [...] None @@ -159,15 +157,15 @@ mise en cache AuthConfig -

Cette directive permet de spécifier un ou plusieurs fournisseurs - pour le(s)quel(s) on veut effectuer une mise en cache. Les données - d'authentification trouvées par un fournisseur non spécifié dans une +

Cette directive permet de spécifier un ou plusieurs fournisseurs + pour le(s)quel(s) on veut effectuer une mise en cache. Les données + d'authentification trouvées par un fournisseur non spécifié dans une directive AuthnCacheProvideFor ne seront pas mises en cache.

-

Par exemple, pour mettre en cache les données d'authentification - trouvées par mod_authn_dbd ou par un fournisseur - personnalisé mon-fournisseur, et ne pas mettre en cache - celles trouvées par les fournisseurs légers comme file ou dbm :

+

Par exemple, pour mettre en cache les données d'authentification + trouvées par mod_authn_dbd ou par un fournisseur + personnalisé mon-fournisseur, et ne pas mettre en cache + celles trouvées par les fournisseurs légers comme file ou dbm :

AuthnCacheProvideFor dbd mon-fournisseur @@ -176,60 +174,60 @@ AuthnCacheProvideFor dbd mon-fournisseur AuthnCacheTimeout -Définit une durée de vie pour les entrées du cache -AuthnCacheTimeout durée-de-vie (secondes) +Définit une durée de vie pour les entrées du cache +AuthnCacheTimeout durée-de-vie (secondes) 300 (5 minutes) directory.htaccess AuthConfig -

La mise en cache des données d'authentification peut constituer - un trou de sécurité, bien qu'un mise en cache de courte durée ne - posera probablement pas de problème. En général, il est conseillé de - conserver les entrées du cache de façon à ce que la charge du serveur - d'arrière-plan reste normale, mais pas plus longtemps ; - une durée de vie plus longue peut être paramétrée si les - changements d'utilisateurs et de mots de passe sont peu fréquents. - La durée de vie par défaut de 300 secondes (5 minutes) est à la fois - raisonnable et suffisamment importante pour réduire la charge d'un - serveur d'arrière-plan comme dbd (requêtes SQL).

-

Cette durée de vie ne doit pas être confondue avec la durée de +

La mise en cache des données d'authentification peut constituer + un trou de sécurité, bien qu'un mise en cache de courte durée ne + posera probablement pas de problème. En général, il est conseillé de + conserver les entrées du cache de façon à ce que la charge du serveur + d'arrière-plan reste normale, mais pas plus longtemps ; + une durée de vie plus longue peut être paramétrée si les + changements d'utilisateurs et de mots de passe sont peu fréquents. + La durée de vie par défaut de 300 secondes (5 minutes) est à la fois + raisonnable et suffisamment importante pour réduire la charge d'un + serveur d'arrière-plan comme dbd (requêtes SQL).

+

Cette durée de vie ne doit pas être confondue avec la durée de vie de session qui est un tout autre sujet. Cependant, vous devez - utiliser votre logiciel de gestion de session pour vérifier si les - données d'authentification mises en cache peuvent allonger + utiliser votre logiciel de gestion de session pour vérifier si les + données d'authentification mises en cache peuvent allonger accidentellement une session, et en tenir compte lorsque vous - définissez la durée de vie.

+ définissez la durée de vie.

 AuthnCacheContext -Spécifie une chaîne de contexte à utiliser dans la clé du +Spécifie une chaîne de contexte à utiliser dans la clé du cache -AuthnCacheContext directory|server|chaîne-personnalisée +AuthnCacheContext directory|server|chaîne-personnalisée directory directory -

Cette directive permet de spécifier une chaîne à utiliser avec le +

Cette directive permet de spécifier une chaîne à utiliser avec le nom d'utilisateur fourni (et le domaine d'authentification - realm - - dans le cas d'une authentification à base de condensés) lors de la - construction d'une clé de cache. Ceci permet de lever l'ambiguïté - entre plusieurs noms d'utilisateurs identiques servant différentes + dans le cas d'une authentification à base de condensés) lors de la + construction d'une clé de cache. Ceci permet de lever l'ambiguïté + entre plusieurs noms d'utilisateurs identiques servant différentes zones d'authentification sur le serveur.

-

Il y a deux valeurs spéciales pour le paramètre : directory, - qui utilise le contexte de répertoire de la requête comme chaîne, et +

Il y a deux valeurs spéciales pour le paramètre : directory, + qui utilise le contexte de répertoire de la requête comme chaîne, et server, qui utilise le nom du serveur virtuel.

-

La valeur par défaut est directory, qui est aussi la - définition la plus courante. Ceci est cependant loin d'être optimal, +

La valeur par défaut est directory, qui est aussi la + définition la plus courante. Ceci est cependant loin d'être optimal, car par exemple, $app-base, $app-base/images, $app-base/scripts et $app-base/media - possèderont chacun leur propre clé de cache. Il est préférable + possèderont chacun leur propre clé de cache. Il est préférable d'utiliser le fournisseur de mot de passe : par exemple un fichier - htpasswd ou une table de base de données.

-

Les contextes peuvent être partagés entre différentes zones du - serveur, où les données d'authentification sont partagées. Ceci est - cependant susceptible de créer des trous de sécurité de type + htpasswd ou une table de base de données.

+

Les contextes peuvent être partagés entre différentes zones du + serveur, où les données d'authentification sont partagées. Ceci est + cependant susceptible de créer des trous de sécurité de type cross-site ou cross-application, et cette directive n'est donc pas disponible dans les contextes .htaccess.

 diff --git a/docs/manual/mod/mod_authz_core.xml.fr b/docs/manual/mod/mod_authz_core.xml.fr index 193f2eb705d..8b1e449e6b9 100644 --- a/docs/manual/mod/mod_authz_core.xml.fr +++ b/docs/manual/mod/mod_authz_core.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -33,14 +33,14 @@ d'Apache HTTPD -

Ce module fournit un socle de fonctionnalités d'autorisation - permettant d'accorder ou refuser l'accès à certaines zones du site - web aux utilisateurs authentifiés. mod_authz_core - donne la possibilité d'enregistrer divers fournisseurs - d'autorisation. Il est en général utilisé avec un module fournisseur +

Ce module fournit un socle de fonctionnalités d'autorisation + permettant d'accorder ou refuser l'accès à certaines zones du site + web aux utilisateurs authentifiés. mod_authz_core + donne la possibilité d'enregistrer divers fournisseurs + d'autorisation. Il est en général utilisé avec un module fournisseur d'authentification comme mod_authn_file, et un module d'autorisation comme mod_authz_user. Il - permet aussi l'application d'une logique élaborée au déroulement du + permet aussi l'application d'une logique élaborée au déroulement du processus d'autorisation.

 @@ -51,19 +51,19 @@ d'Apache HTTPD RequireAny et RequireNone - peuvent être combinées entre elles et avec la directive Require pour construire une logique d'autorisation complexe.

L'exemple ci-dessous illustre la logique d'autorisation suivante. - Pour pouvoir accéder à la ressource, l'utilisateur doit être + Pour pouvoir accéder à la ressource, l'utilisateur doit être l'utilisateur superadmin, ou appartenir aux deux groupes LDAP admins et Administrateurs et soit appartenir au groupe ventes, soit avoir ventes comme valeur de l'attribut LDAP - dept. De plus, pour pouvoir accéder à la ressource, + dept. De plus, pour pouvoir accéder à la ressource, l'utilisateur ne doit appartenir ni au groupe temps, ni - au groupe LDAP Employés temporaires.

+ au groupe LDAP Employés temporaires.

<Directory "/www/mydocs"> @@ -81,7 +81,7 @@ d'Apache HTTPD </RequireAny> <RequireNone> Require group temps - Require ldap-group "cn=Employés temporaires,o=Airius" + Require ldap-group "cn=Employés temporaires,o=Airius" </RequireNone> </RequireAll> </Directory> @@ -90,23 +90,23 @@ d'Apache HTTPD
Les directives Require -

Le module mod_authz_core met à disposition des - fournisseurs d'autorisation génériques utilisables avec la directive +

Le module mod_authz_core met à disposition des + fournisseurs d'autorisation génériques utilisables avec la directive Require.

Require env -

Le fournisseur env permet de contrôler l'accès au +

Le fournisseur env permet de contrôler l'accès au serveur en fonction de l'existence d'une variable d'environnement. Lorsque Require - env env-variable est spécifié, la requête se voit - autoriser l'accès si la variable d'environnement - env-variable existe. Le serveur permet de définir + env env-variable est spécifié, la requête se voit + autoriser l'accès si la variable d'environnement + env-variable existe. Le serveur permet de définir facilement des variables d'environnement en fonction des - caractéristiques de la requête du client via les directives fournies + caractéristiques de la requête du client via les directives fournies par le module mod_setenvif. Cette directive Require - env permet donc de contrôler l'accès en fonction des - valeurs des en-têtes de la requête HTTP tels que + env permet donc de contrôler l'accès en fonction des + valeurs des en-têtes de la requête HTTP tels que User-Agent (type de navigateur), Referer, entre autres.

@@ -117,31 +117,31 @@ SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in </Directory> -

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

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

+ l'accès, alors que tous les autres seront rejetés.

Lorsque le serveur cherche un chemin via une sous-requête interne (par exemple la + ref="subrequest">sous-requête interne (par exemple la recherche d'un DirectoryIndex), ou lorsqu'il génère un - listing du contenu d'un répertoire via le module - mod_autoindex, la sous-requête n'hérite pas des - variables d'environnement spécifiques à la requête. En outre, à cause + module="mod_dir">DirectoryIndex), ou lorsqu'il génère un + listing du contenu d'un répertoire via le module + mod_autoindex, la sous-requête n'hérite pas des + variables d'environnement spécifiques à la requête. En outre, à cause des phases de l'API auxquelles mod_setenvif prend part, les directives SetEnvIf ne sont pas évaluées - séparément dans la sous-requête.

+ module="mod_setenvif">SetEnvIf ne sont pas évaluées + séparément dans la sous-requête.

Require all -

Le fournisseur all reproduit la fonctionnalité - précédemment fournie par les directives 'Allow from all' et 'Deny +

Le fournisseur all reproduit la fonctionnalité + précédemment fournie par les directives 'Allow from all' et 'Deny from all'. Il accepte un argument dont les deux valeurs possibles sont : 'granted' ou 'denied'. Les exemples suivants autorisent ou - interdisent l'accès à toutes les requêtes.

+ interdisent l'accès à toutes les requêtes.

Require all granted @@ -155,22 +155,22 @@ SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in
Require method -

Le fournisseur method permet d'utiliser la méthode - HTTP dans le processus d'autorisation. Les méthodes GET et HEAD sont - ici considérées comme équivalentes. La méthode TRACE n'est pas - supportée par ce fournisseur ; utilisez à la place la directive +

Le fournisseur method permet d'utiliser la méthode + HTTP dans le processus d'autorisation. Les méthodes GET et HEAD sont + ici considérées comme équivalentes. La méthode TRACE n'est pas + supportée par ce fournisseur ; utilisez à la place la directive TraceEnable.

-

Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et - OPTIONS sont autorisées :

+

Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et + OPTIONS sont autorisées :

Require method GET POST OPTIONS -

Dans l'exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS - sont autorisées sans authentification, alors que toutes les autres - méthodes nécessitent un utilisateur valide :

+

Dans l'exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS + sont autorisées sans authentification, alors que toutes les autres + méthodes nécessitent un utilisateur valide :

<RequireAny> @@ -183,7 +183,7 @@ SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in
Require expr

Le fournisseur expr permet d'accorder l'autorisation - d'accès en fonction d'expressions arbitraires.

+ d'accès en fonction d'expressions arbitraires.

Require expr %{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17 @@ -200,42 +200,42 @@ SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" -

La syntaxe de l'expression est décrite dans la documentation de La syntaxe de l'expression est décrite dans la documentation de ap_expr.

-

Normalement, l'expression est évaluée avant l'authentification. - Cependant, si l'expression renvoie false et se réfère à la variable +

Normalement, l'expression est évaluée avant l'authentification. + Cependant, si l'expression renvoie false et se réfère à la variable %{REMOTE_USER}, le processus d'authentification sera - engagé et l'expression réévaluée.

+ engagé et l'expression réévaluée.

-
Création des alias du fournisseur +<section id="authzalias"><title>Création des alias du fournisseur d'autorisation -

Il est possible de créer des fournisseurs d'autorisation étendus +

Il est possible de créer des fournisseurs d'autorisation étendus dans le fichier de configuration et de leur assigner un nom d'alias. - On peut ensuite utiliser ces fournisseurs aliasés dans une + On peut ensuite utiliser ces fournisseurs aliasés dans une directive Require de - la même manière qu'on le ferait pour des fournisseurs d'autorisation - de base. En plus de la possibilité de créer et d'aliaser un - fournisseur étendu, le même fournisseur d'autorisation étendu peut - être référencé par diverses localisations. + la même manière qu'on le ferait pour des fournisseurs d'autorisation + de base. En plus de la possibilité de créer et d'aliaser un + fournisseur étendu, le même fournisseur d'autorisation étendu peut + être référencé par diverses localisations.

Exemple -

Dans l'exemple suivant, on crée deux alias de fournisseur - d'autorisation ldap différents basés sur le fournisseur +

Dans l'exemple suivant, on crée deux alias de fournisseur + d'autorisation ldap différents basés sur le fournisseur d'autorisation ldap-group. Il est ainsi possible pour un seul - répertoire de vérifier l'appartenance à un groupe dans plusieurs + répertoire de vérifier l'appartenance à un groupe dans plusieurs serveurs ldap :

<AuthzProviderAlias ldap-group ldap-group-alias1 "cn=my-group,o=ctx"> - AuthLDAPBindDN cn=youruser,o=ctx + AuthLDAPBindDN "cn=youruser,o=ctx" AuthLDAPBindPassword yourpassword AuthLDAPURL "ldap://ldap.host/o=ctx" </AuthzProviderAlias> @@ -255,7 +255,7 @@ Alias "/secure" "/webpages/secure" AuthType Basic AuthName LDAP_Protected_Place - #Opération logique implicite : OU inclusif + #Opération logique implicite : OU inclusif Require ldap-group-alias1 Require ldap-group-alias2 </Directory> @@ -267,44 +267,44 @@ Alias "/secure" "/webpages/secure" Require -Vérifie si un utilisateur authentifié a une -autorisation d'accès accordée par un fournisseur +Vérifie si un utilisateur authentifié a une +autorisation d'accès accordée par un fournisseur d'autorisation. -Require [not] nom-entité [nom-entité] +Require [not] nom-entité [nom-entité] ... directory.htaccess AuthConfig -

Cette directive permet de vérifier si un utilisateur authentifié - a l'autorisation d'accès accordée pour un certain fournisseur +

Cette directive permet de vérifier si un utilisateur authentifié + a l'autorisation d'accès accordée pour un certain fournisseur d'autorisation et en tenant compte de certaines restrictions. - mod_authz_core met à disposition les fournisseurs - d'autorisation génériques suivants :

+ mod_authz_core met à disposition les fournisseurs + d'autorisation génériques suivants :

Require all granted
-
L'accès est autorisé sans restriction.
+
L'accès est autorisé sans restriction.
Require all denied
-
L'accès est systématiquement refusé.
+
L'accès est systématiquement refusé.
Require env env-var [env-var] ...
-
L'accès n'est autorisé que si l'une au moins des variables - d'environnement spécifiées est définie.
+
L'accès n'est autorisé que si l'une au moins des variables + d'environnement spécifiées est définie.
Require method http-method [http-method] ...
-
L'accès n'est autorisé que pour les méthodes HTTP spécifiées.
+
L'accès n'est autorisé que pour les méthodes HTTP spécifiées.
Require expr expression
-
L'accès est autorisé si expression est évalué à +
L'accès est autorisé si expression est évalué à vrai.
-

Voici quelques exemples de syntaxes autorisées par +

Voici quelques exemples de syntaxes autorisées par mod_authz_user, mod_authz_host et mod_authz_groupfile :

@@ -312,33 +312,33 @@ d'autorisation.
Require user identifiant utilisateur [identifiant utilisateur] ...
-
Seuls les utilisateurs spécifiés auront accès à la +
Seuls les utilisateurs spécifiés auront accès à la ressource.
Require group nom groupe [nom groupe] ...
-
Seuls les utilisateurs appartenant aux groupes spécifiés - auront accès à la ressource.
+
Seuls les utilisateurs appartenant aux groupes spécifiés + auront accès à la ressource.
Require valid-user
-
Tous les utilisateurs valides auront accès à la +
Tous les utilisateurs valides auront accès à la ressource.
Require ip 10 172.20 192.168.2
Les clients dont les adresses IP font partie des tranches - spécifiées auront accès à la ressource.
+ spécifiées auront accès à la ressource.

D'autres modules d'autorisation comme mod_authnz_ldap, mod_authz_dbm, mod_authz_dbd, mod_authz_owner et mod_ssl - implémentent des options de la directive Require.

+ implémentent des options de la directive Require.

Pour qu'une configuration d'authentification et d'autorisation fonctionne correctement, la directive Require - doit être accompagnée dans la plupart des cas de directives AuthName, AuthType et AuthBasicProvider ou de directives telles que AuthUserFile et AuthGroupFile (pour la - définition des utilisateurs et des groupes). Exemple :

+ définition des utilisateurs et des groupes). Exemple :

AuthType Basic @@ -357,25 +357,25 @@ AuthGroupFile "/web/groups" Require group admin -

Les contrôles d'accès appliqués de cette manière sont effectifs - pour toutes les méthodes. C'est d'ailleurs - ce que l'on souhaite en général. Si vous voulez n'appliquer - les contrôles d'accès qu'à certaines méthodes, tout en laissant les - autres méthodes sans protection, placez la directive +

Les contrôles d'accès appliqués de cette manière sont effectifs + pour toutes les méthodes. C'est d'ailleurs + ce que l'on souhaite en général. Si vous voulez n'appliquer + les contrôles d'accès qu'à certaines méthodes, tout en laissant les + autres méthodes sans protection, placez la directive Require dans une section Limit.

-

Le résultat de la directive Require peut - être inversé en utilisant l'option not. Comme dans le - cas de l'autre directive d'autorisation inversée Le résultat de la directive Require peut + être inversé en utilisant l'option not. Comme dans le + cas de l'autre directive d'autorisation inversée RequireNone, si la directive - Require est inversée, elle ne peut qu'échouer - ou produire un résultat neutre ; elle ne peut donc alors pas - en soi autoriser une requête.

+ Require est inversée, elle ne peut qu'échouer + ou produire un résultat neutre ; elle ne peut donc alors pas + en soi autoriser une requête.

Dans l'exemple suivant, tous les utilisateurs appartenant aux groupes alpha et beta ont l'autorisation - d'accès, à l'exception de ceux appartenant au groupe + d'accès, à l'exception de ceux appartenant au groupe reject.

@@ -388,35 +388,35 @@ Require group admin

Lorsque plusieurs directives Require sont - placées dans une même section de + placées dans une même section de configuration, et ne se trouvent pas dans une autre directive d'autorisation comme RequireAll, elles sont implicitement contenues dans une directive RequireAny. Ainsi, la première directive - Require qui autorise l'accès à un utilisateur - autorise l'accès pour l'ensemble de la requête, et les directives - Require suivantes sont ignorées.

- - Avertissement à propos de la sécurité -

Prettez une attention particulière aux directives d'autorisation - définies + type="section">RequireAny. Ainsi, la première directive + Require qui autorise l'accès à un utilisateur + autorise l'accès pour l'ensemble de la requête, et les directives + Require suivantes sont ignorées.

+ + Avertissement à propos de la sécurité +

Prettez une attention particulière aux directives d'autorisation + définies au sein des sections Location - qui se chevauchent avec des contenus servis depuis le système de - fichiers. Par défaut, les configurations définies dans ces sections l'emportent sur les - configurations d'autorisations définies au sein des sections + configurations d'autorisations définies au sein des sections Directory et Files sections.

La directive AuthMerging permet de contrôler - la manière selon laquelle les configurations d'autorisations sont - fusionnées au sein des sections précitées.

+ module="mod_authz_core">AuthMerging permet de contrôler + la manière selon laquelle les configurations d'autorisations sont + fusionnées au sein des sections précitées.

 -Tutoriel du contrôle d'accès +Tutoriel du contrôle d'accès Conteneurs d'autorisation mod_authn_core mod_authz_host @@ -425,8 +425,8 @@ Require group admin RequireAll Regroupe plusieurs directives d'autorisation dont aucune ne -doit échouer et dont au moins une doit retourner un résultat positif -pour que la directive globale retourne elle-même un résultat +doit échouer et dont au moins une doit retourner un résultat positif +pour que la directive globale retourne elle-même un résultat positif. <RequireAll> ... </RequireAll> directory.htaccess @@ -436,31 +436,31 @@ positif.

Les balises RequireAll et </RequireAll> permettent de regrouper des - directives d'autorisation dont aucune ne doit échouer, et dont au - moins une doit retourner un résultat positif pour que la directive - RequireAll retourne elle-même - un résultat positif.

+ directives d'autorisation dont aucune ne doit échouer, et dont au + moins une doit retourner un résultat positif pour que la directive + RequireAll retourne elle-même + un résultat positif.

Si aucune des directives contenues dans la directive RequireAll n'échoue, et si au moins une - retourne un résultat positif, alors la directive RequireAll retourne elle-même un résultat - positif. Si aucune ne retourne un résultat positif, et si aucune - n'échoue, la directive globale retourne un résultat neutre. Dans - tous les autres cas, elle échoue.

+ type="section">RequireAll n'échoue, et si au moins une + retourne un résultat positif, alors la directive RequireAll retourne elle-même un résultat + positif. Si aucune ne retourne un résultat positif, et si aucune + n'échoue, la directive globale retourne un résultat neutre. Dans + tous les autres cas, elle échoue.

 Conteneurs d'autorisation Authentification, autorisation et -contrôle d'accès +contrôle d'accès RequireAny Regroupe des directives d'autorisation dont au moins une -doit retourner un résultat positif pour que la directive globale -retourne elle-même un résultat positif. +doit retourner un résultat positif pour que la directive globale +retourne elle-même un résultat positif. <RequireAny> ... </RequireAny> directory.htaccess @@ -470,40 +470,40 @@ retourne elle-même un résultat positif.

Les balises RequireAny et </RequireAny> permettent de regrouper des directives d'autorisation dont au moins une doit retourner un - résultat positif pour que la directive RequireAny retourne elle-même un résultat + résultat positif pour que la directive RequireAny retourne elle-même un résultat positif.

Si une ou plusieurs directives contenues dans la directive RequireAny retournent un - résultat positif, alors la directive RequireAny retourne elle-même un résultat - positif. Si aucune ne retourne un résultat positif et aucune - n'échoue, la directive globale retourne un résultat neutre. Dans - tous les autres cas, elle échoue.

- - Comme les directives d'autorisation inversées sont incapables - de retourner un résultat positif, elles ne peuvent pas impacter de - manière significative le résultat d'une directive RequireAny retourne elle-même un résultat + positif. Si aucune ne retourne un résultat positif et aucune + n'échoue, la directive globale retourne un résultat neutre. Dans + tous les autres cas, elle échoue.

+ + Comme les directives d'autorisation inversées sont incapables + de retourner un résultat positif, elles ne peuvent pas impacter de + manière significative le résultat d'une directive RequireAny (elles pourraient tout au plus - faire échouer la directive dans le cas où elles échoueraient - elles-mêmes, et où - toutes les autres directives retourneraient un résultat neutre). + faire échouer la directive dans le cas où elles échoueraient + elles-mêmes, et où + toutes les autres directives retourneraient un résultat neutre). C'est pourquoi il n'est pas permis d'utiliser les directives - d'autorisation inversées dans une directive RequireAny. Conteneurs d'autorisation Authentification, autorisation et -contrôle d'accès +contrôle d'accès RequireNone Regroupe des directives d'autorisation dont aucune ne doit -retourner un résultat positif pour que la directive globale n'échoue +retourner un résultat positif pour que la directive globale n'échoue pas. <RequireNone> ... </RequireNone> directory.htaccess @@ -513,41 +513,41 @@ pas.

Les balises RequireNone et </RequireNone> permettent de regrouper des - directives d'autorisation dont aucune ne doit retourner un résultat + directives d'autorisation dont aucune ne doit retourner un résultat positif pour que la directive RequireNone n'échoue pas.

+ type="section">RequireNone n'échoue pas.

Si une ou plusieurs directives contenues dans la directive RequireNone retournent un - résultat positif, la directive RequireNone échouera. Dans tous les - autres cas, cette dernière retournera un résultat neutre. Ainsi, - comme pour la directive d'autorisation inversée Require - not, elle ne peut jamais en soi autoriser une requête - car elle ne pourra jamais retourner un résultat + résultat positif, la directive RequireNone échouera. Dans tous les + autres cas, cette dernière retournera un résultat neutre. Ainsi, + comme pour la directive d'autorisation inversée Require + not, elle ne peut jamais en soi autoriser une requête + car elle ne pourra jamais retourner un résultat positif. Par contre, on peut l'utiliser pour restreindre l'ensemble - des utilisateurs autorisés à accéder à une ressource.

+ des utilisateurs autorisés à accéder à une ressource.

- Comme les directives d'autorisation inversées sont incapables - de retourner un résultat positif, elles ne peuvent pas impacter de - manière significative le résultat d'une directive Comme les directives d'autorisation inversées sont incapables + de retourner un résultat positif, elles ne peuvent pas impacter de + manière significative le résultat d'une directive RequireNone. C'est pourquoi il n'est pas permis d'utiliser les directives - d'autorisation inversées dans une directive RequireNone. Conteneurs d'autorisation Authentification, autorisation et -contrôle d'accès +contrôle d'accès AuthMerging -Définit la manière dont chaque logique d'autorisation des +Définit la manière dont chaque logique d'autorisation des sections de configuration se combine avec celles des sections de -configuration précédentes. +configuration précédentes. AuthMerging Off | And | Or AuthMerging Off directory.htaccess @@ -555,44 +555,44 @@ configuration précédentes. AuthConfig -

Lorsque l'autorisation est activée, elle est normalement héritée +

Lorsque l'autorisation est activée, elle est normalement héritée par chaque section de - configuration suivante, à moins qu'un jeu de directives - d'autorisations différent ne soit spécifié. Il s'agit du - comportement par défaut, qui correspond à la définition explicite + configuration suivante, à moins qu'un jeu de directives + d'autorisations différent ne soit spécifié. Il s'agit du + comportement par défaut, qui correspond à la définition explicite AuthMerging Off.

-

Dans certaines situations cependant, il peut être souhaitable de +

Dans certaines situations cependant, il peut être souhaitable de combiner la logique d'autorisation d'une section de configuration - avec celle de la section précédente lorsque les sections de + avec celle de la section précédente lorsque les sections de configuration se combinent entre elles. Dans ce cas, deux options sont disponibles, And et Or.

Lorsqu'une section de configuration contient AuthMerging And ou AuthMerging Or, sa logique d'autorisation - se combine avec celle de la section de configuration qui la précède - (selon l'ordre général des sections de configuration), et qui + se combine avec celle de la section de configuration qui la précède + (selon l'ordre général des sections de configuration), et qui contient aussi une logique d'autorisation, comme si les deux - sections étaient concaténées, respectivement, dans une directive + sections étaient concaténées, respectivement, dans une directive RequireAll ou RequireAny.

- La définition de la directive + La définition de la directive AuthMerging ne concerne que la section de - configuration dans laquelle elle apparaît. Dans l'exemple suivant, + configuration dans laquelle elle apparaît. Dans l'exemple suivant, seuls les utilisateurs appartenant au groupe alpha sont - autorisés à accéder à /www/docs. Les utilisateurs + autorisés à accéder à /www/docs. Les utilisateurs appartenant au groupe alpha ou au groupe - beta sont autorisés à accéder à - /www/docs/ab. Cependant, la définition implicite à + beta sont autorisés à accéder à + /www/docs/ab. Cependant, la définition implicite à Off de la directive AuthMerging - s'applique à la section de configuration Directory concernant le répertoire + s'applique à la section de configuration Directory concernant le répertoire /www/docs/ab/gamma, ce qui implique que les directives d'autorisation de cette section l'emportent sur celles des sections - précédentes. Par voie de conséquence, seuls les utilisateurs - appartenant au groupe gamma sont autorisés à accéder à + précédentes. Par voie de conséquence, seuls les utilisateurs + appartenant au groupe gamma sont autorisés à accéder à /www/docs/ab/gamma. @@ -619,11 +619,11 @@ configuration précédentes. AuthzProviderAlias -Regroupe des directives représentant une extension d'un -fournisseur d'autorisation de base qui pourra être référencée à l'aide -de l'alias spécifié +Regroupe des directives représentant une extension d'un +fournisseur d'autorisation de base qui pourra être référencée à l'aide +de l'alias spécifié <AuthzProviderAlias fournisseur-de-base Alias -Paramètres-Require> +Paramètres-Require> ... </AuthzProviderAlias> server config @@ -633,8 +633,8 @@ Paramètres-Require>

Les balises AuthzProviderAlias et </AuthzProviderAlias> permettent de regrouper des - directives d'autorisation auxquelles on pourra faire référence à - l'aide de l'alias spécifié dans une directive Require.

 @@ -643,27 +643,28 @@ Paramètres-Require> AuthzSendForbiddenOnFailure Envoie '403 FORBIDDEN' au lieu de '401 UNAUTHORIZED' si -l'authentification réussit et si l'autorisation a été refusée. +l'authentification réussit et si l'autorisation a été refusée. AuthzSendForbiddenOnFailure On|Off AuthzSendForbiddenOnFailure Off directory.htaccess +AuthConfig Disponible depuis la version 2.3.11 d'Apache HTTPD -

Par défaut, si l'authentification réussit, alors que - l'autorisation est refusée, Apache HTTPD renvoie un code de réponse - HTTP '401 UNAUTHORIZED'. En général, les navigateurs proposent alors - une nouvelle fois à l'utilisateur la boîte de dialogue de saisie du +

Par défaut, si l'authentification réussit, alors que + l'autorisation est refusée, Apache HTTPD renvoie un code de réponse + HTTP '401 UNAUTHORIZED'. En général, les navigateurs proposent alors + une nouvelle fois à l'utilisateur la boîte de dialogue de saisie du mot de passe, ce qui n'est pas toujours souhaitable. La directive AuthzSendForbiddenOnFailure permet de changer - le code de réponse en '403 FORBIDDEN'.

+ le code de réponse en '403 FORBIDDEN'.

- Avertissement de sécurité -

La modification de la réponse en cas de refus d'autorisation - diminue la sécurité du mot de passe, car elle indique à un éventuel - attaquant que le mot de passe qu'il a saisi était correct.

+ Avertissement de sécurité +

La modification de la réponse en cas de refus d'autorisation + diminue la sécurité du mot de passe, car elle indique à un éventuel + attaquant que le mot de passe qu'il a saisi était correct.

 diff --git a/docs/manual/mod/mod_authz_host.xml.fr b/docs/manual/mod/mod_authz_host.xml.fr index af688351e0c..2321c213f17 100644 --- a/docs/manual/mod/mod_authz_host.xml.fr +++ b/docs/manual/mod/mod_authz_host.xml.fr @@ -1,7 +1,7 @@ - + @@ -30,8 +30,8 @@ IP) Base mod_authz_host.c authz_host_module -Disponible depuis les versions 2.3 et supérieures -d'Apache +Le fournisseur forward-dns est disponible à partir +de la version 2.4.19 du serveur HTTP Apache

Les fournisseurs d'autorisation implémentés par le module @@ -188,6 +188,8 @@ Require forward-dns bla.example.org

Un client dont l'adresse IP correspond au nom d'hôte bla.example.org se verra autoriser l'accès.

+

Le fournisseur forward-dns est disponible à partir de la + version 2.4.19 du serveur HTTP Apache.

Require local diff --git a/docs/manual/mod/mod_deflate.xml.fr b/docs/manual/mod/mod_deflate.xml.fr index 3c6f8f8f340..83117a3c05b 100644 --- a/docs/manual/mod/mod_deflate.xml.fr +++ b/docs/manual/mod/mod_deflate.xml.fr @@ -1,7 +1,7 @@ - + @@ -428,6 +428,7 @@ de la compression compression server configvirtual host directory.htaccess +All Disponible à partir de la version 2.4.10 du serveur HTTP Apache @@ -448,6 +449,7 @@ Apache 200 server configvirtual host directory.htaccess +All Disponible à partir de la version 2.4.10 du serveur HTTP Apache @@ -470,6 +472,7 @@ corps de requête peut être dépassé 3 server configvirtual host directory.htaccess +All Disponible à partir de la version 2.4.10 du serveur HTTP Apache diff --git a/docs/manual/mod/mod_example_hooks.xml.fr b/docs/manual/mod/mod_example_hooks.xml.fr index 7773a3c9fbf..f9a363fc330 100644 --- a/docs/manual/mod/mod_example_hooks.xml.fr +++ b/docs/manual/mod/mod_example_hooks.xml.fr @@ -1,7 +1,7 @@ - + - + @@ -31,34 +31,34 @@ example_hooks_module -

Certains fichiers situés dans le répertoire +

Certains fichiers situés dans le répertoire modules/examples de l'arborescence de la - distribution d'Apache sont fournis à titre d'exemples pour ceux qui - souhaitent écrire des modules qui utilisent l'API d'Apache.

+ distribution d'Apache sont fournis à titre d'exemples pour ceux qui + souhaitent écrire des modules qui utilisent l'API d'Apache.

Le fichier principal est mod_example_hooks.c, qui - constitue une illustration exhaustive des différents mécanismes et - syntaxes d'appels. En aucun cas un module additionnel n'aura à - inclure des routines pour tous les appels - il n'en nécessitera au + constitue une illustration exhaustive des différents mécanismes et + syntaxes d'appels. En aucun cas un module additionnel n'aura à + inclure des routines pour tous les appels - il n'en nécessitera au contraire qu'un petit nombre !

-

Le module example_hooks fonctionne réellement. Si vous le chargez dans +

Le module example_hooks fonctionne réellement. Si vous le chargez dans votre serveur, activez le gestionnaire "example-hooks-handler" dans une - section location, et essayez d'accéder à la zone du site web + section location, et essayez d'accéder à la zone du site web correspondante, vous verrez s'afficher certaines sorties que le - module example_hooks produit au cours des différents appels.

+ module example_hooks produit au cours des différents appels.
Compilation du module example_hooks

Pour inclure le module example_hooks dans votre serveur, effectuez les - étapes suivantes :

+ étapes suivantes :

    -
  1. Exécutez configure avec l'option +
  2. Exécutez configure avec l'option --enable-example-hooks.
    3. -
  3. Compilez le serveur (exécutez la commande +
  4. Compilez le serveur (exécutez la commande "make").
@@ -70,35 +70,35 @@
  • Modifiez le fichier.
    • -
  • Créez modules/nouveau_module/config.m4. +
  • Créez modules/nouveau_module/config.m4.
    1. Ajoutez APACHE_MODPATH_INIT(nouveau_module).
    2. Copiez la ligne APACHE_MODULE contenant "example_hooks" depuis modules/examples/config.m4.
    3. Remplacez le premier argument "example-hooks" par monexemple.
      4. -
    4. Remplacez le second argument par une brève description de - votre module. Cette description sera utilisée par la commande +
    5. Remplacez le second argument par une brève description de + votre module. Cette description sera utilisée par la commande configure --help.
      6. -
    6. Si la compilation de votre module nécessite des drapeaux - de compilation C, des drapeaux d'édition de liens, ou de - bibliothèques supplémentaires, ajoutez les respectivement à +
    7. Si la compilation de votre module nécessite des drapeaux + de compilation C, des drapeaux d'édition de liens, ou de + bibliothèques supplémentaires, ajoutez les respectivement à CFLAGS, LDFLAGS et LIBS. Reportez-vous aux fichiers - config.m4 des répertoires des autres modules pour + config.m4 des répertoires des autres modules pour plus d'exemples.
    8. Ajoutez APACHE_MODPATH_FINISH.
    • -
  • Créez le fichier +
  • Créez le fichier module/nouveau_module/Makefile.in. - Si la compilation de votre module ne nécessite pas d'instructions - particulières, ce fichier ne doit contenir que la ligne + Si la compilation de votre module ne nécessite pas d'instructions + particulières, ce fichier ne doit contenir que la ligne include $(top_srcdir)/build/special.mk.
    • -
  • Exécutez ./buildconf à la racine du répertoire.
    • +
  • Exécutez ./buildconf à la racine du répertoire.
    • -
  • Compilez le serveur après avoir exécuté la commande configure +
  • Compilez le serveur après avoir exécuté la commande configure avec l'option --enable-monexemple.
    • @@ -107,7 +107,7 @@
    Utilisation du module <code>mod_example_hooks</code> -

    Pour activer le module example_hooks, ajoutez à votre fichier +

    Pour activer le module example_hooks, ajoutez à votre fichier httpd.conf un bloc du style :

    <Location "/example-hooks-info"> @@ -117,7 +117,7 @@

    Vous pouvez aussi ajouter ce qui suit dans un fichier .htaccess, puis - accéder au fichier "test.example" à partir du répertoire + accéder au fichier "test.example" à partir du répertoire correspondant :

    @@ -125,28 +125,29 @@ -

    Après avoir rechargé la configuration ou redémarré votre serveur, - vous devriez pouvoir accéder à ce fichier et voir s'afficher ce qui - a été décrit plus haut.

    +

    Après avoir rechargé la configuration ou redémarré votre serveur, + vous devriez pouvoir accéder à ce fichier et voir s'afficher ce qui + a été décrit plus haut.

    Example -Directive de démonstration pour illustrer l'API des modules +Directive de démonstration pour illustrer l'API des modules Apache Example server config virtual hostdirectory .htaccess +Options

    La directive Example n'a pour fonction que - de définir un drapeau de démonstration que le gestionnaire de - contenu du module example_hooks va afficher. Elle ne possède aucun - argument. Si vous naviguez vers une URL à laquelle le gestionnaire + de définir un drapeau de démonstration que le gestionnaire de + contenu du module example_hooks va afficher. Elle ne possède aucun + argument. Si vous naviguez vers une URL à laquelle le gestionnaire de contenu example_hooks s'applique, vous verrez s'afficher les routines - du module, ainsi que l'ordre dans lequel elles ont été appelées pour - servir le document demandé. On peut observer l'effet de cette + du module, ainsi que l'ordre dans lequel elles ont été appelées pour + servir le document demandé. On peut observer l'effet de cette directive dans la phrase "Example directive declared here: YES/NO".

     diff --git a/docs/manual/mod/mod_logio.xml.fr b/docs/manual/mod/mod_logio.xml.fr index 1dfacd586ab..feb64a0c9b9 100644 --- a/docs/manual/mod/mod_logio.xml.fr +++ b/docs/manual/mod/mod_logio.xml.fr @@ -1,9 +1,8 @@ - + - + @@ -203,6 +203,7 @@ UndefMacro DirGroup virtual host directory +All

    La directive Macro permet de définir une macro @@ -236,6 +237,7 @@ UndefMacro DirGroup virtual host directory +All

    La directive Use permet d'utiliser une macro. @@ -271,6 +273,7 @@ Require ip 192.54.172.0/24 192.54.148.0/24 virtual host directory +All

    La directive UndefMacro annule la définition @@ -295,6 +298,7 @@ propos des arguments de Macro vides virtual host directory +All @@ -310,6 +314,7 @@ propos d'une imbrication de Macros non conforme virtual host directory +All diff --git a/docs/manual/mod/mod_remoteip.xml.fr b/docs/manual/mod/mod_remoteip.xml.fr index e132d288ddb..fa47dda279f 100644 --- a/docs/manual/mod/mod_remoteip.xml.fr +++ b/docs/manual/mod/mod_remoteip.xml.fr @@ -1,7 +1,7 @@ - + @@ -324,12 +324,7 @@ version 2.4.26 du serveur HTTP Apache présence de l'en-tête PROXY, mais aussi de permettre aux autres clients de se connecter sans ce dernier. Cette directive permet à l'administrateur du serveur d'autoriser cette possibilité à un hôte isolé ou à une gamme d'hôtes - au format CIDR. This is generally useful for monitoring and administrative - traffic to a virtual host direct to the server behind the upstream load - balancer.

    - + au format CIDR.

         diff --git a/docs/manual/sitemap.xml.fr b/docs/manual/sitemap.xml.fr index dd086e32951..20a0910cf73 100644 --- a/docs/manual/sitemap.xml.fr +++ b/docs/manual/sitemap.xml.fr @@ -1,7 +1,7 @@ - + @@ -220,6 +220,7 @@ threads dans la version 2.x Index des modules Index des directives Référence rapide des directives +Index de la classe Override pour .htaccess