apache/docs/manual/mod/mod_authz_core.xml.fr

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
<!-- English Revision:1888002 -->
<!-- French translation : Lucien GENTIS -->
<!-- Reviewed by : Vincent Deffontaines -->

<!--
 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>Socle d'autorisation</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 un socle de fonctionnalités d'autorisation
    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="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 construire 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>, soit 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">
&lt;Directory "/www/mydocs"&gt;
    &lt;RequireAll&gt;
        &lt;RequireAny&gt;
            Require user superadmin
            &lt;RequireAll&gt;
            Require group admins
            Require ldap-group "cn=Administrateurs,o=Airius"
                &lt;RequireAny&gt;
                Require group ventes
                Require ldap-attribute dept="ventes"
                &lt;/RequireAny&gt;
            &lt;/RequireAll&gt;
        &lt;/RequireAny&gt;
        &lt;RequireNone&gt;
            Require group temps
            Require ldap-group "cn=Employés temporaires,o=Airius"
        &lt;/RequireNone&gt;
    &lt;/RequireAll&gt;
&lt;/Directory&gt;
    </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
&lt;Directory "/docroot"&gt;
    Require env let_me_in
&lt;/Directory&gt;
    </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">
&lt;RequireAny&gt;
    &nbsp;Require method GET POST OPTIONS
    &nbsp;Require valid-user
&lt;/RequireAny&gt;
    </highlight>

  </section>
  <section id="reqexpr"><title>Require expr</title>

  <p>Le fournisseur <code>expr</code> permet d'accorder l'autorisation
  d'accès en fonction d'expressions arbitraires.</p>

    <highlight language="config">
         Require expr "%{TIME_HOUR} -ge 9 &amp;&amp; %{TIME_HOUR} -le 17"
    </highlight>

    <highlight language="config">
&lt;RequireAll&gt;
    Require expr "!(%{QUERY_STRING} =~ /secret/)"
    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
&lt;/RequireAll&gt;
    </highlight>

    <highlight language="config">
        Require expr "!(%{QUERY_STRING} =~ /secret/) &amp;&amp; %{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>. Avant la version 2.4.16, les doubles-quotes
    étaient prohibées.</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>

<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 diverses 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">
&lt;AuthzProviderAlias ldap-group ldap-group-alias1 "cn=my-group,o=ctx"&gt;
    AuthLDAPBindDN "cn=youruser,o=ctx"
    AuthLDAPBindPassword yourpassword
    AuthLDAPUrl "ldap://ldap.host/o=ctx"
&lt;/AuthzProviderAlias&gt;

&lt;AuthzProviderAlias ldap-group ldap-group-alias2 "cn=my-other-group,o=dev"&gt;
    AuthLDAPBindDN "cn=yourotheruser,o=dev"
    AuthLDAPBindPassword yourotherpassword
    AuthLDAPUrl "ldap://other.ldap.host/o=dev?cn"
&lt;/AuthzProviderAlias&gt;

Alias "/secure" "/webpages/secure"
&lt;Directory "/webpages/secure"&gt;
    Require all granted

    AuthBasicProvider file

    AuthType Basic
    AuthName LDAP_Protected_Place

    #Opération logique implicite : OU inclusif
    Require ldap-group-alias1
    Require ldap-group-alias2
&lt;/Directory&gt;
        </highlight>
    </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>

      <dt><code>Require forward-dns dynamic.example.org</code></dt>
      <dd>Un client dont l'adresse IP est résolue à partir du nom
      dynamic.example.org aura l'autorisation d'accès.
      </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
    en soi autoriser une requête.</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">
&lt;Directory "/www/docs"&gt;
    &lt;RequireAll&gt;
        Require group alpha beta
        Require not group reject
    &lt;/RequireAll&gt;
&lt;/Directory&gt;
    </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>&lt;RequireAll&gt; ... &lt;/RequireAll&gt;</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>

<usage>
    <p>Les balises <directive type="section">RequireAll</directive> et
    <code>&lt;/RequireAll&gt;</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>&lt;RequireAny&gt; ... &lt;/RequireAny&gt;</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>

<usage>
    <p>Les balises <directive type="section">RequireAny</directive> et
    <code>&lt;/RequireAny&gt;</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>&lt;RequireNone&gt; ... &lt;/RequireNone&gt;</syntax>
<contextlist><context>directory</context><context>.htaccess</context>
</contextlist>
<override>AuthConfig</override>

<usage>
    <p>Les balises <directive type="section">RequireNone</directive> et
    <code>&lt;/RequireNone&gt;</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 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.</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">
&lt;Directory "/www/docs"&gt;
    AuthType Basic
    AuthName Documents
    AuthBasicProvider file
    AuthUserFile "/usr/local/apache/passwd/passwords"
    Require group alpha
&lt;/Directory&gt;

&lt;Directory "/www/docs/ab"&gt;
    AuthMerging Or
    Require group beta
&lt;/Directory&gt;

&lt;Directory "/www/docs/ab/gamma"&gt;
    Require group gamma
&lt;/Directory&gt;
    </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>&lt;AuthzProviderAlias <var>baseProvider Alias Require-Parameters</var>&gt;
... &lt;/AuthzProviderAlias&gt;
</syntax>
<contextlist><context>server config</context>
</contextlist>

<usage>
    <p>Les balises <directive
    type="section">AuthzProviderAlias</directive> et
    <code>&lt;/AuthzProviderAlias&gt;</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>

    <p>Si <var>Require-Parameters</var> comporte plusieurs paramètres, la liste
    de ces derniers doit être entourée de guillemets. Dans le cas contraire,
    seul le premier paramètre de la liste sera pris en compte.</p>
    
    <highlight language="config">
# Dans cet exemple, pour que les deux adresses IP soient prises en compte, elles
# DOIVENT être entourées de guillemets
&lt;AuthzProviderAlias ip reject-ips "XXX.XXX.XXX.XXX YYY.YYY.YYY.YYY"&gt;
&lt;/AuthzProviderAlias&gt;

&lt;Directory "/path/to/dir"&gt;
    &lt;RequireAll&gt;
        Require not reject-ips
        Require all granted
    &lt;/RequireAll&gt;
&lt;/Directory&gt;
    </highlight>

</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>
<override>AuthConfig</override>
<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>