4 203
modifications
« Installation de configuration du serveur web Apache 2.4 sous Debian Bullseye » : différence entre les versions
Aller à la navigation
Aller à la recherche
Installation de configuration du serveur web Apache 2.4 sous Debian Bullseye (voir la source)
Version du 31 juillet 2022 à 19:12
, 31 juillet 2022→AllowOverride
| Ligne 322 : | Ligne 322 : | ||
Notez qu'il est important de faire terminer le path par un <code>/</code> (le path <code>/votre/documentroot</code> est considéré comme <code>/votre/documentroot*</code> | Notez qu'il est important de faire terminer le path par un <code>/</code> (le path <code>/votre/documentroot</code> est considéré comme <code>/votre/documentroot*</code> | ||
===AllowOverride=== | ===AllowOverride et .htaccess=== | ||
AllowOverride permet de définir les règles autorisées à être modifiées par un fichier <code>.htaccess</code><br> | AllowOverride permet de définir les règles autorisées à être modifiées par un fichier <code>.htaccess</code><br> | ||
Notez que cette directive doit obligatoirement être définie dans un champ <Directory><br> | |||
La configuration apache que nous avons vu plus tôt désactive complètement les fichiers <code>.htaccess</code> dans la totalité du système de fichier. Le problème de ce comportement est que les fichiers htaccess seront tout simplement ignoré, or, de nombreux projets utilisent les fichiers htaccess pour protéger de la lecture certains répertoires sensibles (fichiers de configurations, etc).<br> | La configuration apache que nous avons vu plus tôt désactive complètement les fichiers <code>.htaccess</code> dans la totalité du système de fichier. Le problème de ce comportement est que les fichiers htaccess seront tout simplement ignoré, or, de nombreux projets utilisent les fichiers htaccess pour protéger de la lecture certains répertoires sensibles (fichiers de configurations, etc).<br> | ||
'''Si vous êtes certain que votre projet n'utilise pas de fichiers .htaccess, la question ne se pose même pas, gardez les fichiers htaccess désactivés''' ! Même s'ils sont pratiques, ils restent des fichiers relativement faciles à modifier (un peu de code foireux dans un module externe d'un CMS par exemple) et offrent donc une sécurité bien moindre que les directives définies directement dans la configuration de votre virtualhost apache ! Ils ont | Plusieurs options s'offrent à vous : | ||
* '''Si vous êtes certain que votre projet n'utilise pas de fichiers .htaccess, la question ne se pose même pas, gardez les fichiers htaccess désactivés''' ! Même s'ils sont pratiques, ils restent des fichiers relativement faciles à modifier (un peu de code foireux dans un module externe d'un CMS par exemple) et offrent donc une sécurité bien moindre que les directives définies directement dans la configuration de votre virtualhost apache ! Ils ont également un impact sur les performances de apache (nécessité pour apache de remonter l'arborescence à la recherche d'un .htaccess à chaque requête).<br> | |||
* Si votre projet utilise des fichiers .htaccess, il est possible d'intégrer leur contenu à la configuration de votre virtualhost. Vous y gagniez ainsi en sécurité et en performances tout en limitant un vecteur d'attaque. | |||
* Si votre projet utilise des fichiers .htaccess mais qu'ils ne peuvent pas être intégrés à la configuration de votre virtualhost (fichiers générés par un client dans le cadre d'une activité de hosting, fichier dynamique généré par le projet lui même, etc), l'idéal est de restreindre les capacités des fichiers .htaccess, ce que vous allons voir plus loin. | |||
Dans tous les cas : | Dans tous les cas : | ||
| Ligne 342 : | Ligne 344 : | ||
AllowOverrideList Require | AllowOverrideList Require | ||
</pre> | </pre> | ||
* Si jamais le projet en question | * Si jamais le projet en question nécessite les directives d'authentifications, on pourra définir comme cela : | ||
<pre> | <pre> | ||
AllowOverride Limit AuthConfig | AllowOverride Limit AuthConfig | ||