1

sudo apt-get install sysv-rc-conf

Lancez l’outil :

1

sudo sysv-rc-conf

cela devrait vous donner un truc pareil :

Le reste est simple! désactivez le service apache et sauvez.
Cool n’est ce pas?

Dans cet article, en présentant quelques exemples, je vais essayer d’expliquer ce qui se passe afin de comprendre les principes de bases. Vous pourrez par la suite étendre ces exemples pour en créer vos propres commandes. Les exemples de ce tutoriel s’appliquent sur Apache2 et ont ete testés sur Ubuntu. Vous trouverez les sources de ce tutoriel au bas de l’article.

Qu’est ce que les .htaccess?

Les fichiers .htaccess ou encore les fichiers de configuration distribués offre un moyen pour effectuer des changements de configuration par base de répertoire. Un fichier contenant une ou plusieurs directives de configuration est placé dans un répertoire, la configuration s’applique alors a ce répertoires et aux répertoires fils.

Directives

On peut voir “Directives” comme des commandes d’Apache. Les directives sont placées dans le fichier .htaccess et sont relativement des courtes commandes. Elles sont généralement représentées par une paire de clé valeur, qui modifient le comportement d’Apache. Le fichier .htaccess permet d’exécuter un ensembles de directives sans obliger l’accès au fichier de configuration de base d’Apache (généralement le fichier httpd.conf ou apache2.conf). Ce fichier, apache2.conf est typiquement le fichier de configuration global.

Note : En dessous de apache2.conf, les configurations peuvent s’écrire aussi dans vos fichiers d’hôtes virtuels (virtual hosts), ces fichiers qui vous permettent de faire des configurations généraux par domaine. Vous pouvez aussi activer / désactiver globalement les directives a ce niveau. Dans ce qui reste du tutoriel, je vais continuer a citer apache2 comme fichier de référence.

La fonctionnalité est idéale pour les hébergements mutualisés du fait que l’hébergeur ne permet pas a ses différents client d’accéder au fichier de configuration global qui affecte l’ensemble des clients qui hébergent leurs applications sur ce serveur. Les clients alors pourront, en activant ces fichiers .htaccess, spécifier et executer leurs directives Apache sur leurs répertoires et fichiers respectives. Évidemment, les fichiers .htaccess sont très utiles pour les développeurs comme nous le verrons plus tard.

Ce qu’il faut savoir c’est que n’importe quelle directive qu’on peut spécifier dans le fichier .htaccess peut également être placée dans le fichier apache2.conf. L’inverse n’est toutefois pas vrai, ce ne sont pas toutes les configurations que le apache2.conf peut comprendre qui peuvent être mis dans un .htaccess. En effet, les fichiers .htaccess doivent être activées dans le fichier apache2.conf afin d’être exécutées. Une fois activées, leur pouvoir peut être limite a certains “contextes”, ils pourront alors redéfinir quelques aspects mais pas d’autres. De cette façon, les administrateurs pourront contrôler ce que peuvent faire les développeurs avec ces fichiers .htaccess.

Comment activer les .htaccess

Généralement, les .htaccess sont actives par défaut. Ceci est contrôlé par la directive AllowOverride dans le fichier apache2.conf. Cette directive peut être uniquement placée dans la section <Directory>. Attention a ne pas être confondu ici, Un fichier typique apache2.conf définit un DocumentRoot et la majorité du fichier contiendra des directives a l’ intérieur de la section Directory qui gère votre répertoire global (votre document root). Ceci inclut la directive AllowOverride.

La valeur par défaut est “All” et donc les fichiers .htaccess seront actives par défaut. Une valeur alternative peut être “None” ce qui permettra de les désactiver. De multiples valeurs peuvent limiter la configuration a seulement quelques contextes. Par exemple:

• AuthConfig – directives d’Autorisation comment ceux qui gèrent les authentifications Authentification.
• FileInfo – directives qui gèrent les entêtes HTTP, les documents d’erreur, les Cookies, la reecriture d’URL (URL rewriting) etc.
• Indexes – personnalisation par défaut du contenu du répertoire
• Limit – contrôle l’accès aux pages de manières différentes
• Options – pareil que Indexes, mais inclut plus de valeurs comme ExecCGI, FollowSymLinks etc.

L’exemple suivant permet une surcharge complète des .htaccess

1
2

# controle total des .htaccess
AllowOverride All

Par contre, l’exemple ci-dessous permet une configuration plus granulaire (surcharge limitee):

1
2

# Permettre uniquement de specifier Authorization et Indexes
AllowOverride AuthConfig Indexes

La première ligne de chacun des deux exemples précédent est un commentaire. Ceci est commun aux langages de scripts et a plusieurs fichiers de configuration. Bien que fortement conseillés, les commentaires ne sont pas obligatoires.

La deuxième ligne pressente la directive AllowOverride. C’est la syntaxe usuelle d’une directive Apache. Le nom de la directive (AllowOverride) est suivi d’un espace suivi d’une liste de valeurs séparées par un espace.

Dans plusieurs cas, une seule erreur dans le fichier apache2.conf ou un fichier de configuration .htaccess peut causer un plantage temporaire du serveur, les utilisateurs verront le message : 500 – Internal Server Error pages.

Pour cette unique raison, c’est une bonne pratique de faire une copie de sauvegarde de votre fichier apache2.conf et de vos fichiers .htaccess avant de faire un changement ou un ajout. Il aussi conseille de faire des petits changement a chaque fois et de vérifier s ces changements ont pris effet. De cette manière vous vous retrouverez plus rapidement en cas d’erreur.

Si vous êtes vraiment confus dans la syntaxe d’une directive, veuillez consulter la la liste des directives Apache pache qui reste toujours la meilleure ressource de documentation.

Tester si .htaccess est activé :

Le premier fichier auquel apache route vos requêtes http est par defaut le fichier index.html. Ce cas est tres simple. Il utilise une directive pour dire a Apache d’aller a un fichier leBonFichier.html avant de chercher index.html . Si .si .htaccess est activee, lorsque vous pointez votre navigateurs vers ce répertoire, Apache chargera le fichier .htaccess et saura qu’il devra charger le fichier leBonFichier.html. Si par contre .htaccess n’est pas activé, Apache ignorera le chargement du .htaccess et chargera donc index.html.

1
2

# Dire a Apache de charger leBonFichier.html avant de charger index.html
DirectoryIndex leBonFichier.html index.html

L’idée est simple ici, la directive DirectoryIndex prend une liste de fichiers éventuels a charger. En effet, c’est ce qui fait que lorsque vous accédez a une adresse du genre http://www.serveur.com vous seriez éventuellement redirige vers http://www.serveur.com/index.html . En effet, Apache cherchera les fichiers de gauche a droite. Le premier fichier trouve sera chargé et affiché au client.

Voici le rendu selon le premier exemple si .htaccess est active

et si .htaccess n’est pas active

Conséquences des fichiers .htaccess

Il est important de comprendre ce qui se passe lorsque les .htaccess sont activées sur le serveur. Comme mentionnée auparavant, quand vous activez les .htaccess, vous allouez la surcharge ou la redéfinition des directives pour un répertoire et tous ces répertoires fils. Ayez toujours en tête que vous êtes en train d’affecter tous les sous répertoires ainsi que le répertoire courant.

Aussi, lorsqu’ils sont actifs, le serveur va perdre un peu de performance. La raison est que pour chaque requête sur le serveur, si .htaccess est activé, lorsque Apache va ouvrir le fichier requis, il a a chercher le fichier .htaccess pour chaque répertoire menant au fichier.

On peut comprendre beaucoup de choses ici: premièrement, parce qu’Apache cherchera toujours le fichier .htaccess pour chaque requête, chaque changement sur le fichier prendra effet directement. Ces fichiers ne sont pas cachés et Apache verra immédiatement le changement a la prochaine requête. Par contre, ceci veut dire aussi qu’Apache va faire du travail supplémentaire pour chaque requête. Par exemple, si un utilisateur demande le fichier /www/repertoireduclient/sousrepertoire/index.html, le serveur cherchera les fichiers .htaccess suivants :

• /www/.htaccess
• /www/repertoireduclient/.htaccess
• /www/repertoireduclient/sousrepertoire/.htaccess

les acces a ce fichier potentiel (potentiel, puisque le fichier peut ne pas exister) prendra du temps.

Ceci ne veut pas dire que vous devez ignorer d’utiliser les .htaccess. Par contre, si vous avez access a modifier votre apache2.conf (ou vos fichiers d’hotes virtuels), mettez toujours vos directives la dedans. Voici un exemple :

1
2
3

<Directory /www/repertoireduclient/sousrepertoire>
# vos directives ici
</Directory>

l’inconvénient de cette approche est que vous auriez a redémarrer Apache pour que les modifications tiennent effet.

Ce que je fais personnellement, lors du développement, j’utilise les .htaccess pour aller vite. Mais une fois sur un environnement de Test ou de Prod, j’applique les effets sur les fichiers d’hôte virtuel ou dans Apache2.conf

Voici maintenant quelques exemples

Listings de repertoires

Avant d’aller vers des exemples complexes, commençons par un truc simple mais utile. Vous avez certainement rencontre un exemple de listing de répertoires. Lorsqu’un utilisateur accéde a un répertoire, Apache va chercher le fichier par défaut qui est index.html, index.php ou un truc similaire. Si il ne trouve aucun fichier, il utilisera le module mod_autoindex pour afficher la liste des fichiers et répertoires dans le répertoire courant. Des fois ce module est activé et des fois il est désactivé. Vous pouvez manipuler toutefois ce comportement avec les .htaccess.

Voici un exemple :

1
2
3

# Desactiver les listings de repertoire pour ce repertoire et les sous-repertoires.
# Ceci va cacher les fichier au public sauf si ils connaissent les URLs directs
Options -Indexes

La directive Options prend un nombre de valeurs (+ ou – pour Indexes), ceci va hériter des directives Options des répertoires parents et ceux de la configuration globale. En ajoutant la syntaxe + ou -, vous vous assurez que vous voulez uniquement certains options, puisque vous ne connaissez pas les options qui étaient mises auparavant.

Le résultat de la directive -Indexes est le suivant :

Celui de +Indexes est le suivant

Authentification de base

En effet, vous ne voulez peut être pas désactiver complètement l’accès a un répertoire. Vous voulez peut être donner l’accès a certaines personnes. La directive Basic Authentication peut vous etre utile dans ce cas. C’est le cas le plus répandu sur le web. Lorsqu’un utilisateur essaye d’accéder aux pages, il va avoir la fenêtre familière Login/mot de passe. Seuls les utilisateurs permis vont pouvoir accéder aux pages.

Pour l’authentification de base il y a deux étapes:

• Configurer un fichier (en-crypté) qui va contenir les logins/mots de passe
• Ajouter quelques lignes au fichier .htaccess pour utiliser ce fichier

Traditionnellement, les développeurs web nomment le fichier qui contient les comptes/mots de passe « .htpasswd ». ceci vient du fait que l’outil en ligne de commande qui génère la paire compte/mot de passe en-crypté est appelé htpasswd. Il existe plusieurs outils en ligne qui génèrent cette paire facilement.

Voici la ligne encryptee pour l’utilisateur : « anis » et mot de passe « anis »

1

anis:$apr1$QH3dV/..$HVTNKumUmtCoIxsMMimOo0

une fois cette ligne ajoutée au fichier .htpasswd, ajoutez ce qui suit a votre fichier .htaccess:

1
2
3
4
5
6
7
8

# Activer l'authentification de base
AuthType Basic
# Ceci est ce qui va etre affiche dans la boite de dialogue d'authentification
AuthName "Access to the Hidden Files"
# Editer ceci pour le chemin absolu au fichier .htpasswd
AuthUserFile /chemin/absolu/.htpasswd
# Ceci permet a un utilisateur valide dans le fichier .htpasswd d'acceder a la ressource
Require valid-user

Ces commandes sont bien commentées. Le seul défi ici est de mettre le bon chemin pour votre .htpasswd. Une bonne pratique est de le mettre dans un répertoire externe aux répertoires qu’Apache sert, afin que les utilisateurs mal intentionnés ne puissent pas avoir accès au fichiers .htaccess et a son contenu.

Voici la boite de dialogue qui s’affiche en accédant au répertoire

une fois vous saisissez les bons accès – ici anis anis – voici le résultat :

L’authentification de base est une solution simple. Mais ce n’est pas une solution complête. Les mots de passe sont encodées en Base64 et envoyées sur le réseau. Si vous voulez une authentification plus sécurisée utilisez plutôt le protocole https.

Entêtes

Bien que tutoriel suppose que vous ayez des connaissances basiques sur les entetes HTTP., je vais quand même faire quelques rappels de base. HTTP est un protocole sans état, c’est a dire que chaque requête/réponse entre le navigateur et le serveur est indépendante des autres requêtes/réponses. Aussi, avec chaque requête envoyée a partir de votre navigateur au serveur, et chaque réponse du serveur (Apache par exemple) a votre navigateur, il ya deux sections. Une section contenant des entêtes et une section contenant des données.

Les entêtes des requêtes spécifient toujours le fichier qu’elles demandent ai serveur (par exemple index.html), les informations d’état qu’ils devraient donner (les informations de cookie par exemple) ainsi que le type MIME qu’elles vont recevoir (par exemple text/html)

Les entêtes des réponses spécifient, quant a elles, les informations génériques du serveur (Apache, PHP, Perl etc), l’encodage du contenu, la longueur, le type MIME. Il existe en effet une multitude d’entêtes qui spécifient des détails comme le Cache Control , les redirections, les codes d’état (le code 404 par exemple pour un fichier non trouve sur le serveur)etc.

Mais qu’est ce que ceci a a voir avec les .htaccess? En effet, vous pouvez utiliser les directives Apache pour redéfinir (ou ajouter) de nouvelles entêtes. Vous pouvez aussi ajouter les fonctionnalités avancées pour la re-écriture des URLs.

Un exemple utilisant la reecriture d’URLs

Je vais essayer de parler plus en profondeur de l’URL rewriting dans un article a part, mais j’expliquerai sommairement quelques regles relatifs a notre exemple

Exemple : Interdire l’acces distant aux ressources

Ceci est communément appelée en anglais : Hotlinking, ou encore inline linking. C’est quand un site web effectue un lient directement a une ressource sur un autre site. Ceci coûte au site de la bande passante pour servir l’image sur le site demandeur. Ceci peut être un vrai problème pour les sites populaires de photos.

Il existe plusieurs façons pour fixer ce problème en utilisant les .htaccess.

Voici un exemple de code dans lequel on veut permettre de servir des images a des domaines spécifiques mais pas a tous les sites

1
2
3
4
5
6
7

 RewriteEngine on
 RewriteCond %{HTTP_REFERER} !^$
 #liste des domaines qui peuvent acceder l'image
 RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?.site-alloue-1.com [NC]
 RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?.site-alloue-2.com [NC]
 #Affiche No Image quand le site n'a pas le droit
 RewriteRule \.(jpg|png|gif)$ - [NC,F,L]

Essayons de comprendre l’exemple ligne par ligne:

1. Premièrement, nous devons activer l’engin de réécriture d’URLs dans Apache : rewrite engine . Ceci nous permettra de rediriger la requête de l’utilisateur.
2. Ensuite, en utilisant la directive RewriteCond , nous allons spécifier nos règles de réécriture. RewriteCond prend deux arguments: laChaine et laRegle. LaChaine est la chaine sur laquelle nous voulons tester notre règle laRegle (en utilisant les expressions régulières). ${HTTP_REFERER} est une variable fournie par Apache qui contient le domaine de provenance de la requête. Dans ce cas, nous voulons allouer les requêtes ayant des HTTP REFERERs nuls afin de protéger les utilisateurs qui sont sur un serveur proxy qui envoie des referers nuls.
3. Ensuite, nous allons spécifier les domaines allouees a lier nos images en utilisant toujours la même syntaxe, en spécifiant cette fois des URLs. Le flag [NC] a la fin de la commande indique a l’engin d’ignorer la casse. Vous pouvez ajouter des lignes selon vos besoin.
4. Finalement, la dernière ligne utilise la directive RewriteRule dans le cas échéant. Cette directive prend deux arguments Modele et Substitution, Pattern est une expression régulière est Substitution est ce par quoi on veut remplacer les parties concordantes. Dans ce cas nous sommes en train d’analyser les urls finissant avec jpg, png, et gif; Si on en trouve, nous substituons par rien. Désormais, nous utilisant le flag NC on indique d’ignorer la casse, le flag F quand a lui, envoie une erreur 403 « forbidden » a l’utilisateur, le flag L indique a l’engin d’arrêter la réécriture, donc les autres règles ne seront pas appliquées.

Ceci a l’air simple, mais peut être que nous serions intéressés a dire a l’utilisateur explicitement que nous ne voulons pas qu’ils fassent un lien direct a nos images. Ce que nous pouvons faire donc c’est au lieu d’envoyer une erreur 403, nous allons rediriger tous les requêtes non permises a une image par défaut indiquant que le lien est interdit. Remplaçons la dernière ligne par ce qui suit :

#Afficher une image alternative
RewriteRule \.(jpg|png|gif)$ http://www.votreserveur/img/nonpermis.jpeg [NC,R,L]

Le dernier flag R qui a remplacé F indique la redirection.

Attention ici! Vous remarquez l’utilisation de .jpeg (ancienne extension de jpg). Ceci est mis exprès, du fait que si votre lien finira par .jpg (ou .png ou .gif), ceci va envoyer le serveur dans une boucle infinie! Vous pouvez aussi utiliser n’importe quelle autre extension, .php par exemple.

Conclusion

Dans cet article j’ai essayé d’expliquer avec un certain niveau de detail quelques directives apache basiques. J’essayerai de parler un peu plus dans un prochain article de la réécriture d’URLs.

Telecharger les fichiers sources

References

La bible d’Apache : Pro Apache , un livre Excellent!