Le fichier .htaccess

Ceci est une ARCHIVE, peut-être périmée. Vérifiez bien les compatibilités !

Cet article a pour but de vous faire découvrir le fichier .htaccess et son utilisation pour paramétrer les accès à votre site web.

Article original publié sur le site dynamique de l’immobilier

Le fichier .htaccess

Cet article a pour but de vous faire découvrir le fichier .htaccess et son utilisation pour améliorer votre site web.

Ce simple fichier texte [1] vous permet d’ajuster finement certains paramètres de votre serveur Apache tels que les redirections, les réécritures d’URL, les redirections et les restrictions d’accès.

Cette puissance permet le meilleur comme le pire. Même si la syntaxe des règles du fichier .htaccess est souvent triviale, la moindre faute dans celles-ci se traduira le plus souvent par la redoutée "erreur 500" [2].

L’une des utilisations les plus répandues de ce fichier est l’affichage d’une page 404 [3] personnalisée, beaucoup plus utile que celle procurée par défaut par votre navigateur favori.

Note aux utilisateurs FrontPage

Lorsque les extensions FrontPage sont installées, un fichier .htaccess est créé à la racine du site. Il faut donc être très prudent et éviter d’écraser ce fichier, faute de quoi les extensions FrontPage ne fonctionneraient plus sur votre site. De même, avant toute modification, une sauvegarde du fichier originel est utile, car toute erreur dans ce fichier pourrait rendre l’entièreté de votre site inaccessible.

Votre hébergement permet-il son utilisation ?

C’est, bien sûr, la première question à se poser. Elle ne fait malheureusement pas partie de celles auxquelles on peut répondre simplement.
Si votre hébergement se fait sur un système Unix/Linux et que le serveur Web est de type Apache, le fichier .htaccess est supporté. Ceci ne veut malheureusement pas dire que votre hébergeur en autorise l’utilisation.
Le plus souvent, les hébergements gratuits ont cette fonctionnalité désactivée.

Si votre hébergeur vous permet de restreindre l’accès à certains de vos répertoires à l’aide d’un mot de passe, c’est en général à l’aide du fichier .htaccess, dans ce cas, tout va bien.

De deux choses l’une : soit vous téléchargez votre fichier .htaccess et tout fonctionne comme vous l’espériez, soit cela ne fonctionne pas et au pire vous obtenez une "erreur 500". Dans ce cas, il ne vous reste plus qu’à retirer le fichier incriminé. Ce n’est pas bien dangereux, mais réservez vos essais à une période creuse. Le seul cas où un fichier .htaccess pourrait poser de réels problèmes est celui où le serveur utilise des extensions Microsoft FrontPage.
Ces dernières utilisent le fichier .htaccess et son écrasement les empêcherait à jamais de fonctionner.

Si vous n’aimez pas vivre dangereusement, le plus simple reste encore de demander à votre hébergeur ou à une connaissance ayant le même type d’hébergement que vous.

Pour effectuer vos tests, il est judicieux de créer un répertoire temporaire sur votre site, dans lequel vous mettrez un fichier index.html et le fichier .htaccess sur lequel vous travaillez.

Une fois votre fichier .htaccess mis au point, déplacez le dans le répertoire que vous voulez protéger, ou à la racine de votre site.

C’est supporté ? Bien ! Restez avec nous !

Avant toutes choses, il faut arriver à créer ce fichier. Sous pratiquement tous les systèmes d’exploitation, cela se fait sans problème comme n’importe quel fichier texte.
Windows peut toutefois ne pas accepter la création de ce fichier tel que souhaité. En effet, .htaccess est vu par Windows comme un fichier sans nom comportant une extension non standard. Si notepad ou votre éditeur favori ne vous permet pas d’enregistrer ce fichier avec le nom souhaité, sauvez-le comme htaccess.txt, vous le renommerez plus tard sur votre serveur à l’aide de votre logiciel de transfert ftp.
Attention : Une fois renommé, le fichier doit impérativement se nommer « .htaccess » (débutant par un point), sinon il sera sans effet.

Nous allons commencer notre découverte avec une fonctionnalité bien utile

La page d’erreur « sur mesure »

Comme tout internaute, vous avez déjà eu l’occasion de faire face à l’erreur la plus répandue, l’erreur 404. Cette erreur vient du fait que l’Internet est essentiellement mouvant, des millions de pages y apparaissent et disparaissent chaque jour.
Si un de vos visiteurs décide de mettre en favori l’une de vos pages pour y revenir plus tard, rien ne lui garantit que cette page sera toujours accessible à sa prochaine visite.
Vous pouvez à tout moment décider de la déplacer, de la renommer ou de la supprimer. C’est votre site, vous en avez le droit le plus absolu.

Que se passera-t-il lors du retour de ce même visiteur ? C’est simple : son navigateur fera une requête pour la page souhaitée, requête à laquelle le serveur répondra « pas trouvé ».
Dès la genèse du Web, les différents concepteurs ont bien intégré le fait que les utilisateurs seraient d’origines différents et qu’une page mentionnant ce laconique « pas trouvé » ne pourrait pas être exhaustive sur le plan linguistique. Ils ont donc défini des codes pour chaque type d’erreurs, laissant aux navigateurs le soin d’afficher le message dans la langue de l’utilisateur. D’où, dans ce cas précis, l’erreur communément appelée « erreur 404 ».

Pour éviter à vos visiteurs cette page peu esthétique, une seule ligne suffit dans le fichier .htaccess :

ErrorDocument  404  /mapage.html

Dès ce moment, toutes les requêtes pour des pages inexistantes recevront en retour la page mapage.html. Si vous êtes prévoyant, cette page pourrait présenter un plan de votre site qui évitera à votre visiteur de se sentir seul et abandonné de tous. Il faut bien sûr que ce fichier « mapage.html » existe à la racine de votre site sinon votre serveur ne saura plus où donner de la tête. Ne souriez pas, c’est arrivé à l’auteur de ces lignes.

D’une manière plus générale, l’instruction « ErrorDocument » s’écrit :

ErrorDocument  code-erreur  fichier

En plus de l’erreur 404, vous pouvez donc fournir des pages spécifiques pour les erreurs les plus fréquentes, par exemple :

401 - Autorisation Requise
400 - Mauvaise requête
403 - Interdit
500 - Erreur interne serveur

La restriction d’accès par mot de passe

Nous avons tous sur nos sites certains répertoires que nous souhaitons protéger des yeux indiscrets. Qu’il soit bien entendu ici, que la meilleure protection possible pour un document passe par la non publication sur le Web, quelle que soit le niveau de protection du serveur ou du répertoire.
Ceci est encore plus vrai s’il s’agit d’un hébergement mutualisé dont la gestion est assurée par un organisme indépendant. Ne stockez donc pas sur votre serveur Web d’informations dont la divulgation pourrait vous pénaliser.

Ces limitations étant exprimées, il est souvent utile ou dans certains cas indispensable d’avoir dans un répertoire des informations telles que le mot de passe d’accès à votre base de données ou les statistiques de fréquentation de votre serveur.
Dans le cadre des hébergements sur serveur Apache, il est aisé de soustraire certains répertoires à la curiosité du public. Cette fois encore, le fichier .htaccess est votre allié.

Le mode opératoire en est simple et s’appuie sur un deuxième fichier qui contiendra les noms et mots de passe des personnes autorisées à accéder au contenu du répertoire.

Dans le fichier .htaccess, saisissez les informations suivantes :

AuthUserFile /home/login/.htpasswd
AuthGroupFile /dev/null
AuthName "Acces Restreint"
AuthType Basic
<Limit GET POST>
require valid-user
</Limit>

Analysons de plus près ces quelques lignes :

AuthUserFile /home/login/.htpasswd
donne le répertoire dans lequel se trouve le fichier contenant les paires login/mot de passe des visiteurs autorisés. Notez bien qu’il ne s’agit pas d’une URL, mais bien d’un chemin d’accès depuis la racine du serveur.

L’usage veut que ce fichier soit souvent nommé .htpasswd, mais ce n’est pas du tout une obligation. Il est même conseillé d’utiliser un autre nom, le fichier sera d’autant plus difficile à trouver. Ne le mettez pas dans un répertoire qui fait partie du site mais placez-le plutôt en dehors de cette arborescence si vous en avez le choix.

Dans le système d’exploitation Unix/Linux, tous les fichiers dont le nom commence par un point décimal sont des fichiers cachés. Attention : caché ne signifie pas invisible, mais signifie plutôt qu’ils n’apparaissent pas dans les commandes les plus fréquentes si leur affichage n’est pas spécifiquement demandé.

AuthGroupFile /dev/null
permet de donner un droit d’accès à un ensemble d’utilisateurs faisant partie d’un même groupe et est rarement utilisée dans le cas de sites Web personnels. Dans l’exemple, le fichier « /dev/null » est l’équivalent Unix de « nulle-part » ou « pas de fichier spécifique »

AuthName "Acces Restreint"
est la chaîne de caractère qui apparaîtra dans la boîte de dialogue au moment de la saisie du nom et du mot de passe.

AuthType Basic
détermine le type d’authentification utilisé, dans notre cas l’authentification HTTP standard.

<limit GET POST> ... </limit>
détermine le type d’opérations permises. GET s’applique à la majorité des pages Web, PUT est utilisé par certains scripts ou éditeurs pour faire de l’upload sous protocole http. Il est important de mettre GET et POST en majuscule sur les dernières versions d’Apache.

require valid-user
signifie littéralement qu’un utilisateur valide est requis, à savoir un utilisateur pour le nom duquel une ligne existe dans le fichier .htpasswd. Une variante pourrait être :
require user pierre paul
pour limiter l’accès aux seuls utilisateurs pierre et paul

Le fichier .htpasswd

C’est très simple, pour chaque utilisateur autorisé ce fichier contient une ligne sous la forme « nom:mot de passe crypté » ou encore « pierre:saqKFoHV4rU.E »

La seule difficulté, pour autant que c’en soit une, étant de crypter le mot de passe. Il existe deux types d’approche différents :

-  Vous avez accès a un shell Unix/Linux

htpasswd -c passwdfile username

Dans cette commande, « passwdfile » représente le chemin complet du fichier mot de passe souhaité, « username » est le nom de l’utilisateur.

-  Pour tous ceux qui n’ont pas d’accès au shell unix, plusieurs sites sur le Web vous permettent d’obtenir le mot de passe encrypté, par exemple : http://ovh.fr/cgi-bin/crypt.pl

Vous voilà en mesure de restreindre l’accès à vos répertoires privés ou, pourquoi pas, de créer des répertoires réservés aux copains ou aux membres de votre famille.

Vous avez déplacé vos pages ?

Il est parfois nécessaire de déplacer certaines pages ou répertoires d’un site dans l’optique d’une restructuration. Ceci ne va pas sans poser quelques problèmes inhérents au changement d’adresse :
-  la page n’est plus accessible pour les visiteurs qui l’ont mise dans leurs favoris.
-  les références à cette page dans les moteurs de recherche et annuaires pointent vers l’ancienne adresse.

Dans ces deux cas de figure, plutôt que de présenter une page d’erreur personnalisée au visiteur, il est beaucoup plus élégant de le rediriger automatiquement vers la nouvelle adresse. Ici encore, le fichier .htaccess nous sera précieux.

Pour déplacer une page :

RedirectPermanent ancien.html http://www.domaine.tld/nouveau.html

Cette directive signale au navigateur que la page ancien.html a été renommée nouveau.html et renvoie l’entête correcte au navigateur pour signaler ce fait (entête 301 « déplacement permanent »). L’avantage de cette approche est que les robots d’indexation des différents moteurs apprendront que cette page a été déplacée et modifieront leur index pour refléter la nouvelle adresse. Dans le cas de Google, le PageRank [4] de l’ancienne page sera automatiquement transmis à la nouvelle page.

Pour déplacer un répertoire :

RedirectPermanent /ancien http://www.domaine.tld/nouveau/

Il est important de noter que dans le cas d’utilisation de la directive RedirectPermanent, la nouvelle adresse de page ou de répertoire doit être une URL complète.

Pour changer de nom de domaine :

RedirectPermanent / http://www.nouveaudomaine.tld/

Cette directive redirigera la racine de l’ancien site vers le nouveau domaine.

Note : Seuls les moteurs de recherche ajusteront leur index pour refléter la nouvelle adresse. N’oubliez pas de demander aux annuaires de modifier leurs liens vers vos pages.

Pour des redirections plus avancées, découvrez la suite de l’article : La réécriture d’URL

Notes

[1Avec le protocole ftp, il est impératif de transférer le fichier .htaccess en mode texte et non en mode binaire, de manière à obtenir les caractères de fin de ligne appropriés au système d’exploitation du serveur. De même, l’édition en local devra se faire en mode texte.

[2L’erreur 500 est une erreur interne au serveur, survenant le plus souvent lors de l’appel d’un module inexistant ou effectuant une opération illégale.

[3L’erreur 404, ou « page inexistante », est l’erreur la plus fréquente sur le web.

[4Indice de mesure de popularité d’une page utilisé par Google et noté sur une échelle de 0 à 10.

Discussion

30 discussions

  • Salut
    Je veux protéger l’accés à mon site hébergé sur phpnet.

    j’ai donc mis un htaccess et htpasswd dans le répertoire où j’ai installé spip.

    Pad de problème l’accès est effectivement protégé, mais lorsque qqu’un s’inscrit pour devenir rédacteur, l’inscription se fait normalement dans la base de données, mais il n’apparaît pas sous forme d’auteur dans spip, donc ne peut pas écrire d’article !!!
    Qqu’un sait-il pourquoi ???

    Répondre à ce message

  • Aurélien

    Hello !
    Je souhaite que les fichiers de mes répertoires type : « monsite.free.fr/fichiers_privés/ » ne soient pas listés par le navigateur, et donc que si cette adresse est tapée, l’htaccess rebascule vers la page index.html

    Et ça ne marche pas, je n’ai plus du tout accès au fichiers, et la redirection ne se fait pas(erreur 500).
    La ligne est la suivante :

    DirectoryIndex /index.html
    (index.html est placé sur la racine du site, le htaccess est dans le répertoire en question)
    Est-ce suffisant ? est-ce free qui bloque ce script ?

    Merci par avance !

    Répondre à ce message

  • Jacques Chatignoux

    Bonjour,
    J’ai bien placé dans un .htaccess les lignes ci-dessous indiquées sur le spikini.
    Une fois téléchargé le .htaccess à la racine du Spip rien ne se passe. Pas davantage si je le place dans le dossier spikini ?
    Je tente pourtant www.nomdedomaine/spikini

    et j’obtiens
    Warning : open_basedir restriction in effect. File is in wrong directory. in index.php on line 4

    Warning : SAFE MODE Restriction in effect. in index.php on line 4

    Warning : Failed opening ’ecrire/inc_version.php3’ for inclusion in index.php on line 4

    Fatal error : Call to unsupported or undefined function include_ecrire() in index.php on line 5

    Merci du coup de main


    Rewriteengine On

    ## feuilles de style
    Rewriterule ^/(wakka(.basic) ?.css)$ /spikini/$1 [L]

    ## spiperies
    # 1) la version patchee de spip_cookie, qui regle le cookie_path sur /
    Rewriterule /spip_cookie\.php3 ? /spikini$0 [QSA,L]
    # 2) les autres a la racine
    Rewritecond %REQUEST_URI !^/ecrire/
    Rewriterule /(spip_.*\.(css|php3 ?)|puce\.gif) $0 [QSA,L]

    ## passer ce qui reste a spikini
    Rewritecond %REQUEST_URI !^(/ecrire/|/IMG/)
    Rewriterule ^/([a-z0-9_]+)/(.*) /spikini/multi.php ?wname=$1&wiki=$2 [QSA,L]

    ## urls incompletes (sans /)
    Rewriterule ^/([a-z0-9_]+)$ /$1/ [R,L]

    Répondre à ce message

  • Bonjour,
    j’aimerais restraindre l’accès à un site, mais cette fois non pas par mot de passe, mais en fonction d’un site d’origine déterminé ; je m’explique : par exemple je souhaite que seuls les visiteurs venant de www.exemple.com puissent acceder au contenu de mon site.
    Est ce possible, et si oui, quelle serait la ligne de code ?

    Merci d’avance

    Pascal

    Répondre à ce message

  • 1

    J’utilise actuellement .htaccess pour protéger l’accès à une partie réservée de mon site. Mais aujourd’hui je voudrais que les utilisateurs puissent se signer directement dans ma page d’accueil (login, mot de passe) avec donc deux zones de champs. Je pensais mettre les infos user, password dans une base mysql (je voudrais leur donner la possibilité de changer leur mot de passe), comment est-ce que je peux faire ?
    merci

    • Dan (admin Webmaster Hub)

      Bonjour,

      Ce que tu veux faire suppose l’installation du module mod_auth_mysql, qui n’est pas generalement disponible en hébergement mutualisé.

      A moins que tu sois sur serveur dédié, c’est donc à ton hébergeur de te donner ces informations.

      Cordialement,

      Dan

    Répondre à ce message

  • 1

    Merci pour ce site super clair ! J’ai néanmoins besoin d’un complément d’information :

    En tapant dans la barre d’adresse

    http://www.monsite.com/.htaccess

    le texte de celui-ci s’affiche, indiquant du coup le chemin de ma liste de passwords (non cryptés car je suis sur Free :-( ).
    Comment interdire l’affichage du .htaccess ?

    • Dan Hetzel

      Salut Manu,

      C’est manifestement un problème de configuration propre à free, comme un fichier .htaccess ne devrait pas être listé.

      Normalement, dans le fichier de configuration apache, on interdit l’accès aux fichiers .htaccess et .htpasswd à l’aide des instructions suivantes :

      <Files ~ "^\.ht">
          Order allow,deny
          Deny from all
          Satisfy All
      </Files>

      Ces instructions font normalement partie intégrante du fichier httpd.conf auquel tu n’as pas accès.
      Tu peux tenter de mettre ces lignes en début de fichier .htaccess, et selon le paramétrage du « AllowOverride » ce sera pris en compte ou non...

      Cordialement,

      Dan

    Répondre à ce message

  • 1

    Bonjour
    pourriez-vous expliquer comment synchroniser les accès entre SPIP et le fichier de mot de passe .htpassword ?
    On m’a dit que cela était possible moyennant l’installation de libapache-auth-mysql, en forçant Apache à aller chercher l’authentification directement dans la base mysql de SPIP au lieu de la lire dans le fichier idoine...

    Répondre à ce message

  • 1

    Bonjour je viens de lire ton article qui a le mérite de débrousailler considérablement le sujet à mes yeux.

    Dans ton article je lis

    « Pour tous ceux qui n’ont pas d’accès au shell unix, plusieurs sites sur le Web vous permettent d’obtenir le mot de passe encrypté, par exemple : http://ovh.fr/cgi-bin/crypt.pl »

    je me rend sur cette URL et là on me demande une clé (deux lettres pour crypter le mot de passe. :-/ C’est quoi cette clef ? Deux lettres que je choisis au hasard ou faut-il les demander à mon hébergeur ? En gros je ne vois pas du tout ce que c’est que cette clef.

    D’autre part, donc il faut que je demande le chemin réel de la racine au rep de mon site sur le serveur de mon hébergeur pour pouvoir indiquer l’emplacement du fichier .htpasswd dans le fichier .htaccess
    Exact ?

    Merci en tout cas.

    • Bonjour Fred,

      La clé de 2 caractères permet de diversifier l’algorithme de cryptage, c’est ce qu’on appelle le ’salt’ (le sel) :- ;
      Tu peux choisir les caractères que tu veux, et n’as pas à les retenir.

      Pour le chemin d’accès, ton hébergeur doit te donner cette info. Ce sera de la forme ’home/tonlogin/www/...’ (un chemin absolu, commençant par / )

      Dan

    Répondre à ce message

  • 3

    Merci pour ces repèrs utiles... J’ai essayé pour changer le domaine : un RedirectPermanent d’un répertoire racine vers un autre. ça marche pour la page d’accueil et aussi pour les pages de ce répertoire, super, mais le probleme c’est que les paramétres des pages (par ex : ?id_article=23) ne suivent pas !!!

    Serait-ce qu’il faut utilsier des jokers ou wildcards ou regexp en plus dans la RedirectPermanent ? ou bien dans ce cas il faut passer par une rewrite rule plutôt qu’un RedirectPermanent ?

    • Pour info ! contrairement au redirect, ça marche avec une rewrite rule : autant le nom de fichier que les paramètres sont recopiés.

    • Bonjour,

      Désolé pour le délai mis à répondre... je terminais l’article mis en ligne (URL ci-dessous) ! ;-)

      Effectivement cela marche avec une RewriteRule, pour autant qu’on n’oublie pas de mettre le flag [QSA] (pour Query Strin Append)

      Dan

    • Le lien ne marche pas... je réessaie :-(

      L’algorithme du PageRank expliqué :
      http://immo.wildcroft.com/publication/article39.html

      Dan

    Répondre à ce message

  • 1

    Merci pour cette contrib claire et efficace... Je vais enfin pouvoir m’amuser avec des urls un peu plus plaosantes ;-)

    Répondre à ce message

Ajouter un commentaire

Avant de faire part d’un problème sur un plugin X, merci de lire ce qui suit :

  • Désactiver tous les plugins que vous ne voulez pas tester afin de vous assurer que le bug vient bien du plugin X. Cela vous évitera d’écrire sur le forum d’une contribution qui n’est finalement pas en cause.
  • Cherchez et notez les numéros de version de tout ce qui est en place au moment du test :
    • version de SPIP, en bas de la partie privée
    • version du plugin testé et des éventuels plugins nécessités
    • version de PHP (exec=info en partie privée)
    • version de MySQL / SQLite
  • Si votre problème concerne la partie publique de votre site, donnez une URL où le bug est visible, pour que les gens puissent voir par eux-mêmes.
  • En cas de page blanche, merci d’activer l’affichage des erreurs, et d’indiquer ensuite l’erreur qui apparaît.

Merci d’avance pour les personnes qui vous aideront !

Par ailleurs, n’oubliez pas que les contributeurs et contributrices ont une vie en dehors de SPIP.

Qui êtes-vous ?
[Se connecter]

Pour afficher votre trombine avec votre message, enregistrez-la d’abord sur gravatar.com (gratuit et indolore) et n’oubliez pas d’indiquer votre adresse e-mail ici.

Ajoutez votre commentaire ici

Ce champ accepte les raccourcis SPIP {{gras}} {italique} -*liste [texte->url] <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Ajouter un document

Suivre les commentaires : RSS 2.0 | Atom