SELFHTML actuel Articles spécialisés Configuration de serveurs
Michael Schröpl:
Contrôle d'accès avec fichier .htaccess
Michael Schröpl
.htaccess - Contrôle d'accès à des répertoires http
| SELFHTML actuel Articles spécialisés Configuration de serveurs |
|
|
Michael Schröpl: |
|
|
|
| | |
| Adresse électronique: |
 michael.schroepl@gmx.de
|
| Présence Internet: |
 http://www.schroepl.net/
|
Il s'agit ici d'un article traduit de l'allemand par la rédaction de SELFHTML actuel. Veuillez poser vos questions relatives à cet article uniquement à son auteur, prenant compte que celui-ci ne maîtrise peut-être pas la langue française!
 |
Chaque serveur WWW possède des fichiers de configuration centrale, dans lesquels le webmestre peut inscrire centralement propriétés, services et droits d'accès divers. Si cependant le nombre d'utilisateurs du serveur, lesquels peuvent avoir de différentes exigences concernant les documents qu'ils ont placés sur le serveur, est important, la maintenance d'une telle configuration centrale devient vite difficile.
Ici, le concept d'une configuration décentralisée avec des fichiers de configuration propres à l'utilisateur d'un serveur NCSA (et de tous les serveurs compatibles), s'avère être très utile: en sus de la configuration centrale, chaque utilisateur peut, en créant un fichier texte nommé .htaccess, influencer le comportement du serveur lors de l'accès à ses propres documents.
Dans un tel fichier, on peut par exemple:
directory browsing,D'autre part, le webmestre peut définir de manière détaillée dans sa configuration centrale quelles vont être les possibilités de configuration propre à l'utitlisateur, et à quels répertoires et leur arborescence celles-ci devront s'appliquer. Les commandes de ces fichiers .htaccess sont identiques à celles des fichiers de configuration centrale - le webmestre pourrait aussi bien définir globalement dans sa configuration centrale access.conf tout ce qu'un utilisateur peut préciser localement.
authType basic
# Procédé de protection (Apache 1.2 ne connaît que "basic")
authName Section_WEB_du_bureau_des_comptes
# Nom de la section autorisée
authUserFile /home/ms/acceshttp/utilisateurs.txt
# Fichier pour description utilisateur (ne pas placer parmi les documents!)
authGroupFile /home/ms/acceshttp/groupes.txt
# Fichier pour description groupes (ne pas placer parmi les documents!)
order deny,allow
# Dans ce cas particulier, les autorisations (allow) prévalent
# sur les interdictions (deny)...
# (order allow,deny provoquerait le contraire)
deny from all
# ... mais d'abord, on interdit tout
satisfy all
# seules l'adresse de l'ordinateur ET la reconnaissance de
# l'utilisateur autorisent l'accès!
allow from 153.46.90.
# seuls les ordinateurs de ce groupe d'adresses IP ont droit d'accès
require group developp
# seuls les utitlisateurs du groupe "developp" ont droit d'accès
require user chef secretai
# seuls le "chef" et sa secrétaire ont droit d'accès
|
# (Pour la démonstration, les noms ont été pris comme mot de passe - # ce qui n'est pas recommandé! - et codés crypt()-salt = "IN") chef:IN3WY1lATStaY secretai:INS9s.0QXFqyk dupont:IN8BH6lqySqBM durandt:INOvMHm1DH5yU baudoin:INJ7tGk1r7Un6 lampion:INqkuAWiV0xo2 |
# Liste des membres du/des groupe(s) défini(s) developp: chef dupont lampion |
L'accès aux documents d'un répertoire peut être réduit par son "propriétaire" à certains noms d'hôtes, à certaines adresses IP ou aux préfixes de ces deux catégories (donc parties d'adresses IP et de domaines!). Pour une société disposant d'un important réseau d'ordinateurs avec plusieurs réseaux dépendants ou des sous-domaines, ceci est très pratique: il est de la sorte possible d'organiser les accès selon les filiales, les sections, les bureaux, etc. en utilisant la structure du réseau.
Les utilisateurs autorisés d'accès à des documents déterminés ne sont pas obligés de donner explicitement leurs coordonnées d'accès (nom et mot de passe) - et donc ne se rendront peut-être même pas compte que ces documents sont interdits d'accès à d'autres utilisateurs.
Pour obtenir des contrôles plus stricts, avec lesquels les utilisateurs doivent donner explicitement leurs nom et mot de passe d'accès lors de chaque séance (le serveur garde en mémoire nom et mot de passe tout le temps que dure une "séance de visite"), il faut d'abord définir un secteur d'accès en attribuant un nom au répertoire en question.
Si un visiteur veut accéder aux documents d'un tel secteur, par exemple en donnant l'URL d'un répertoire situé dans le répertoire ainsi protégé, le serveur envoie au navigateur une demande d'authentification. Le navigateur présente au visiteur une boîte de dialogue comportant des champs de saisie pour le nom et le mot de passe. D'autre part, est indiqué également dans la boîte de dialogue le nom du secteur protégé, afin que le visiteur reconnaisse pour quelle raison on lui demande ses coordonnées d'accès. Si les entrées du visiteur sont correctes (selon les autorisations définies), il peut alors accéder au document. Dans le cas contraire, le serveur provoque une erreur HTTP 401 (authorisation required, autorisation requise).
À l'intérieur d'un secteur protégé, l'utilisateur d'un répertoire peut en autoriser ou en interdire l'accès à des visiteurs ou des groupes déterminés. La définition de ces identifications se fait dans des fichiers utilisateurs ou groupes: dans le fichier utilisateurs doivent être indiqués les noms utilisateur et les mots de passe codés (!!!) - avec le système UNIX crypt() - des différents utilisateurs autorisés, dans le fichier groupes sont indiquées les listes des utilisateurs des différents noms de groupes autorisés.
Il est également possible d'indiquer que soit la provenance d'un hôte déterminé, soit l'entrée de coordonnées du visiteur est suffisante pour l'autorisation, ou au contraire, que les deux conditions ensemble soient nécessaires à l'accès aux documents.
Exemple: l'utilisateur baudoin n'autorise l'accès aux documents de sa section développement qu'aux visiteurs ayant une adresse IP dans le segment 153.46.90.*
Si votre page d'accueil se trouve sur un serveur Apache (ou compatible) et si vous désirez utiliser .htaccess, vous n'aurez peut-être pas la possibilité de coder vous-même les mots de passe selon le procédé crypt. C'est pourquoi nous vous proposons d'utiliser le petit assistant suivant pour laisser coder vos mots de passe par crypt.
Pour des fins propres, le serveur Apache, gratuit et très répandu (que vous pouvez télécharger à l'adresse 
http://www.apache.org), est recommandé. Depuis 1998, il existe, en plus de la version pour UNIX, une version stable pour Windows 32.
Remarquez cependant que sous Windows, les mots de passe doivent être indiqués en clair, donc non codés, dans le fichier utilisateurs car Windows n'offre pas, au contraire d'UNIX, de programme crypt().
La version 1.3.6 du serveur WWW Apache contient un bogue qui empêche l'utitilisation de mots de passe sous Windows. Ce problème est résolu dans la version 1.3.9 (août 1999).
Directory Browsing:
Généralement, si un répertoire Web ne contient pas de fichier devant être affiché par défaut (index.htm, index.html, default.htm, etc.), le serveur génère à l'appel du répertoire par son adresse URL une page indiquant les documents ou éventuels sous-répertoires y étant contenus. C'est donc cette page que l'on peut personnaliser et faire afficher grâce à un fichier .htaccess.
Sources: Manuel Apache V1.3, core features
Modules: mod_access ou mod_auth.
Autres liens:
http://www.infres.enst.fr/~danzart/frames/htaccess.html - Fonctionnement de l'authentification avec .htaccess
|
|
| SELFHTML actuel Articles spécialisés Configuration de serveurs |
