granicus.if.org Git - apache/blob - docs/manual/mod/mod_authz_core.xml.fr

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
   3 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
   4 <!-- English Revision: 1793934 -->
   5 <!-- French translation : Lucien GENTIS -->
   6 <!-- Reviewed by : Vincent Deffontaines -->
   7
   8 <!--
   9  Licensed to the Apache Software Foundation (ASF) under one or more
  10  contributor license agreements.  See the NOTICE file distributed with
  11  this work for additional information regarding copyright ownership.
  12  The ASF licenses this file to You under the Apache License, Version 2.0
  13  (the "License"); you may not use this file except in compliance with
  14  the License.  You may obtain a copy of the License at
  15
  16      http://www.apache.org/licenses/LICENSE-2.0
  17
  18  Unless required by applicable law or agreed to in writing, software
  19  distributed under the License is distributed on an "AS IS" BASIS,
  20  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  21  See the License for the specific language governing permissions and
  22  limitations under the License.
  23 -->
  24
  25 <modulesynopsis metafile="mod_authz_core.xml.meta">
  26
  27 <name>mod_authz_core</name>
  28 <description>Socle d'autorisation</description>
  29 <status>Base</status>
  30 <sourcefile>mod_authz_core.c</sourcefile>
  31 <identifier>authz_core_module</identifier>
  32 <compatibility>Disponible depuis la version 2.3
  33 d'Apache HTTPD</compatibility>
  34
  35 <summary>
  36     <p>Ce module fournit un socle de fonctionnalités d'autorisation
  37     permettant d'accorder ou refuser l'accès à certaines zones du site
  38     web aux utilisateurs authentifiés. <module>mod_authz_core</module>
  39     donne la possibilité d'enregistrer divers fournisseurs
  40     d'autorisation. Il est en général utilisé avec un module fournisseur
  41     d'authentification comme <module>mod_authn_file</module>, et un
  42     module d'autorisation comme <module>mod_authz_user</module>. Il
  43     permet aussi l'application d'une logique élaborée au déroulement du
  44     processus d'autorisation.</p>
  45 </summary>
  46
  47 <section id="logic"><title>Conteneurs d'autorisation</title>
  48
  49     <p>Les directives de conteneur d'autorisation <directive
  50     module="mod_authz_core" type="section">RequireAll</directive>,
  51     <directive module="mod_authz_core"
  52     type="section">RequireAny</directive> et <directive
  53     module="mod_authz_core" type="section">RequireNone</directive>
  54     peuvent être combinées entre elles et avec la directive <directive
  55     module="mod_authz_core">Require</directive> pour construire une
  56     logique d'autorisation complexe.</p>
  57
  58     <p>L'exemple ci-dessous illustre la logique d'autorisation suivante.
  59     Pour pouvoir accéder à la ressource, l'utilisateur doit être
  60     l'utilisateur <code>superadmin</code>, ou appartenir aux deux
  61     groupes LDAP <code>admins</code> et <code>Administrateurs</code> et
  62     soit appartenir au groupe <code>ventes</code>, soit avoir
  63     <code>ventes</code> comme valeur de l'attribut LDAP
  64     <code>dept</code>. De plus, pour pouvoir accéder à la ressource,
  65     l'utilisateur ne doit appartenir ni au groupe <code>temps</code>, ni
  66     au groupe LDAP <code>Employés temporaires</code>.</p>
  67
  68     <highlight language="config">
  69 &lt;Directory "/www/mydocs"&gt;
  70     &lt;RequireAll&gt;
  71         &lt;RequireAny&gt;
  72             Require user superadmin
  73             &lt;RequireAll&gt;
  74             Require group admins
  75             Require ldap-group "cn=Administrateurs,o=Airius"
  76                 &lt;RequireAny&gt;
  77                 Require group ventes
  78                 Require ldap-attribute dept="ventes"
  79                 &lt;/RequireAny&gt;
  80             &lt;/RequireAll&gt;
  81         &lt;/RequireAny&gt;
  82         &lt;RequireNone&gt;
  83             Require group temps
  84             Require ldap-group "cn=Employés temporaires,o=Airius"
  85         &lt;/RequireNone&gt;
  86     &lt;/RequireAll&gt;
  87 &lt;/Directory&gt;
  88     </highlight>
  89 </section>
  90
  91 <section id="requiredirectives"><title>Les directives Require</title>
  92
  93   <p>Le module <module>mod_authz_core</module> met à disposition des
  94   fournisseurs d'autorisation génériques utilisables avec la directive
  95   <directive module="mod_authz_core">Require</directive>.</p>
  96
  97   <section id="reqenv"><title>Require env</title>
  98
  99     <p>Le fournisseur <code>env</code> permet de contrôler l'accès au
 100     serveur en fonction de l'existence d'une <a
 101     href="../env.html">variable d'environnement</a>. Lorsque <code>Require
 102     env <var>env-variable</var></code> est spécifié, la requête se voit
 103     autoriser l'accès si la variable d'environnement
 104     <var>env-variable</var> existe. Le serveur permet de définir
 105     facilement des variables d'environnement en fonction des
 106     caractéristiques de la requête du client via les directives fournies
 107     par le module <module>mod_setenvif</module>. Cette directive Require
 108     env permet donc de contrôler l'accès en fonction des
 109     valeurs des en-têtes de la requête HTTP tels que
 110     <code>User-Agent</code> (type de navigateur), <code>Referer</code>,
 111     entre autres.</p>
 112
 113     <highlight language="config">
 114 SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in
 115 &lt;Directory "/docroot"&gt;
 116     Require env let_me_in
 117 &lt;/Directory&gt;
 118     </highlight>
 119
 120     <p>Avec cet exemple, les navigateurs dont la chaîne user-agent
 121     commence par <code>KnockKnock/2.0</code> se verront autoriser
 122     l'accès, alors que tous les autres seront rejetés.</p>
 123
 124     <p>Lorsque le serveur cherche un chemin via une <glossary
 125    ref="subrequest">sous-requête</glossary> interne (par exemple la
 126    recherche d'un <directive
 127    module="mod_dir">DirectoryIndex</directive>), ou lorsqu'il génère un
 128    listing du contenu d'un répertoire via le module
 129    <module>mod_autoindex</module>, la sous-requête n'hérite pas des
 130    variables d'environnement spécifiques à la requête. En outre, à cause
 131    des phases de l'API auxquelles <module>mod_setenvif</module> prend
 132    part, les directives <directive
 133    module="mod_setenvif">SetEnvIf</directive> ne sont pas évaluées
 134    séparément dans la sous-requête.</p>
 135
 136   </section>
 137
 138   <section id="reqall"><title>Require all</title>
 139
 140     <p>Le fournisseur <code>all</code> reproduit la fonctionnalité
 141     précédemment fournie par les directives 'Allow from all' et 'Deny
 142     from all'. Il accepte un argument dont les deux valeurs possibles
 143     sont : 'granted' ou 'denied'. Les exemples suivants autorisent ou
 144     interdisent l'accès à toutes les requêtes.</p>
 145
 146     <highlight language="config">
 147     Require all granted
 148     </highlight>
 149
 150     <highlight language="config">
 151     Require all denied
 152     </highlight>
 153
 154   </section>
 155
 156   <section id="reqmethod"><title>Require method</title>
 157
 158     <p>Le fournisseur <code>method</code> permet d'utiliser la méthode
 159     HTTP dans le processus d'autorisation. Les méthodes GET et HEAD sont
 160     ici considérées comme équivalentes. La méthode TRACE n'est pas
 161     supportée par ce fournisseur ; utilisez à la place la directive
 162     <directive module="core">TraceEnable</directive>.</p>
 163
 164     <p>Dans l'exemple suivant, seules les méthodes GET, HEAD, POST, et
 165     OPTIONS sont autorisées :</p>
 166
 167     <highlight language="config">
 168         Require method GET POST OPTIONS
 169     </highlight>
 170
 171     <p>Dans l'exemple suivant, les méthodes GET, HEAD, POST, et OPTIONS
 172     sont autorisées sans authentification, alors que toutes les autres
 173     méthodes nécessitent un utilisateur valide :</p>
 174
 175     <highlight language="config">
 176 &lt;RequireAny&gt;
 177     &nbsp;Require method GET POST OPTIONS
 178     &nbsp;Require valid-user
 179 &lt;/RequireAny&gt;
 180     </highlight>
 181
 182   </section>
 183   <section id="reqexpr"><title>Require expr</title>
 184
 185   <p>Le fournisseur <code>expr</code> permet d'accorder l'autorisation
 186   d'accès en fonction d'expressions arbitraires.</p>
 187
 188     <highlight language="config">
 189          Require expr %{TIME_HOUR} -ge 9 &amp;&amp; %{TIME_HOUR} -le 17
 190     </highlight>
 191
 192     <highlight language="config">
 193 &lt;RequireAll&gt;
 194     Require expr "!(%{QUERY_STRING} =~ /secret/)"
 195     Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
 196 &lt;/RequireAll&gt;
 197     </highlight>
 198
 199     <highlight language="config">
 200         Require expr "!(%{QUERY_STRING} =~ /secret/) &amp;&amp; %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
 201     </highlight>
 202
 203     <p>La syntaxe de l'expression est décrite dans la documentation de <a
 204     href="../expr.html">ap_expr</a>.</p>
 205
 206     <p>Normalement, l'expression est évaluée avant l'authentification.
 207     Cependant, si l'expression renvoie false et se réfère à la variable
 208     <code>%{REMOTE_USER}</code>, le processus d'authentification sera
 209     engagé et l'expression réévaluée.</p>
 210
 211   </section>
 212
 213 </section>
 214
 215 <section id="authzalias"><title>Création des alias du fournisseur
 216 d'autorisation</title>
 217
 218     <p>Il est possible de créer des fournisseurs d'autorisation étendus
 219     dans le fichier de configuration et de leur assigner un nom d'alias.
 220     On peut ensuite utiliser ces fournisseurs aliasés dans une
 221     directive <directive module="mod_authz_core">Require</directive> de
 222     la même manière qu'on le ferait pour des fournisseurs d'autorisation
 223     de base. En plus de la possibilité de créer et d'aliaser un
 224     fournisseur étendu, le même fournisseur d'autorisation étendu peut
 225     être référencé par diverses localisations.
 226     </p>
 227
 228     <section id="example"><title>Exemple</title>
 229         <p>Dans l'exemple suivant, on crée deux alias de fournisseur
 230         d'autorisation ldap différents basés sur le fournisseur
 231         d'autorisation ldap-group. Il est ainsi possible pour un seul
 232         répertoire de vérifier l'appartenance à un groupe dans plusieurs
 233         serveurs ldap :
 234         </p>
 235
 236         <highlight language="config">
 237 &lt;AuthzProviderAlias ldap-group ldap-group-alias1 "cn=my-group,o=ctx"&gt;
 238     AuthLDAPBindDN "cn=youruser,o=ctx"
 239     AuthLDAPBindPassword yourpassword
 240     AuthLDAPURL "ldap://ldap.host/o=ctx"
 241 &lt;/AuthzProviderAlias&gt;
 242
 243 &lt;AuthzProviderAlias ldap-group ldap-group-alias2 "cn=my-other-group,o=dev"&gt;
 244     AuthLDAPBindDN "cn=yourotheruser,o=dev"
 245     AuthLDAPBindPassword yourotherpassword
 246     AuthLDAPURL "ldap://other.ldap.host/o=dev?cn"
 247 &lt;/AuthzProviderAlias&gt;
 248
 249 Alias "/secure" "/webpages/secure"
 250 &lt;Directory "/webpages/secure"&gt;
 251     Require all granted
 252
 253     AuthBasicProvider file
 254
 255     AuthType Basic
 256     AuthName LDAP_Protected_Place
 257
 258     #Opération logique implicite : OU inclusif
 259     Require ldap-group-alias1
 260     Require ldap-group-alias2
 261 &lt;/Directory&gt;
 262         </highlight>
 263     </section>
 264
 265 </section>
 266
 267
 268 <directivesynopsis>
 269 <name>Require</name>
 270 <description>Vérifie si un utilisateur authentifié a une
 271 autorisation d'accès accordée par un fournisseur
 272 d'autorisation.</description>
 273 <syntax>Require [not] <var>nom-entité</var> [<var>nom-entité</var>]
 274 ...</syntax>
 275 <contextlist><context>directory</context><context>.htaccess</context>
 276 </contextlist>
 277 <override>AuthConfig</override>
 278
 279 <usage>
 280     <p>Cette directive permet de vérifier si un utilisateur authentifié
 281     a l'autorisation d'accès accordée pour un certain fournisseur
 282     d'autorisation et en tenant compte de certaines restrictions.
 283     <module>mod_authz_core</module> met à disposition les fournisseurs
 284     d'autorisation génériques suivants :</p>
 285
 286     <dl>
 287       <dt><code>Require all granted</code></dt>
 288       <dd>L'accès est autorisé sans restriction.</dd>
 289
 290       <dt><code>Require all denied</code></dt>
 291       <dd>L'accès est systématiquement refusé.</dd>
 292
 293       <dt><code>Require env <var>env-var</var> [<var>env-var</var>]
 294       ...</code></dt>
 295       <dd>L'accès n'est autorisé que si l'une au moins des variables
 296       d'environnement spécifiées est définie.</dd>
 297
 298       <dt><code>Require method <var>http-method</var> [<var>http-method</var>]
 299       ...</code></dt>
 300       <dd>L'accès n'est autorisé que pour les méthodes HTTP spécifiées.</dd>
 301
 302       <dt><code>Require expr <var>expression</var> </code></dt>
 303       <dd>L'accès est autorisé si <var>expression</var> est évalué à
 304       vrai.</dd>
 305     </dl>
 306
 307     <p>Voici quelques exemples de syntaxes autorisées par
 308     <module>mod_authz_user</module>, <module>mod_authz_host</module> et
 309     <module>mod_authz_groupfile</module> :</p>
 310
 311     <dl>
 312       <dt><code>Require user <var>identifiant utilisateur</var>
 313       [<var>identifiant utilisateur</var>]
 314       ...</code></dt>
 315       <dd>Seuls les utilisateurs spécifiés auront accès à la
 316       ressource.</dd>
 317
 318       <dt><code>Require group <var>nom groupe</var> [<var>nom
 319       groupe</var>]
 320       ...</code></dt>
 321       <dd>Seuls les utilisateurs appartenant aux groupes spécifiés
 322       auront accès à la ressource.</dd>
 323
 324       <dt><code>Require valid-user</code></dt>
 325       <dd>Tous les utilisateurs valides auront accès à la
 326       ressource.</dd>
 327
 328       <dt><code>Require ip 10 172.20 192.168.2</code></dt>
 329       <dd>Les clients dont les adresses IP font partie des tranches
 330       spécifiées auront accès à la ressource.</dd>
 331     </dl>
 332
 333     <p>D'autres modules d'autorisation comme
 334     <module>mod_authnz_ldap</module>, <module>mod_authz_dbm</module>,
 335     <module>mod_authz_dbd</module>,
 336     <module>mod_authz_owner</module> et <module>mod_ssl</module>
 337     implémentent des options de la directive Require.</p>
 338
 339     <p>Pour qu'une configuration d'authentification et d'autorisation
 340     fonctionne correctement, la directive <directive>Require</directive>
 341     doit être accompagnée dans la plupart des cas de directives <directive
 342     module="mod_authn_core">AuthName</directive>, <directive
 343     module="mod_authn_core">AuthType</directive> et <directive
 344     module="mod_auth_basic">AuthBasicProvider</directive> ou <directive
 345     module="mod_auth_digest">AuthDigestProvider</directive>, ainsi que
 346     de directives telles que <directive
 347     module="mod_authn_file">AuthUserFile</directive> et <directive
 348     module="mod_authz_groupfile">AuthGroupFile</directive> (pour la
 349     définition des utilisateurs et des groupes). Exemple :</p>
 350
 351     <highlight language="config">
 352 AuthType Basic
 353 AuthName "Restricted Resource"
 354 AuthBasicProvider file
 355 AuthUserFile "/web/users"
 356 AuthGroupFile "/web/groups"
 357 Require group admin
 358     </highlight>
 359
 360     <p>Les contrôles d'accès appliqués de cette manière sont effectifs
 361     pour <strong>toutes</strong> les méthodes. <strong>C'est d'ailleurs
 362     ce que l'on souhaite en général.</strong> Si vous voulez n'appliquer
 363     les contrôles d'accès qu'à certaines méthodes, tout en laissant les
 364     autres méthodes sans protection, placez la directive
 365     <directive>Require</directive> dans une section <directive
 366     module="core" type="section">Limit</directive>.</p>
 367
 368     <p>Le résultat de la directive <directive>Require</directive> peut
 369     être inversé en utilisant l'option <code>not</code>. Comme dans le
 370     cas de l'autre directive d'autorisation inversée <directive
 371     type="section">RequireNone</directive>, si la directive
 372     <directive>Require</directive> est inversée, elle ne peut qu'échouer
 373     ou produire un résultat neutre ; elle ne peut donc alors pas
 374     en soi autoriser une requête.</p>
 375
 376     <p>Dans l'exemple suivant, tous les utilisateurs appartenant aux
 377     groupes <code>alpha</code> et <code>beta</code> ont l'autorisation
 378     d'accès, à l'exception de ceux appartenant au groupe
 379     <code>reject</code>.</p>
 380
 381     <highlight language="config">
 382 &lt;Directory "/www/docs"&gt;
 383     &lt;RequireAll&gt;
 384         Require group alpha beta
 385         Require not group reject
 386     &lt;/RequireAll&gt;
 387 &lt;/Directory&gt;
 388     </highlight>
 389
 390     <p>Lorsque plusieurs directives <directive>Require</directive> sont
 391     placées dans une même <a href="../sections.html#merging">section de
 392     configuration</a>, et ne se trouvent pas dans une autre directive
 393     d'autorisation comme <directive module="mod_authz_core"
 394     type="section">RequireAll</directive>, elles sont implicitement
 395     contenues dans une directive <directive module="mod_authz_core"
 396     type="section">RequireAny</directive>. Ainsi, la première directive
 397     <directive>Require</directive> qui autorise l'accès à un utilisateur
 398     autorise l'accès pour l'ensemble de la requête, et les directives
 399     <directive>Require</directive> suivantes sont ignorées.</p>
 400
 401     <note type="warning"><title>Avertissement à propos de la sécurité</title>
 402     <p>Prettez une attention particulière aux directives d'autorisation
 403     définies
 404     au sein des sections <directive module="core">Location</directive>
 405     qui se chevauchent avec des contenus servis depuis le système de
 406     fichiers. Par défaut, les configurations définies dans ces <a
 407     href="../sections.html#merging">sections</a> l'emportent sur les
 408     configurations d'autorisations définies au sein des sections
 409     <directive module="core">Directory</directive> et <directive
 410     module="core">Files</directive> sections.</p>
 411     <p>La directive <directive
 412     module="mod_authz_core">AuthMerging</directive> permet de contrôler
 413     la manière selon laquelle les configurations d'autorisations sont
 414     fusionnées au sein des sections précitées.</p>
 415     </note>
 416 </usage>
 417
 418
 419 <seealso><a href="../howto/access.html">Tutoriel du contrôle d'accès</a></seealso>
 420 <seealso><a href="#logic">Conteneurs d'autorisation</a></seealso>
 421 <seealso><module>mod_authn_core</module></seealso>
 422 <seealso><module>mod_authz_host</module></seealso>
 423 </directivesynopsis>
 424
 425 <directivesynopsis type="section">
 426 <name>RequireAll</name>
 427 <description>Regroupe plusieurs directives d'autorisation dont aucune ne
 428 doit échouer et dont au moins une doit retourner un résultat positif
 429 pour que la directive globale retourne elle-même un résultat
 430 positif.</description>
 431 <syntax>&lt;RequireAll&gt; ... &lt;/RequireAll&gt;</syntax>
 432 <contextlist><context>directory</context><context>.htaccess</context>
 433 </contextlist>
 434 <override>AuthConfig</override>
 435
 436 <usage>
 437     <p>Les balises <directive type="section">RequireAll</directive> et
 438     <code>&lt;/RequireAll&gt;</code> permettent de regrouper des
 439     directives d'autorisation dont aucune ne doit échouer, et dont au
 440     moins une doit retourner un résultat positif pour que la directive
 441     <directive type="section">RequireAll</directive> retourne elle-même
 442     un résultat positif.</p>
 443
 444     <p>Si aucune des directives contenues dans la directive <directive
 445     type="section">RequireAll</directive> n'échoue, et si au moins une
 446     retourne un résultat positif, alors la directive <directive
 447     type="section">RequireAll</directive> retourne elle-même un résultat
 448     positif. Si aucune ne retourne un résultat positif, et si aucune
 449     n'échoue, la directive globale retourne un résultat neutre. Dans
 450     tous les autres cas, elle échoue.</p>
 451 </usage>
 452
 453 <seealso><a href="#logic">Conteneurs d'autorisation</a></seealso>
 454 <seealso><a href="../howto/auth.html">Authentification, autorisation et
 455 contrôle d'accès</a></seealso>
 456
 457 </directivesynopsis>
 458
 459 <directivesynopsis type="section">
 460 <name>RequireAny</name>
 461 <description>Regroupe des directives d'autorisation dont au moins une
 462 doit retourner un résultat positif pour que la directive globale
 463 retourne elle-même un résultat positif.</description>
 464 <syntax>&lt;RequireAny&gt; ... &lt;/RequireAny&gt;</syntax>
 465 <contextlist><context>directory</context><context>.htaccess</context>
 466 </contextlist>
 467 <override>AuthConfig</override>
 468
 469 <usage>
 470     <p>Les balises <directive type="section">RequireAny</directive> et
 471     <code>&lt;/RequireAny&gt;</code> permettent de regrouper des
 472     directives d'autorisation dont au moins une doit retourner un
 473     résultat positif pour que la directive <directive
 474     type="section">RequireAny</directive> retourne elle-même un résultat
 475     positif.</p>
 476
 477     <p>Si une ou plusieurs directives contenues dans la directive
 478     <directive type="section">RequireAny</directive> retournent un
 479     résultat positif, alors la directive <directive
 480     type="section">RequireAny</directive> retourne elle-même un résultat
 481     positif. Si aucune ne retourne un résultat positif et aucune
 482     n'échoue, la directive globale retourne un résultat neutre. Dans
 483     tous les autres cas, elle échoue.</p>
 484
 485     <note>Comme les directives d'autorisation inversées sont incapables
 486     de retourner un résultat positif, elles ne peuvent pas impacter de
 487     manière significative le résultat d'une directive <directive
 488     type="section">RequireAny</directive> (elles pourraient tout au plus
 489     faire échouer la directive dans le cas où elles échoueraient
 490     elles-mêmes, et où
 491     toutes les autres directives retourneraient un résultat neutre).
 492     C'est pourquoi il n'est pas permis d'utiliser les directives
 493     d'autorisation inversées dans une directive <directive
 494     type="section">RequireAny</directive>.</note>
 495 </usage>
 496
 497 <seealso><a href="#logic">Conteneurs d'autorisation</a></seealso>
 498 <seealso><a href="../howto/auth.html">Authentification, autorisation et
 499 contrôle d'accès</a></seealso>
 500
 501 </directivesynopsis>
 502
 503 <directivesynopsis type="section">
 504 <name>RequireNone</name>
 505 <description>Regroupe des directives d'autorisation dont aucune ne doit
 506 retourner un résultat positif pour que la directive globale n'échoue
 507 pas.</description>
 508 <syntax>&lt;RequireNone&gt; ... &lt;/RequireNone&gt;</syntax>
 509 <contextlist><context>directory</context><context>.htaccess</context>
 510 </contextlist>
 511 <override>AuthConfig</override>
 512
 513 <usage>
 514     <p>Les balises <directive type="section">RequireNone</directive> et
 515     <code>&lt;/RequireNone&gt;</code> permettent de regrouper des
 516     directives d'autorisation dont aucune ne doit retourner un résultat
 517     positif pour que la directive <directive
 518     type="section">RequireNone</directive> n'échoue pas.</p>
 519
 520     <p>Si une ou plusieurs directives contenues dans la directive
 521     <directive type="section">RequireNone</directive> retournent un
 522     résultat positif, la directive <directive
 523     type="section">RequireNone</directive> échouera. Dans tous les
 524     autres cas, cette dernière retournera un résultat neutre. Ainsi,
 525     comme pour la directive d'autorisation inversée <code>Require
 526     not</code>, elle ne peut jamais en soi autoriser une requête
 527     car elle ne pourra jamais retourner un résultat
 528     positif. Par contre, on peut l'utiliser pour restreindre l'ensemble
 529     des utilisateurs autorisés à accéder à une ressource.</p>
 530
 531     <note>Comme les directives d'autorisation inversées sont incapables
 532     de retourner un résultat positif, elles ne peuvent pas impacter de
 533     manière significative le résultat d'une directive <directive
 534     type="section">RequireNone</directive>.
 535     C'est pourquoi il n'est pas permis d'utiliser les directives
 536     d'autorisation inversées dans une directive <directive
 537     type="section">RequireNone</directive>.</note>
 538 </usage>
 539
 540 <seealso><a href="#logic">Conteneurs d'autorisation</a></seealso>
 541 <seealso><a href="../howto/auth.html">Authentification, autorisation et
 542 contrôle d'accès</a></seealso>
 543
 544 </directivesynopsis>
 545
 546 <directivesynopsis>
 547 <name>AuthMerging</name>
 548 <description>Définit la manière dont chaque logique d'autorisation des
 549 sections de configuration se combine avec celles des sections de
 550 configuration précédentes.</description>
 551 <syntax>AuthMerging Off | And | Or</syntax>
 552 <default>AuthMerging Off</default>
 553 <contextlist><context>directory</context><context>.htaccess</context>
 554 </contextlist>
 555 <override>AuthConfig</override>
 556
 557 <usage>
 558     <p>Lorsque l'autorisation est activée, elle est normalement héritée
 559     par chaque <a href="../sections.html#merging">section de
 560     configuration</a> suivante, à moins qu'un jeu de directives
 561     d'autorisations différent ne soit spécifié. Il s'agit du
 562     comportement par défaut, qui correspond à la définition explicite
 563     <code>AuthMerging Off</code>.</p>
 564
 565     <p>Dans certaines situations cependant, il peut être souhaitable de
 566     combiner la logique d'autorisation d'une section de configuration
 567     avec celle de la section précédente lorsque les sections de
 568     configuration se combinent entre elles. Dans ce cas, deux options
 569     sont disponibles, <code>And</code> et <code>Or</code>.</p>
 570
 571     <p>Lorsqu'une section de configuration contient <code>AuthMerging
 572     And</code> ou <code>AuthMerging Or</code>, sa logique d'autorisation
 573     se combine avec celle de la section de configuration qui la précède
 574     (selon l'ordre général des sections de configuration), et qui
 575     contient aussi une logique d'autorisation, comme si les deux
 576     sections étaient concaténées, respectivement, dans une directive
 577     <directive module="mod_authz_core"
 578     type="section">RequireAll</directive> ou <directive
 579     module="mod_authz_core" type="section">RequireAny</directive>.</p>
 580
 581     <note>La définition de la directive
 582     <directive>AuthMerging</directive> ne concerne que la section de
 583     configuration dans laquelle elle apparaît. Dans l'exemple suivant,
 584     seuls les utilisateurs appartenant au groupe <code>alpha</code> sont
 585     autorisés à accéder à <code>/www/docs</code>. Les utilisateurs
 586     appartenant au groupe <code>alpha</code> ou au groupe
 587     <code>beta</code> sont autorisés à accéder à
 588     <code>/www/docs/ab</code>. Cependant, la définition implicite à
 589     <code>Off</code> de la directive <directive>AuthMerging</directive>
 590     s'applique à la section de configuration <directive type="section"
 591     module="core">Directory</directive> concernant le répertoire
 592     <code>/www/docs/ab/gamma</code>, ce qui implique que les directives
 593     d'autorisation de cette section l'emportent sur celles des sections
 594     précédentes. Par voie de conséquence, seuls les utilisateurs
 595     appartenant au groupe <code>gamma</code> sont autorisés à accéder à
 596     <code>/www/docs/ab/gamma</code>.</note>
 597
 598     <highlight language="config">
 599 &lt;Directory "/www/docs"&gt;
 600     AuthType Basic
 601     AuthName Documents
 602     AuthBasicProvider file
 603     AuthUserFile "/usr/local/apache/passwd/passwords"
 604     Require group alpha
 605 &lt;/Directory&gt;
 606
 607 &lt;Directory "/www/docs/ab"&gt;
 608     AuthMerging Or
 609     Require group beta
 610 &lt;/Directory&gt;
 611
 612 &lt;Directory "/www/docs/ab/gamma"&gt;
 613     Require group gamma
 614 &lt;/Directory&gt;
 615     </highlight>
 616 </usage>
 617
 618 </directivesynopsis>
 619
 620 <directivesynopsis type="section">
 621 <name>AuthzProviderAlias</name>
 622 <description>Regroupe des directives représentant une extension d'un
 623 fournisseur d'autorisation de base qui pourra être référencée à l'aide
 624 de l'alias spécifié</description>
 625 <syntax>&lt;AuthzProviderAlias <var>fournisseur-de-base Alias
 626 Paramètres-Require</var>&gt;
 627 ... &lt;/AuthzProviderAlias&gt;
 628 </syntax>
 629 <contextlist><context>server config</context>
 630 </contextlist>
 631
 632 <usage>
 633     <p>Les balises <directive
 634     type="section">AuthzProviderAlias</directive> et
 635     <code>&lt;/AuthzProviderAlias&gt;</code> permettent de regrouper des
 636     directives d'autorisation auxquelles on pourra faire référence à
 637     l'aide de l'alias spécifié dans une directive <directive
 638     module="mod_authz_core">Require</directive>.</p>
 639
 640 </usage>
 641 </directivesynopsis>
 642
 643 <directivesynopsis>
 644 <name>AuthzSendForbiddenOnFailure</name>
 645 <description>Envoie '403 FORBIDDEN' au lieu de '401 UNAUTHORIZED' si
 646 l'authentification réussit et si l'autorisation a été refusée.
 647 </description>
 648 <syntax>AuthzSendForbiddenOnFailure On|Off</syntax>
 649 <default>AuthzSendForbiddenOnFailure Off</default>
 650 <contextlist><context>directory</context><context>.htaccess</context>
 651 </contextlist>
 652 <override>AuthConfig</override>
 653 <compatibility>Disponible depuis la version 2.3.11 d'Apache HTTPD</compatibility>
 654
 655 <usage>
 656     <p>Par défaut, si l'authentification réussit, alors que
 657     l'autorisation est refusée, Apache HTTPD renvoie un code de réponse
 658     HTTP '401 UNAUTHORIZED'. En général, les navigateurs proposent alors
 659     une nouvelle fois à l'utilisateur la boîte de dialogue de saisie du
 660     mot de passe, ce qui n'est pas toujours souhaitable. La directive
 661     <directive>AuthzSendForbiddenOnFailure</directive> permet de changer
 662     le code de réponse en '403 FORBIDDEN'.</p>
 663
 664     <note type="warning"><title>Avertissement de sécurité</title>
 665     <p>La modification de la réponse en cas de refus d'autorisation
 666     diminue la sécurité du mot de passe, car elle indique à un éventuel
 667     attaquant que le mot de passe qu'il a saisi était correct.</p>
 668     </note>
 669 </usage>
 670 </directivesynopsis>
 671
 672 </modulesynopsis>