Serveur HTTP Apache Version 2.4
Serveur HTTP Apache Version 2.4
Les directives des fichiers de configuration peuvent s'appliquer
au serveur dans son ensemble, ou seulement à des répertoires, fichiers, hôtes,
ou URLs particuliers. Ce document décrit comment utiliser les conteneurs de
sections de configuration ou les fichiers .htaccess pour
modifier la portée des directives de configuration.
Types de conteneurs de sections de
configuration Système de fichiers,
arborescence du site web et expressions booléennes Serveurs virtuels Mandataire Quelles sont les directives autorisées ? Comment les sections sont combinées entre elles
| Modules Apparentés | Directives Apparentées |
|---|---|
Il existe deux grands types de conteneurs. La plupart des conteneurs sont
évalués pour chaque requête. Les directives qu'ils contiennent s'appliquent
seulement aux requêtes qui sont concernées par le conteneur. En revanche,
les conteneurs
<IfDefine>, <IfModule> et
<IfVersion> sont
évalués seulement au démarrage et au redémarrage du serveur.
Si leurs conditions sont vérifiées au démarrage, les directives qu'ils contiennent
s'appliqueront à toutes les requêtes. Si leurs conditions ne sont pas vérifiées, les
directives qu'ils contiennent seront ignorées.
Le conteneur <IfDefine>
contient des directives qui ne seront appliquées que si un paramètre
approprié a été défini dans la ligne de commande de httpd.
Par exemple,
avec la configuration suivante, toutes les requêtes seront redirigées vers
un autre site si le serveur est démarré en utilisant la ligne de commande :
httpd -DClosedForNow :
<IfDefine ClosedForNow>
Redirect "/" "http://otherserver.example.com/"
</IfDefine>
Le conteneur <IfModule>
est similaire ; les directives qu'il contient ne s'appliqueront que si
un module particulier est disponible au niveau du serveur.
Le module doit être soit compilé statiquement dans le serveur, soit
dynamiquement et dans ce cas, la ligne LoadModule correspondante doit apparaître
plus haut dans le fichier de configuration. Ce conteneur ne doit être
utilisé que dans le cas où votre fichier de configuration doit être valable
indépendamment de la présence ou de l'absence de certains modules.
Il ne doit pas contenir de directives que vous souhaitez voir s'appliquer
systématiquement, car vous pouvez perdre ainsi de précieux messages d'erreur
à propos de modules manquants.
Dans l'exemple suivant, la directive MimeMagicFile ne s'appliquera que si le
module mod_mime_magic est disponible.
<IfModule mod_mime_magic.c>
MimeMagicFile "conf/magic"
</IfModule>
Le conteneur
<IfVersion>
est similaire aux conteneurs <IfDefine> et <IfModule> ; les directives qu'il contient ne
s'appliqueront que si une version particulière du serveur s'exécute. Ce
conteneur a été conçu pour une utilisation dans les suites de tests
et les grands réseaux qui doivent prendre en compte différentes versions
et configurations de httpd.
<IfVersion >= 2.4>
# les directives situées ici ne s'appliquent que si la version
# est supérieure ou égale à 2.4.0.
</IfVersion>
<IfDefine>,
<IfModule> et
<IfVersion>
peuvent inverser leur test conditionnel en le faisant précéder d'un « ! ».
De plus, ces sections peuvent être imbriquées afin de définir des restrictions
plus complexes.
Les conteneurs de sections de configuration les plus couramment utilisés
sont ceux qui modifient la configuration de points particuliers du système de
fichiers ou de l'arborescence du site web. Tout d'abord, il est important de
comprendre la différence entre les deux. Le système de fichiers est une vue de
vos disques tels qu'ils sont perçus par votre système d'exploitation. Par
exemple, avec une installation par défaut, Apache httpd est situé dans
/usr/local/apache2 pour le système de fichiers UNIX, ou
"c:/Program Files/Apache Group/Apache2" pour le système de
fichiers Windows (notez que des slashes directs doivent toujours être utilisés
comme séparateur de chemin dans les fichiers de configuration d'Apache httpd,
même sous Windows). Quant à l'arborescence du site web, il s'agit d'une vue de
votre site telle que présentée par le serveur web et perçue par le client.
Ainsi le chemin /dir/ dans l'arborescence du site web correspond
au chemin /usr/local/apache2/htdocs/dir/ dans le système de
fichiers pour une installation d'Apache httpd par défaut sous UNIX. En outre,
l'arborescence du site web n'a pas besoin de correspondre en permanence au
système de fichiers, car les pages web peuvent être générées dynamiquement à
partir de bases de données ou d'autres emplacements.
Les conteneurs <Directory>
et <Files>,
ainsi que leurs équivalents acceptant les
expressions rationnelles,
appliquent des directives à certaines parties du système de fichiers.
Les directives contenues dans une section <Directory> s'appliquent au répertoire
précisé, ainsi qu'à tous ses sous-répertoires et aux fichiers que ces
derniers contiennent.
Le même effet peut être obtenu en utilisant les fichiers .htaccess. Par exemple, avec la
configuration suivante, l'indexation sera activée pour le répertoire
/var/web/dir1 et tous ses sous-répertoires.
<Directory "/var/web/dir1">
Options +Indexes
</Directory>
Les directives contenues dans une section <Files> s'appliquent à tout fichier
avec le nom spécifié, quel que soit le répertoire dans lequel il se trouve.
Ainsi par exemple, les directives de configuration suivantes, si elles sont
placées dans la section principale du fichier de configuration, vont interdire
l'accès à tout fichier nommé private.html quel que soit
l'endroit où il se trouve.
<Files "private.html">
Require all denied
</Files>
Pour faire référence à des fichiers qui se trouvent en des points
particuliers du système de fichiers, les sections
<Files> et
<Directory>
peuvent être combinées. Par exemple, la configuration suivante va interdire
l'accès à /var/web/dir1/private.html,
/var/web/dir1/subdir2/private.html,
/var/web/dir1/subdir3/private.html, ainsi que toute instance de
private.html qui se trouve dans l'arborescence
/var/web/dir1/.
<Directory "/var/web/dir1">
<Files "private.html">
Require all denied
</Files>
</Directory>
le conteneur <Location>
et son équivalent acceptant les
expressions rationnelles modifient quant à eux la
configuration de parties de l'arborescence du site web. Par exemple, la
configuration suivante interdit l'accès à toute URL dont la partie chemin
commence par /private.
En particulier, l'interdiction s'appliquera aux requêtes pour :
http://yoursite.example.com/private,
http://yoursite.example.com/private123, et
http://yoursite.example.com/private/dir/file.html ainsi qu'à
toute requête commençant par la chaîne de caractères /private.
<LocationMatch "^/private">
Require all denied
</LocationMatch>
Le conteneur <Location>
n'a pas besoin de faire référence à un élément du système de fichiers.
À ce titre, l'exemple suivant montre comment faire correspondre une URL
particulière à un gestionnaire interne du serveur HTTP Apache fourni par le module
mod_status.
Il n'est pas nécessaire de trouver un fichier nommé server-status
dans le système de fichiers.
<Location "/server-status">
SetHandler server-status
</Location>
Pour contrôler deux URLs imbriquées, on doit tenir compte de l'ordre
dans lequel certaines sections ou directives sont évaluées. Pour
<Location>, on doit
avoir :
<Location "/foo"> </Location> <Location "/foo/bar"> </Location>
Les directives <Alias>, quant à elles, sont évaluées vice-versa :
Alias "/foo/bar" "/srv/www/uncommon/bar" Alias "/foo" "/srv/www/common/foo"
Ceci est aussi vrai pour les directives ProxyPass :
ProxyPass "/special-area" "http://special.example.com" smax=5 max=10 ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On
Les conteneurs <Directory>, <Files> et <Location> peuvent utiliser des caractères de
remplacement de style shell comme dans la fonction fnmatch de la
bibliothèque C standard. Le caractère « * » correspond à toute séquence de
caractères, « ? » à un caractère seul, et « [seq] » à tout caractère
contenu dans seq. Le caractère « / » ne peut pas faire l'objet d'un
remplacement ; il doit être spécifié explicitement.
Si une définition des critères de correspondance encore plus souple est
nécessaire, chaque conteneur possède son équivalent acceptant les expressions
rationnelles : <DirectoryMatch>, <FilesMatch> et <LocationMatch> acceptent les expressions rationnelles compatibles Perl pour définir
les critères de correspondance. Mais voyez plus loin la section à propos de la
combinaison des sections de configuration pour comprendre comment l'utilisation
de conteneurs avec des expressions rationnelles va modifier la manière dont les
directives sont appliquées.
Un conteneur qui modifie la configuration de tous les répertoires utilisateurs à l'aide de caractères de remplacement mais sans utiliser les expressions rationnelles pourrait ressembler à ceci :
<Directory "/home/*/public_html">
Options Indexes
</Directory>
Avec les conteneurs utilisant les expressions rationnelles, on peut interdire l'accès à de nombreux types de fichiers d'images simultanément :
+<FilesMatch "\.(?i:gif|jpe?g|png)$">
Require all denied
</FilesMatch>
Les expressions rationnelles contenant des groupes nommés et
des références arrières sont ajoutées à l'environnement avec
leur nom en majuscules. Cela permet de référencer des éléments de
chemins de fichiers et d'URLs depuis une expression et au sein de modules comme
mod_rewrite.
<DirectoryMatch "^/var/www/combined/(?<SITENAME>[^/]+)">
Require ldap-group "cn=%{env:MATCH_SITENAME},ou=combined,o=Example"
</DirectoryMatch>
La directive <If>
permet de modifier la configuration en fonction d'une condition qui peut
être définie sous la forme d'une expression booléenne. Dans l'exemple
suivant, l'accès est interdit si l'en-tête HTTP Referer ne commence pas
par « http://www.example.com/ ».
<If "!(%{HTTP_REFERER} -strmatch 'http://www.example.com/*')">
Require all denied
</If>
Choisir entre des conteneurs de système de fichiers et des conteneurs
d'arborescence du site web est vraiment très simple.
Pour appliquer des directives à des objets qui résident dans le système de
fichiers, utilisez toujours un conteneur <Directory> ou <Files>. Pour appliquer des directives à des objets
qui ne résident pas dans le système de fichiers (comme une page web générée
par une base de données), utilisez un conteneur <Location>.
Il ne faut jamais utiliser un conteneur <Location> pour restreindre l'accès à des
objets du système de fichiers, car plusieurs emplacements de
l'arborescence du site web (URLs) peuvent correspondre au même emplacement
du système de fichier, ce qui peut permettre de contourner vos restrictions.
Par exemple, imaginez la configuration suivante :
<Location "/dir/">
Require all denied
</Location>
Elle fonctionne correctement si la requête appelle
http://yoursite.example.com/dir/. Mais que va-t-il se passer si
votre système de fichiers est insensible à la casse ? Votre restriction va
pouvoir être tout simplement contournée en envoyant une requête sur
http://yoursite.example.com/DIR/. Le conteneur <Directory>, quant à lui, s'appliquera à
tout contenu servi à partir de cet emplacement, sans tenir compte de la manière
dont il est appelé. Les liens du système de fichiers constituent une exception.
Le même répertoire peut être placé dans plusieurs parties du système de fichiers
en utilisant des liens symboliques. Le conteneur <Directory> va suivre le lien symbolique sans modifier
le nom du chemin. Par conséquent, pour plus de sécurité, les liens symboliques
doivent être désactivés à l'aide de la directive Options appropriée.
Si vous pensez que vous n'êtes pas concerné par ce problème
parce que vous utilisez un système de fichiers sensible à la casse,
gardez à l'esprit qu'il y a de nombreuses autres manières pour faire
correspondre plusieurs emplacements de l'arborescence du site web au même
emplacement du système de fichiers. C'est pourquoi vous devez autant que
possible toujours utiliser les conteneurs de système de fichiers.
Il y a cependant une exception à cette règle. Placer des restrictions de
configuration dans un conteneur <Location
"/"> est absolument sans rique car ce conteneur va s'appliquer à
toutes les requêtes sans tenir compte de l'URL spécifique.
Certains types de sections peuvent être imbriqués : d'une part, on peut
utiliser les sections <Files>
à l'intérieur des sections <Directory>, d'autre part, on peut utiliser les
directives <If> à l'intérieur
des sections <Directory>,
<Location> et <Files> (mais pas à l'intérieur d'une
autre section <If>). Les
valeurs des expressions rationnelles correspondant aux sections citées se
comportent de manière identique.
Les sections imbriquées sont fusionnées après les sections non-imbriquées de même type.
Le conteneur <VirtualHost>
contient des directives qui s'appliquent à des serveurs virtuels spécifiques.
Cela s'avère utile pour servir les contenus de plusieurs serveurs virtuels à
partir de la même machine, chacun d'entre eux possédant une configuration
différente. Pour de plus amples informations, voir la Documentation sur les serveurs virtuels.
Les conteneurs
<Proxy>
et <ProxyMatch>
appliquent les directives de configuration qu'ils contiennent uniquement aux
sites qui correspondent à l'URL spécifiée et auxquels on a
accédé à l'aide du serveur mandataire du module mod_proxy.
Par exemple, la configuration suivante n'autorisera qu'un sous-ensemble de
clients à accéder au site www.example.com en passant par le serveur
mandataire :
<Proxy "http://www.example.com/*">
Require host yournetwork.example.com
</Proxy>
Pour déterminer quelles sont les directives autorisées pour tel type de
section de configuration, vérifiez le Contexte de la directive.
Tout ce qui est autorisé dans les sections
<Directory>
l'est aussi d'un point de vue syntaxique dans les sections
<DirectoryMatch>,
<Files>,
<FilesMatch>,
<Location>,
<LocationMatch>,
<Proxy>
et <ProxyMatch>.
Il y a cependant quelques exceptions :