mirror of
https://github.com/apache/httpd.git
synced 2025-10-31 19:10:37 +03:00
b50a7f23f2
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1674641 13f79535-47bb-0310-9956-ffa450edef68
672 lines
30 KiB
Plaintext
672 lines
30 KiB
Plaintext
<?xml version="1.0"?>
|
|
<!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
|
|
<?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
|
|
<!-- English Revision : 1673947 -->
|
|
<!-- 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">
|
|
<Directory "/www/mydocs">
|
|
<RequireAll>
|
|
<RequireAny>
|
|
Require user superadmin
|
|
<RequireAll>
|
|
Require group admins
|
|
Require ldap-group "cn=Administrateurs,o=Airius"
|
|
<RequireAny>
|
|
Require group ventes
|
|
Require ldap-attribute dept="ventes"
|
|
</RequireAny>
|
|
</RequireAll>
|
|
</RequireAny>
|
|
<RequireNone>
|
|
Require group temps
|
|
Require ldap-group "cn=Employés temporaires,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 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>
|
|
|
|
<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">
|
|
<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
|
|
|
|
#Opération logique implicite : OU inclusif
|
|
Require ldap-group-alias1
|
|
Require ldap-group-alias2
|
|
</Directory>
|
|
</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>
|
|
</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">
|
|
<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 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">
|
|
<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>
|