Authentification et BdD Drupal
Depuis sa version 7, le CMS Drupal enregistre les mots de passe des utilisateurs dans la table "users_field_data" de la BdD du site.
Cette table compte 15 champs parmi lesquels :
- uid (la clé primaire) ;
- name : le nom d'ouverture de session
- pass : le mot de passe n'apparait pas en clair dans la base de données. Depuis la V8, c'est le résultat d'une fonction de hachage qui apparait.
- mail :le courriel de l'utilisateur.
Il n'est donc pas possible de trouver un mot de passe perdu en consultant la base de données.
Pour résoudre ce problème, on ne peut que remplacer ce "hachage" par le hachage d'un nouveau mot de passe (par exemple "123456") par la fonction de hachage que Drupal utilise. Cette fonction de hachage utilise un paramètre (le sel ou salt) qui est définit de manière aléatoire à chaque création d'un mot de passe. En savoir plus sur le salage d'un mot de passe.
Le fichier "password-hash.sh" qui se trouve dans le dossier core/scripts de votre installation de drupal permet de générer un hashage conforme. C'est un script PHP qui prend comme paramètre une liste de "mots" à hacher et rend le hachage de chacun des "mots" de la liste. Ces "hachages" pourront remplacer dans le champ "pass" de la table "users_field_data" ceux des utilisateurs ayant perdu leur mot de passe.
Vous pouvez l'exécuter dans un terminal (DOS ou Linux suivant l'OS du serveur portant votre installation Drupal) par une des commandes
- php chemin/password-hash.sh new_pass
ou par exemple - usr/bin/php8.1-cli chemin/password-hash.sh new_pass
selon votre configuration. - la variable d'environnement PATH est à jour (sinon il faut ajouter le chemin d'accès ).
- chemin doit indiquer l'emplacement du fichier "password-hash.sh" dans votre installation ;
- new_pass est la suite de mots de passe à hacher.
L'image ci-dessous présente dans sa partie supérieure la règle d'utilisation du script et dans sa partie basse, un exemple de l'utilisation qui génère le hachage des valeurs "abcdef" et"123456"
Le compte d'uid = 0 est le compte de l' utilisateur "anonyme".
Le compte d'uid = 1 est le compte d'administrateur utilisé lors l'installation du site.
La table "user_user_picture"
Cette table liste la relation id "utilisateurs" et id "photographies"
- entity_id : l'id du compte utilisateur correspondant à la photo
- user_picture_target_id : l'id du fichier image de cette photo dans les tables file_managed..
La table "flood"
La table "flood" est illustrée ci-dessous. Elle liste les événements susceptibles de "paralyser" le site (comme les connexions échouées) pour par exemple. Dans cette table, figurent entre autres les champs
- event :
- user.failed_login_IP : l'adresse IP du poste à l'origine de l'événement ;
- user.failed_login_user : l' uid de l'utilisateur (cf : table user_data_field) à l'origine de l'événement
- identifier :
- l'adresse IP du poste à l'origine de l'événement
- l' uid de l'utilisateur - l'adresse IP du poste ( uid : cf. table user_data_field ) à l'origine de l'événement lorsque cet utilisateur est identifié dans la table
- l'heure de début (timestamp) et de fin (expiration) du blocage. Par défaut ce blocage dure 3600s
Pour débloquer le compte d 'uid = 38, avant l'expiration de la durée de blocage, il faudra effacer l' (les) enregistrement(s) correspondant dans la table flood par la requête :
delete FROM `flood` where `identifier` like "%38-%"