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.