Sections de configuration

Types de conteneurs de sections de configuration

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 fonctionner 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.

Syst�me de fichiers, arborescence du site web et expressions bool�ennes

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 tel que pr�sent� 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.

Conteneurs de syst�me de fichiers

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>

Conteneurs de l'arborescence du site web

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. Par exemple, l'exemple suivant montre comment faire r�f�rence � une URL particuli�re vers 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>

Espace web imbriqu�

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

Caract�res de remplacement et expressions rationnelles

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>

Expressions bool�ennes

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>

Que faut-il utiliser et quand ?

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 localisations de l'arborescence du site web (URLs) peuvent correspondre � la m�me localisation 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 cette localisation, 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 parceque 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 localisations de l'arborescence du site web � la m�me localisation 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 tout � fait sans rique car ce conteneur va s'appliquer � toutes les requ�tes sans tenir compte de l'URL sp�cifique.

Imbrication des sections

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>. Les valeurs des expressions rationnelles correspondant aux sections nomm�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.

H�tes virtuels

Le conteneur <VirtualHost> contient des directives qui s'appliquent � des h�tes sp�cifiques. Ceci s'av�re utile pour servir des h�tes multiples � 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 h�tes virtuels.

Mandataire

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� via le serveur mandataire du module mod_proxy. Par exemple, la configuration suivante va interdire l'utilisation du serveur proxy pour acc�der au site www.example.com.

<Proxy http://www.example.com/*>
    Require all granted
</Proxy>

Quelles sont les directives autoris�es ?

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 :

• La directive AllowOverride ne fonctionne que dans les sections <Directory>.
• Les Options FollowSymLinks et SymLinksIfOwnerMatch ne fonctionnent que dans les sections <Directory> ou les fichiers .htaccess.
• La directive Options ne peut pas �tre utilis�e dans les sections <Files> et <FilesMatch>.

Comment les sections sont combin�es entre elles

Les sections de configuration sont appliqu�es dans un ordre tr�s particulier. Il est important de savoir comment cet ordre est d�fini car il peut avoir des effets importants sur la mani�re dont les directives de configuration sont interpr�t�es.

L'ordre dans lequel les sections sont combin�es est :

1. Les sections <Directory> (� l'exception des expressions rationnelles) et les fichiers .htaccess sont appliqu�s simultan�ment (avec la possibilit� pour .htaccess, s'il y est autoris�, de pr�valoir sur <Directory>)
2. Les sections <DirectoryMatch> (et <Directory ~>)
3. Les sections <Files> et <FilesMatch> sont appliqu�es simultan�ment
4. Les sections <Location> et <LocationMatch> sont appliqu�es simultan�ment
5. Les directives <If>

Mises � part les sections <Directory>, chaque groupe est trait� selon l'ordre dans lequel il appara�t dans les fichiers de configuration. Les sections <Directory> (groupe 1 ci-dessus) sont trait�es dans l'ordre du r�pertoire le plus court vers le plus long. Par exemple, <Directory /var/web/dir> sera trait� avant <Directory /var/web/dir/subdir>. Si plusieurs sections <Directory> s'appliquent au m�me r�pertoire, elles sont trait�es selon l'ordre dans lequel elles apparaissent dans le fichier de configuration. Les sections de configuration incluses via la directive Include sont trait�es comme si elles se trouvaient r�ellement dans le fichier qui les inclut � la position de la directive Include.

Les sections situ�es � l'int�rieur de sections <VirtualHost> sont appliqu�es apr�s les sections correspondantes situ�es en dehors de la d�finition de l'h�te virtuel, ce qui permet � l'h�te virtuel de pr�valoir sur la configuration du serveur principal.

Quand la requ�te est servie par le module mod_proxy, le conteneur <Proxy> prend la place du conteneur <Directory> dans l'ordre de traitement.

Les sections situ�es plus loin dans le fichier de configuration pr�valent sur celles qui les pr�c�dent ; cependant, chaque module est responsable de la d�finition de la forme que doit prendre cette pr�valence. Une section de configuration ult�rieure contenant des directives d'un certain module peut �tre � l'origine d'une fusion conceptuelle de certaines directives, de toutes les directives, ou un remplacement complet de la configuration du module par ses valeurs par d�faut et les directives explicitement d�finies dans cette section ult�rieure.

Quelques exemples

Voici un exemple imaginaire qui montre l'ordre de combinaison des sections. En supposant qu'elles s'appliquent toutes � la requ�te, les directives de cet exemple seront appliqu�es dans l'ordre suivant : A > B > C > D > E.

<Location />
    E
</Location>

<Files f.html>
    D
</Files>

<VirtualHost *>
<Directory /a/b>
    B
</Directory>
</VirtualHost>

<DirectoryMatch "^.*b$">
    C
</DirectoryMatch>

<Directory /a/b>
    A
</Directory>

Pour un exemple plus concret, consid�rez ce qui suit. Sans tenir compte de toute restriction d'acc�s plac�e dans les sections <Directory>, la section <Location> sera �valu�e en dernier et permettra un acc�s au serveur sans aucune restriction. En d'autres termes, l'ordre de la combinaison des sections est important, soyez donc prudent !

<Location />
    Require all granted
</Location>

# Arrghs!  Cette section <Directory> n'aura aucun effet
<Directory />
    <RequireAll>
        Require all granted
        Require not host badguy.example.com
    </RequireAll>
</Directory>