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!
Cela dépend de la configuration du serveur Web.
Le concept de .htaccess signifie que le webmestre délègue à un utilisateur une partie de ses possibilités de contrôle. Chez les fournisseurs de masse d'hébergement de pages d'accueil, il est difficile d'attendre qu'ils soient prêts, serait-ce par crainte, à attribuer par erreur à un utilisateur des droits pour faire quelque chose qui pourrait paralyser leur entreprise et des milliers de pages d'accueil.
Le webmestre doit de toutes façons 
savoir ce qu'il fait - ou bien faire confiance à l'utilisateur. C'est la raison pour laquelle une possibilité telle que .htaccess ne sera probablement incluse que dans les lots d'espaces Web d'un certain prix - ce qui est dommage, car quand, en tant que webmestre, on a effectué les réglages une fois pour toutes, des milliers de visiteurs peuvent en profiter.
Étant donné que pour certains réglages de la configuration serveur, des fichiers .htaccess dans les répertoires parents doivent automatiquement être vérifiés, tout cela pourrait devenir également une question de performance pour des nombres d'accès vraiment élevés. Ici aussi le serveur pour la fourniture de masse est le candidat le plus probable pour ne pas proposer une telle possibilité.
Au cas où un fournisseur d'accès propose effectivement un tel service, il doit alors aussi mentionner lesquelles des nombreuses propriétés (features) de .htaccess il a activées.
Enfin, il faut encore veiller le cas échéant que le nom .htaccess est réglable dans la configuration du serveur Web. En cas de doute, demandez donc le nom du fichier à votre fournisseur d'accès.
Théoriquement la réponse est oui.
Pratiquement vela provoque des problèmes inexplicables (annonces d'erreurs internes du serveur) chez le serveur Web Apache 1.3, quand un fichier .htaccess est installé dans un répertoire approprié pour CGI.
Il est cependant possible de contourner le problème sans complications excessives. Au lieu de protéger directement le répertoire avec l'application CGI, il suffit également,
- de placer un formulaire d'entrée HTML pour cette application CGI dans un répertoire protégé par .htaccess (il ne s'agit pas nécessairement d'un répertoire CGI, là où .htaccess fonctionne donc sans problème) et de
- s'assurer que l'application CGI n'est appelée exclusivement qu'à partir de ce formulaire (car quelqu'un qui s'est déjà identifié avec succès à cet endroit, pourra manifestement réellement utiliser l'application CGI)
Le dernier point ne présente pas de difficulté majeure: Par le port CGI l'application CGI reçoit dans la variable d'environnement HTTP_REFERER l'URL de la page à partir de laquelle l'application CGI a été appelée. Celle-ci peut donc être vérifiée - Si par exemple l'utilisateur a entré directement l'URL de l'application CGI, alors cette tentative peut être reconnue directement par l'application CGI et refusée.
La question complète serait la suivante:
"Si l'utilisateur vient de IP xx.yy.zz.* (par exemple du réseau propre à l'entreprise), alors il doit lui être possible d'accèder sans autre question d'aucune sorte; mais s'il accède en venant d'une autre adresse IP, alors il doit montrer patte blanche avec son identification et son mot de passe qui figurent dans la liste d'utilisateurs définie dans .htaccess."
Dans l'article, le cas est décrit où seule la combinaison de l'adresse IP, de l'identification de l'utilisateur et de son mot de passe doivent permettre l'accès (satisfy=all - toutes les conditions doivent être remplies).
En alternative il y a aussi la possibilité satisfy=any - au moins l'une des conditions doit être remplie. Cela nous donne ensuite exactement le résultat souhaité.
Il ne le peut pas du tout. À ma connaissance il n'existe aucune fonction inverse pour crypt() (si elle existait, le fichier de mots de passe serait une mine d'or pour les pirates).
Il n'est pas nécessaire qu'il le puisse. Le serveur doit seulement pouvoir vérifier si le mot de passe donné lors de l'authentification correspond au mot de passe enregistré. Pour ce faire, il peut de la même façon crypter le mot de passe entré pour comparer ensuite s'il obtient le même résultat.
Partant de cette affirmation, on peut conclure à la sécurité du procédé de protection: Aussi longtemps qu'il n'y a pas d'autre moyen que deviner, un pirate éventuel devrait essayer tous les mots de passe d'une longueur allant jusqu'à 8 caractères, à savoir 2568 soit environ 1.8*1019 combinaisons (chaque tentative laissant une entrée dans le fichier de protocole du serveur Web ...).
Des mots de passe comprenant plus de 8 caractères sont autorisés mais ils sont tronqués par crypt().
Le cryptage effectué à l'aide de crypt() conduit à des résultats toutefois qui ne dépendent pas exclusivement du mot de passe entré mais aussi d'un salt transmis à la fonction et qui est une chaîne de caractères composée de deux caractères (on peut ainsi obtenir à nouveau 65536 possiblilités de cryptage différentes - on ne pas voir en particulier si deux mots de passe cryptés avec deux salts différents sont identiques! De cette façon, on peut utiliser le même mot de passe à différents endroits sans perdre pour autant le cas échéant l'intégralité des mécanismes de protection si un seul d'entre eux est découvert.)
Malgré tout le serveur Web sait comment il doit crypter le mot de passe mentionné: le salt
est à vrai dire une partie constitutive du mot de passe crypté à savoir les deux premiers caractères de celui-ci. (On peut donc au moins reconnaître que deux mots de passse ont été crées avec des salts différents.)
 |
Pas à ma connaissance. Le texte des questions ne peut pas être spécifié dans la configuration du serveur Web (ni dans .htaccess) et n'est manifestement pas du tout partie constitutive du dialogue d'authentification entre le serveur Web et le navigateur.
L'apparence du texte des questions dépend davantage du navigateur utilisé. Un petit échantillon, sans prétendre à l'exhaustivité:
| Ligne d'entête |
Texte des questions |
Navigateur |
| Username and Password Required |
Enter username for <realm> at <hostname> |
Netscape 3.0 Gold (anglais) |
| Nom d'utilisateur |
Entrez le nom d'utilisateur et le mot de passe pour <nom> à <nom de l'hôte> |
Netscape 6.2 (français) |
| Authentifizierung |
Der Zugriff auf diese Seite erfordert ein Kennwort. Ressource: <realm> |
Microsoft IE 2.0 (allemand) |
| Entrez votre nom d'utilisateur et votre mot de passe |
Site <URL>
Domaine: <nom> |
Microsoft IE 6.0 (français) |
| Authentification |
Le document est bloqué. Veuillez entrer un nom d'utilisateur et un mot de passe pour le débloquer. Message serveur: <nom> |
Opera 5.12 (français) |
Non seulement les textes mais même le contenu informatif de ceux-ci dépendent donc massivement du navigateur utilisé. En ce qui concerne la langue, cette conduite spécifique est pourtant fondée: l'utilisateur d'un navigateur configuré pour la langue de son pays reçoit les textes de questions sous une forme qu'il peut comprendre. Voilà donc une chose dont le webmestre d'un serveur n'a pas à s'occuper.
L'Explorer Internet propose dans la version 5.0 l'option supplémentaire de sauvegarder localement la combinaison entrée de l'identification de l'utilisateur et du mot de passe. À chaque nouvel accès à cette même adresse, l'identification de l'utilisateur (en clair) ainsi que le mot de passe (indiqué par un nombre d'étoiles correspondant à sa longueur) ayant été employés en dernier, sont alors déjà renseignés par défaut dans la boite de dialogue d'authentification.
C'est peut-être plus commode pour l'utilisateur - mais cela signifie bien sûr aussi qu'un intrus pourrait, le cas échéant, trouver cette information quelque part sur cet ordinateur local.
La commande de la configuration Apache (utilisée comme exemple) qui règle l'étendue des fonctions d'un fichier .htaccess s'appelle AllowOverride. Le webmestre peut mentionner une partie de son choix des mots-clés suivants. Chaque mot-clé active pour la totalité du groupe les droits à utiliser dans le fichier .htaccess.
Étant donné que la commande pour la définition des droits fait partie d'une arborescence URL, il est possible sans problème d'activer autant de droits .htaccess dans différents répertoires pour ses utilisateurs.
| AuthConfig |
- Définition d'une structure d'accréditation,
comme décrite dans l'article (définition de noms, de fichiers d'utilisateurs et de mots de passe ainsi que des conditions d'authentification). Les mécanismes désirés ne sont obtenus qu'en relation avec Limit.
|
| FileInfo |
- Définition personnelle de types MIME et de leurs représentations par des extensions de fichier,
- Utilisation sous conditions de variantes linguistiques de documents HTML,
- Définition de documents en réaction à des codes d'erreur http.
La propriété CGI serait bien entendu pratique justement en relation avec la définition de documents d'erreurs, parce que l'on pourrait faire établir un compte-rendu des accès correspondants par une application CGI ... mais à la place le fournisseur d'accès peut proposer`a l'utilisateur un extrait des fichiers de protocole centraux, ce aui lui évite l'attribution (dangereuse) de droits CGI.
|
| Indexes |
- Réglages fins pour une navigation intelligente dans l'arborescence (directory browsing), dans la mesure où elle est autorisée:
- icônes définissables soi-même pour des types de fichiers
- textes de description personnels pour les types MIME
- définition du nom du fichier index (index.html etc.)
- fichiers Include automatiques pour les lignes de tête et de pied pour la navigation dans l'arborescence
- liste de fichiers à ne pas afficher (expressions régulières!)
Avec des réglages appropriés il est possible de créer une fonction de navigation acceptable absolument sans documents HTML personnels, par la seule fonction de navigation dans l'arborescence du serveur Web et qui semblera cependant individuelle.
|
| Limit |
- Contrôle d'accès, comme décrit dans l'article (activation des commandes allow, deny et order).
Limit seul et sans AuthConfig
permet une restriction des accés à des répertoires au seul vu de structures d'accréditation prédéfinies par le webmestre, sans permettre par exemple la définition d'identifications utilisateur en propre.
|
| Options |
- XBitHack - on peut grâce à ceci créer une espèce de variante de SSI à programmer soi-même
- Options - grâce à ceci on peut fixer des options pour le comportement du répertoire à savoir:
- Indexes
- permet l'emploi ou la désactivation de la navigation dans l'arborescence
(sinon, c'est tout simplement le réglage central par défaut du serveur qui prévaut).
- ExecCGI - permet la définition de ses propres répertoires CGI.
- Includes - permet l'emploi ou la désactivation de Server Side Includes au sens large (y compris ExecCGI!).
- IncludesNoCGI- permet l'emploi ou la désactivation de Server Side Includes au sens strict (sans ExecCGI!).
- MultiViews - permet l'emploi ou la désactivation de documents dynamiques liés à la langue.
- SymLinks
- permet l'emploi de liens symboliques comme liens à des documents d'autres répertoires. Élégant au cas où l'on veut pointer sur des objets situés hors de l'arborescence URL (par exemple des fichiers de protocole du serveur Web), cependant vous soustrayez ainsi le cas échéant consciemment de l'option cacher de tels objets pour cette arborescence URL.
- SymLinksIfOwnerMatch - version limitée, ne permet les liens que sur des objets de la même identification utilisateur.
C'est ici le réglage auquel le webmestre doit vraiment faire attention; il doit plutôt d'abord définir les droits correspondants dans sa configuration centrale (IncludesNoCGI est en soi sans danger et très utile!).
Quand on permet à un utilisateur de fixer lui même ces options, il peut alors régler lui-même tout ce qui est dans cette liste! Ce qui est très regrettable car cela empêche l'activation de droits sans danger à tous les utilisateurs (comme par exemple si on veut ou non la navigation arborescente) et contraint le webmestre le cas échéant à définir cela lui-même dans sa configuration centrale de façon différente pour différents utilisateurs.
|
Le fournisseur d'accés doit savoir dans chaque cas ce qu'il fait - plus précisément il le sait, mieux il pourra juger lesquels des droits décentralisés auront quel effet sur son serveur.
Il est décrit dans la spécification CGI une variable d'environnement REMOTE_USER, qui doit sauvegarder l'identification-utilisateur d'une authentification du nom correspondant. Par cette variable, il est possible entre autres d'établir le protocole du nom d'un utilisateur. Si l'utilisateur n'a dû s'identifier nulle part pour accéder à l'URL de l'application CGI, le contenu de cette variable est bien entendu vide.
Le serveur Apache respecte cette spécification. Mais malheureusement l'expérience montre que tous les serveurs Web ne se tiennent pas de façon stricte à cette spécification CGI. Le serveur Web WebSite1.1 pour Windows32 appelle par exemple cette variable AUTH_USER!
Il n'y a qu'un moyen de s'en tirer dans le doute: installer un script CGI pour sortir et examiner la totalité des variables CGI ou bien demander le nom du serveur Web par la variable CGI SERVER_SOFTWARE pour connaître quelles variables d'environnement peuvent être questionnées ...
Si un utilisateur s'est identifié avec succés sur un site, alors son identité lui est conservée pour la durée de sa session pour autant qu'il ne la modifie pas sciemment.
Comment peut-on modifier son identité? En accédant à une URL du même site pour laquelle l'identité précédente n'a pas de droit d'accés. Dans ce cas, le dialogue d'authentification d'origine est relancé et l'utilisateur peut alors entrer une une autre identification avec le mot de passe qui lui est associé - dans la mesure où il en dispose. Dès lors, il perd alors son ancienne identité - s'il accède à nouveau à la première URL donc, il obtiendra à nouveau un dialogue d'authentification ...
| |
D'une manière générale: il porte le nom que le webmestre lui a donné dans la commande AccessFileName.
Peut-être n'est-il pas souhaitable que le nom d'un fichier aussi important commence par un point et qu'il ne soit donc même pas affiché dans certains listages de répertoires sur des serveurs UNIX quand par exemple on ne mentionne pas explicilement l'option -a pour la commande UNIX ls (comme le font certains clients FTP).
.htaccess est la valeur par défaut prédéfinie dans la configuration Apache.
© 2001-2005 
Informations
SELFHTML actuel 
