Authentification et BdD Drupal

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.  
 

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" 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

1. 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
2. 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
3. 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-%"