Ce module permet d'utiliser l'authentification basique HTTP pour
restreindre l'accès en recherchant les utilisateurs dans les
fournisseurs d'authentification spécifiés. Il est en général
combiné avec au moins un module d'authentification comme
La directive file
est implémenté par le module
Les fournisseurs sont sollicités dans l'ordre jusqu'à ce que l'un d'entre eux trouve une correspondance pour le nom d'utilisateur de la requête ; alors, ce dernier fournisseur sera le seul à vérifier le mot de passe. Un échec dans la vérification du mot de passe n'entraîne pas le passage du contrôle au fournisseur suivant.
Les différents fournisseurs disponibles sont implémentés par les
modules
Normalement, chaque module d'autorisation énuméré dans la
directive Off
permet de confier l'autorisation et
l'authentification à d'autres modules non basés sur les fournisseurs
si aucun identifiant utilisateur ou aucune
règle ne correspondent à l'identifiant utilisateur
spécifié. Ceci ne peut s'avérer nécessaire que lorsque
Les nom d'utilisateur et mot de passe spécifiés sont rassemblés dans un en-tête d'autorisation qui est transmis au serveur ou au service sous-jacent au serveur. Ces nom d'utilisateur et mot de passe sont interprétés par l'interpréteur d'expression, ce qui permet de les définir en fonction de paramètres de la requête.
Si aucun mot de passe n'est spécifié, la valeur par défaut "password" sera utilisée. Pour désactiver l'authentification de base simulée pour un espace d'URL, définissez AuthBasicFake à "off".
Dans l'exemple suivant, un nom d'utilisateur et un mot de passe prédéfinis sont transmis à un serveur d'arrière-plan :
Dans l'exemple suivant, l'adresse email extraite d'un certificat
client est transmise au serveur, étendant par là-même la
fonctionnalité de l'option FakeBasicAuth de la directive
Pour compléter l'exemple précédent, il est possible de générer la valeur du mot de passe en procédant à un hashage de l'adresse email à partir d'un mot d'une passphrase initial fixée, puis de transmettre le résultat obtenu au serveur d'arrière-plan. Ceci peut s'avérer utile pour donner accès à des serveurs anciens qui ne supportent pas les certificats clients.
Normalement, lorsqu'on utilise l'authentification basique, les
fournisseurs spécifiés via la directive
Lorsqu'on utilise l'authentification de type Digest, les
fournisseurs spécifiés par la directive
A cause de la différence entre les méthodes de stockage des données des authentifications de type basique et digest, le passage d'une méthode d'authentification de type digest à une méthode d'authentification de type basique requiert l'attribution de nouveaux mots de passe à chaque utilisateur, car leur mots de passe existant ne peut pas être extrait à partir du schéma de stockage utilisé par les fournisseurs d'authentification de type digest.
Si la directive MD5
, le mot de passe d'un
utilisateur dans le cas de l'authentification basique sera vérifié
en utilisant le même format de chiffrement que dans le cas de
l'authentification de type digest. Tout d'abord, une chaîne
comportant le nom d'utilisateur, le domaine de protection (realm) et
le mot de passe est générée sous forme de condensé (hash) en
utilisant l'algorithme MD5 ; puis le nom d'utilisateur et cette
chaîne chiffrée sont transmis aux fournisseurs spécifiés via la
directive Digest
et si l'authentification de type
Digest était utilisée.
Grâce à cette directive, un site peut basculer d'une authentification de type digest à basique sans devoir changer les mots de passe des utilisateurs.
MD5
. L'utilisation d'un autre
fournisseur provoquera un message d'erreur et le client se verra
refuser l'accès.