| <?xml version="1.0"?> |
| <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd"> |
| <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?> |
| <!-- French translation : Lucien GENTIS --> |
| <!-- Reviewed by : Vincent Deffontaines --> |
| <!-- English Revision : 1673563 --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <modulesynopsis metafile="mod_authz_core.xml.meta"> |
| |
| <name>mod_authz_core</name> |
| <description>Autorisation basique</description> |
| <status>Base</status> |
| <sourcefile>mod_authz_core.c</sourcefile> |
| <identifier>authz_core_module</identifier> |
| <compatibility>Disponible depuis la version 2.3 |
| d'Apache HTTPD</compatibility> |
| |
| <summary> |
| <p>Ce module fournit des fonctionnalités d'autorisation basiques |
| permettant d'accorder ou refuser l'accès à certaines zones du site |
| web aux utilisateurs authentifiés. <module>mod_authz_core</module> |
| donne la possibilité d'enregistrer divers fournisseurs |
| d'autorisation. Il est en général utilisé avec un module fournisseur |
| d'authentification comme <module>mod_authn_file</module>, et un |
| module d'autorisation comme <module>mod_authz_user</module>. Il |
| permet aussi l'application d'une logique élaborée au déroulement du |
| processus d'autorisation.</p> |
| </summary> |
| |
| <section id="authzalias"><title>Création des alias du fournisseur |
| d'autorisation</title> |
| |
| <p>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 |
| directive <directive module="mod_authz_core">Require</directive> 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 plusieurs localisations. |
| </p> |
| |
| <section id="example"><title>Exemple</title> |
| <p>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 |
| serveurs ldap : |
| </p> |
| |
| <highlight language="config"> |
| <AuthzProviderAlias ldap-group ldap-group-alias1 cn=my-group,o=ctx> |
| AuthLDAPBindDN cn=youruser,o=ctx |
| AuthLDAPBindPassword yourpassword |
| AuthLDAPURL ldap://ldap.host/o=ctx |
| </AuthzProviderAlias> |
| |
| <AuthzProviderAlias ldap-group ldap-group-alias2 cn=my-other-group,o=dev> |
| AuthLDAPBindDN cn=yourotheruser,o=dev |
| AuthLDAPBindPassword yourotherpassword |
| AuthLDAPURL ldap://other.ldap.host/o=dev?cn |
| </AuthzProviderAlias> |
| |
| Alias "/secure" "/webpages/secure" |
| <Directory "/webpages/secure"> |
| Require all granted |
| |
| AuthBasicProvider file |
| |
| AuthType Basic |
| AuthName LDAP_Protected_Place |
| |
| #implied OR operation |
| Require ldap-group-alias1 |
| Require ldap-group-alias2 |
| </Directory> |
| </highlight> |
| </section> |
| |
| </section> |
| |
| <section id="logic"><title>Conteneurs d'autorisation</title> |
| |
| <p>Les directives de conteneur d'autorisation <directive |
| module="mod_authz_core" type="section">RequireAll</directive>, |
| <directive module="mod_authz_core" |
| type="section">RequireAny</directive> et <directive |
| module="mod_authz_core" type="section">RequireNone</directive> |
| peuvent être combinées entre elles et avec la directive <directive |
| module="mod_authz_core">Require</directive> pour confectionner une |
| logique d'autorisation complexe.</p> |
| |
| <p>L'exemple ci-dessous illustre la logique d'autorisation suivante. |
| Pour pouvoir accéder à la ressource, l'utilisateur doit être |
| l'utilisateur <code>superadmin</code>, ou appartenir aux deux |
| groupes LDAP <code>admins</code> et <code>Administrateurs</code> et |
| soit appartenir au groupe <code>ventes</code> ou avoir |
| <code>ventes</code> comme valeur de l'attribut LDAP |
| <code>dept</code>. De plus, pour pouvoir accéder à la ressource, |
| l'utilisateur ne doit appartenir ni au groupe <code>temps</code>, ni |
| au groupe LDAP <code>Employés temporaires</code>.</p> |
| |
| <highlight language="config"> |
| <Directory "/www/mydocs"> |
| <RequireAll> |
| <RequireAny> |
| Require user superadmin |
| <RequireAll> |
| Require group admins |
| Require ldap-group cn=Administrators,o=Airius |
| <RequireAny> |
| Require group sales |
| Require ldap-attribute dept="sales" |
| </RequireAny> |
| </RequireAll> |
| </RequireAny> |
| <RequireNone> |
| Require group temps |
| Require ldap-group cn=Temporary Employees,o=Airius |
| </RequireNone> |
| </RequireAll> |
| </Directory> |
| </highlight> |
| </section> |
| |
| <section id="requiredirectives"><title>Les directives Require</title> |
| |
| <p>Le module <module>mod_authz_core</module> met à disposition des |
| fournisseurs d'autorisation génériques utilisables avec la directive |
| <directive module="mod_authz_core">Require</directive>.</p> |
| |
| <section id="reqenv"><title>Require env</title> |
| |
| <p>Le fournisseur <code>env</code> permet de contrôler l'accès au |
| serveur en fonction de l'existence d'une <a |
| href="../env.html">variable d'environnement</a>. Lorsque <code>Require |
| env <var>env-variable</var></code> est spécifié, la requête se voit |
| autoriser l'accès si la variable d'environnement |
| <var>env-variable</var> 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 |
| par le module <module>mod_setenvif</module>. 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 |
| <code>User-Agent</code> (type de navigateur), <code>Referer</code>, |
| entre autres.</p> |
| |
| <highlight language="config"> |
| SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in |
| <Directory "/docroot"> |
| Require env let_me_in |
| </Directory> |
| </highlight> |
| |
| <p>Avec cet exemple, les navigateurs dont la chaîne user-agent |
| commence par <code>KnockKnock/2.0</code> se verront autoriser |
| l'accès, alors que tous les autres seront rejetés.</p> |
| |
| <p>Lorsque le serveur cherche un chemin via une <glossary |
| ref="subrequest">sous-requête</glossary> interne (par exemple la |
| recherche d'un <directive |
| module="mod_dir">DirectoryIndex</directive>), ou lorsqu'il génère un |
| listing du contenu d'un répertoire via le module |
| <module>mod_autoindex</module>, 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 <module>mod_setenvif</module> prend |
| part, les directives <directive |
| module="mod_setenvif">SetEnvIf</directive> ne sont pas évaluées |
| séparément dans la sous-requête.</p> |
| |
| </section> |
| |
| <section id="reqall"><title>Require all</title> |
| |
| <p>Le fournisseur <code>all</code> 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.</p> |
| |
| <highlight language="config"> |
| Require all granted |
| </highlight> |
| |
| <highlight language="config"> |
| Require all denied |
| </highlight> |
| |
| </section> |
| |
| <section id="reqmethod"><title>Require method</title> |
| |
| <p>Le fournisseur <code>method</code> 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 |
| <directive module="core">TraceEnable</directive>.</p> |
| |
| <p>Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et |
| OPTIONS sont autorisées :</p> |
| |
| <highlight language="config"> |
| Require method GET POST OPTIONS |
| </highlight> |
| |
| <p>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 :</p> |
| |
| <highlight language="config"> |
| <RequireAny> |
| Require method GET POST OPTIONS |
| Require valid-user |
| </RequireAny> |
| </highlight> |
| |
| </section> |
| <section id="reqexpr"><title>Require expr</title> |
| |
| <p>Le fournisseur <code>expr</code> permet d'accorder l'autorisation |
| d'accès de base en fonction d'expressions arbitraires.</p> |
| |
| <highlight language="config"> |
| Require expr "%{TIME_HOUR} -ge 9 && %{TIME_HOUR} -le 17" |
| </highlight> |
| |
| <highlight language="config"> |
| <RequireAll> |
| Require expr "!(%{QUERY_STRING} =~ /secret/)" |
| Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" |
| </RequireAll> |
| </highlight> |
| |
| <highlight language="config"> |
| Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" |
| </highlight> |
| |
| <p>La syntaxe de l'expression est décrite dans la documentation de <a |
| href="../expr.html">ap_expr</a>.</p> |
| |
| <p>Normalement, l'expression est évaluée avant l'authentification. |
| Cependant, si l'expression renvoie false et se réfère à la variable |
| <code>%{REMOTE_USER}</code>, le processus d'authentification sera |
| engagé et l'expression réévaluée.</p> |
| |
| </section> |
| |
| </section> |
| |
| <directivesynopsis> |
| <name>Require</name> |
| <description>Vérifie si un utilisateur authentifié a une |
| autorisation d'accès accordée par un fournisseur |
| d'autorisation.</description> |
| <syntax>Require [not] <var>nom-entité</var> [<var>nom-entité</var>] |
| ...</syntax> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>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. |
| <module>mod_authz_core</module> met à disposition les fournisseurs |
| d'autorisation génériques suivants :</p> |
| |
| <dl> |
| <dt><code>Require all granted</code></dt> |
| <dd>L'accès est autorisé sans restriction.</dd> |
| |
| <dt><code>Require all denied</code></dt> |
| <dd>L'accès est systématiquement refusé.</dd> |
| |
| <dt><code>Require env <var>env-var</var> [<var>env-var</var>] |
| ...</code></dt> |
| <dd>L'accès n'est autorisé que si l'une au moins des variables |
| d'environnement spécifiées est définie.</dd> |
| |
| <dt><code>Require method <var>http-method</var> [<var>http-method</var>] |
| ...</code></dt> |
| <dd>L'accès n'est autorisé que pour les méthodes HTTP spécifiées.</dd> |
| |
| <dt><code>Require expr <var>expression</var> </code></dt> |
| <dd>L'accès est autorisé si <var>expression</var> est évalué à |
| vrai.</dd> |
| </dl> |
| |
| <p>Voici quelques exemples de syntaxes autorisées par |
| <module>mod_authz_user</module>, <module>mod_authz_host</module> et |
| <module>mod_authz_groupfile</module> :</p> |
| |
| <dl> |
| <dt><code>Require user <var>identifiant utilisateur</var> |
| [<var>identifiant utilisateur</var>] |
| ...</code></dt> |
| <dd>Seuls les utilisateurs spécifiés auront accès à la |
| ressource.</dd> |
| |
| <dt><code>Require group <var>nom groupe</var> [<var>nom |
| groupe</var>] |
| ...</code></dt> |
| <dd>Seuls les utilisateurs appartenant aux groupes spécifiés |
| auront accès à la ressource.</dd> |
| |
| <dt><code>Require valid-user</code></dt> |
| <dd>Tous les utilisateurs valides auront accès à la |
| ressource.</dd> |
| |
| <dt><code>Require ip 10 172.20 192.168.2</code></dt> |
| <dd>Les clients dont les adresses IP font partie des tranches |
| spécifiées auront accès à la ressource.</dd> |
| </dl> |
| |
| <p>D'autres modules d'autorisation comme |
| <module>mod_authnz_ldap</module>, <module>mod_authz_dbm</module>, |
| <module>mod_authz_dbd</module>, |
| <module>mod_authz_owner</module> et <module>mod_ssl</module> |
| implémentent des options de la directive Require.</p> |
| |
| <p>Pour qu'une configuration d'authentification et d'autorisation |
| fonctionne correctement, la directive <directive>Require</directive> |
| doit être accompagnée dans la plupart des cas de directives <directive |
| module="mod_authn_core">AuthName</directive>, <directive |
| module="mod_authn_core">AuthType</directive> et <directive |
| module="mod_auth_basic">AuthBasicProvider</directive> ou <directive |
| module="mod_auth_digest">AuthDigestProvider</directive>, ainsi que |
| de directives telles que <directive |
| module="mod_authn_file">AuthUserFile</directive> et <directive |
| module="mod_authz_groupfile">AuthGroupFile</directive> (pour la |
| définition des utilisateurs et des groupes). Exemple :</p> |
| |
| <highlight language="config"> |
| AuthType Basic |
| AuthName "Restricted Resource" |
| AuthBasicProvider file |
| AuthUserFile "/web/users" |
| AuthGroupFile "/web/groups" |
| Require group admin |
| </highlight> |
| |
| <p>Les contrôles d'accès appliqués de cette manière sont effectifs |
| pour <strong>toutes</strong> les méthodes. <strong>C'est d'ailleurs |
| ce que l'on souhaite en général.</strong> 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 |
| <directive>Require</directive> dans une section <directive |
| module="core" type="section">Limit</directive>.</p> |
| |
| <p>Le résultat de la directive <directive>Require</directive> peut |
| être inversé en utilisant l'option <code>not</code>. Comme dans le |
| cas de l'autre directive d'autorisation inversée <directive |
| type="section">RequireNone</directive>, si la directive |
| <directive>Require</directive> est inversée, elle ne peut qu'échouer |
| ou produire un résultat neutre ; elle ne peut donc alors pas |
| autoriser une requête de manière indépendante.</p> |
| |
| <p>Dans l'exemple suivant, tous les utilisateurs appartenant aux |
| groupes <code>alpha</code> et <code>beta</code> ont l'autorisation |
| d'accès, à l'exception de ceux appartenant au groupe |
| <code>reject</code>.</p> |
| |
| <highlight language="config"> |
| <Directory "/www/docs"> |
| <RequireAll> |
| Require group alpha beta |
| Require not group reject |
| </RequireAll> |
| </Directory> |
| </highlight> |
| |
| <p>Lorsque plusieurs directives <directive>Require</directive> sont |
| placées dans une même <a href="../sections.html#merging">section de |
| configuration</a>, et ne se trouvent pas dans une autre directive |
| d'autorisation comme <directive module="mod_authz_core" |
| type="section">RequireAll</directive>, elles sont implicitement |
| contenues dans une directive <directive module="mod_authz_core" |
| type="section">RequireAny</directive>. Ainsi, la première directive |
| <directive>Require</directive> qui autorise l'accès à un utilisateur |
| autorise l'accès pour l'ensemble de la requête, et les directives |
| <directive>Require</directive> suivantes sont ignorées.</p> |
| |
| <note type="warning"><title>Avertissement à propos de la sécurité</title> |
| <p>Prettez une attention particulière aux directives d'autorisation |
| définies |
| au sein des sections <directive module="core">Location</directive> |
| qui se chevauchent avec des contenus servis depuis le système de |
| fichiers. Par défaut, les configurations définies dans ces <a |
| href="../sections.html#merging">sections</a> l'emportent sur les |
| configurations d'autorisations définies au sein des sections |
| <directive module="core">Directory</directive> et <directive |
| module="core">Files</directive> sections.</p> |
| <p>La directive <directive |
| module="mod_authz_core">AuthMerging</directive> permet de contrôler |
| la manière selon laquelle les configurations d'autorisations sont |
| fusionnées au sein des sections précitées.</p> |
| </note> |
| </usage> |
| |
| |
| <seealso><a href="../howto/access.html">Tutoriel du contrôle d'accès</a></seealso> |
| <seealso><a href="#logic">Conteneurs d'autorisation</a></seealso> |
| <seealso><module>mod_authn_core</module></seealso> |
| <seealso><module>mod_authz_host</module></seealso> |
| </directivesynopsis> |
| |
| <directivesynopsis type="section"> |
| <name>RequireAll</name> |
| <description>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 |
| positif.</description> |
| <syntax><RequireAll> ... </RequireAll></syntax> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>Les balises <directive type="section">RequireAll</directive> et |
| <code></RequireAll></code> 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 |
| <directive type="section">RequireAll</directive> retourne elle-même |
| un résultat positif.</p> |
| |
| <p>Si aucune des directives contenues dans la directive <directive |
| type="section">RequireAll</directive> n'échoue, et si au moins une |
| retourne un résultat positif, alors la directive <directive |
| type="section">RequireAll</directive> 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.</p> |
| </usage> |
| |
| <seealso><a href="#logic">Conteneurs d'autorisation</a></seealso> |
| <seealso><a href="../howto/auth.html">Authentification, autorisation et |
| contrôle d'accès</a></seealso> |
| |
| </directivesynopsis> |
| |
| <directivesynopsis type="section"> |
| <name>RequireAny</name> |
| <description>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.</description> |
| <syntax><RequireAny> ... </RequireAny></syntax> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>Les balises <directive type="section">RequireAny</directive> et |
| <code></RequireAny></code> permettent de regrouper des |
| directives d'autorisation dont au moins une doit retourner un |
| résultat positif pour que la directive <directive |
| type="section">RequireAny</directive> retourne elle-même un résultat |
| positif.</p> |
| |
| <p>Si une ou plusieurs directives contenues dans la directive |
| <directive type="section">RequireAny</directive> retournent un |
| résultat positif, alors la directive <directive |
| type="section">RequireAny</directive> 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.</p> |
| |
| <note>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 <directive |
| type="section">RequireAny</directive> (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). |
| C'est pourquoi il n'est pas permis d'utiliser les directives |
| d'autorisation inversées dans une directive <directive |
| type="section">RequireAny</directive>.</note> |
| </usage> |
| |
| <seealso><a href="#logic">Conteneurs d'autorisation</a></seealso> |
| <seealso><a href="../howto/auth.html">Authentification, autorisation et |
| contrôle d'accès</a></seealso> |
| |
| </directivesynopsis> |
| |
| <directivesynopsis type="section"> |
| <name>RequireNone</name> |
| <description>Regroupe des directives d'autorisation dont aucune ne doit |
| retourner un résultat positif pour que la directive globale n'échoue |
| pas.</description> |
| <syntax><RequireNone> ... </RequireNone></syntax> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>Les balises <directive type="section">RequireNone</directive> et |
| <code></RequireNone></code> permettent de regrouper des |
| directives d'autorisation dont aucune ne doit retourner un résultat |
| positif pour que la directive <directive |
| type="section">RequireNone</directive> n'échoue pas.</p> |
| |
| <p>Si une ou plusieurs directives contenues dans la directive |
| <directive type="section">RequireNone</directive> retournent un |
| résultat positif, la directive <directive |
| type="section">RequireNone</directive> échouera. Dans tous les |
| autres cas, cette dernière retournera un résultat neutre. Ainsi, |
| comme pour la directive d'autorisation inversée <code>Require |
| not</code>, elle ne peut jamais autoriser une requête de manière |
| indépendante 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.</p> |
| |
| <note>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 <directive |
| type="section">RequireNone</directive>. |
| C'est pourquoi il n'est pas permis d'utiliser les directives |
| d'autorisation inversées dans une directive <directive |
| type="section">RequireNone</directive>.</note> |
| </usage> |
| |
| <seealso><a href="#logic">Conteneurs d'autorisation</a></seealso> |
| <seealso><a href="../howto/auth.html">Authentification, autorisation et |
| contrôle d'accès</a></seealso> |
| |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthMerging</name> |
| <description>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.</description> |
| <syntax>AuthMerging Off | And | Or</syntax> |
| <default>AuthMerging Off</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <override>AuthConfig</override> |
| |
| <usage> |
| <p>Lorsque l'autorisation est activée, elle est normalement héritée |
| par chaque <a href="../sections.html#merging">section de |
| configuration</a> 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 |
| <code>AuthMerging Off</code>.</p> |
| |
| <p>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 |
| configuration se combinent entre elles. Dans ce cas, deux options |
| sont disponibles, <code>And</code> et <code>Or</code>.</p> |
| |
| <p>Lorsqu'une section de configuration contient <code>AuthMerging |
| And</code> ou <code>AuthMerging Or</code>, 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 |
| contient aussi une logique d'autorisation, comme si les deux |
| sections étaient concaténées respectivement dans une directive |
| <directive module="mod_authz_core" |
| type="section">RequireAll</directive> ou <directive |
| module="mod_authz_core" type="section">RequireAny</directive>.</p> |
| |
| <note>La définition de la directive |
| <directive>AuthMerging</directive> ne concerne que la section de |
| configuration dans laquelle elle apparaît. Dans l'exemple suivant, |
| seuls les utilisateurs appartenant au groupe <code>alpha</code> sont |
| autorisés à accéder à <code>/www/docs</code>. Les utilisateurs |
| appartenant au groupe <code>alpha</code> ou au groupe |
| <code>beta</code> sont autorisés à accéder à |
| <code>/www/docs/ab</code>. Cependant, la définition implicite à |
| <code>Off</code> de la directive <directive>AuthMerging</directive> |
| s'applique à la section de configuration <directive type="section" |
| module="core">Directory</directive> concernant le répertoire |
| <code>/www/docs/ab/gamma</code>, 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 <code>gamma</code> sont autorisés à accéder à |
| <code>/www/docs/ab/gamma</code>.</note> |
| |
| <highlight language="config"> |
| <Directory "/www/docs"> |
| AuthType Basic |
| AuthName Documents |
| AuthBasicProvider file |
| AuthUserFile "/usr/local/apache/passwd/passwords" |
| Require group alpha |
| </Directory> |
| |
| <Directory "/www/docs/ab"> |
| AuthMerging Or |
| Require group beta |
| </Directory> |
| |
| <Directory "/www/docs/ab/gamma"> |
| Require group gamma |
| </Directory> |
| </highlight> |
| </usage> |
| |
| </directivesynopsis> |
| |
| <directivesynopsis type="section"> |
| <name>AuthzProviderAlias</name> |
| <description>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é</description> |
| <syntax><AuthzProviderAlias <var>fournisseur-de-base Alias |
| Paramètres-Require</var>> |
| ... </AuthzProviderAlias> |
| </syntax> |
| <contextlist><context>server config</context> |
| </contextlist> |
| |
| <usage> |
| <p>Les balises <directive |
| type="section">AuthzProviderAlias</directive> et |
| <code></AuthzProviderAlias></code> permettent de regrouper des |
| directives d'autorisation auxquelles on pourra faire référence à |
| l'aide de l'alias spécifié dans une directive <directive |
| module="mod_authz_core">Require</directive>.</p> |
| |
| </usage> |
| </directivesynopsis> |
| |
| <directivesynopsis> |
| <name>AuthzSendForbiddenOnFailure</name> |
| <description>Envoie '403 FORBIDDEN' au lieu de '401 UNAUTHORIZED' si |
| l'authentification réussit et si l'autorisation a été refusée. |
| </description> |
| <syntax>AuthzSendForbiddenOnFailure On|Off</syntax> |
| <default>AuthzSendForbiddenOnFailure Off</default> |
| <contextlist><context>directory</context><context>.htaccess</context> |
| </contextlist> |
| <compatibility>Disponible depuis la version 2.3.11 d'Apache HTTPD</compatibility> |
| |
| <usage> |
| <p>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 |
| <directive>AuthzSendForbiddenOnFailure</directive> permet de changer |
| le code de réponse en '403 FORBIDDEN'.</p> |
| |
| <note type="warning"><title>Avertissement de sécurité</title> |
| <p>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.</p> |
| </note> |
| </usage> |
| </directivesynopsis> |
| |
| </modulesynopsis> |
