Merci @pfaffman
J’ai effectué quelques tests et je peux confirmer que cela ne fonctionne pas avec Drupal 7, qui utilise apparemment SHA-512 selon Drupal 7: Secure password storage by default at last | Jon Cave
Je créerai une PR si je parviens à en ajouter une compatible.
Rich
Bonjour 
J’ai migré une grande quantité de contenu de bbPress vers mon installation Discourse. Je peux voir tous les messages, les utilisateurs et autres éléments. Mais mes utilisateurs ne peuvent pas se connecter avec leurs « anciennes » données de mot de passe provenant de mon site WordPress. J’ai installé le plugin, il est répertorié dans la section des plugins de mon espace d’administration. J’ai coché toutes les cases disponibles.
Pourtant : personne ne peut se connecter !
Je ne sais pas non plus où appliquer le code fourni dans le fichier README du plugin :
user = User.find_by(username: 'user')
user.custom_fields['import_pass'] = '5f4dcc3b5aa765d61d8327deb882cf99'
user.save
Je ne sais pas non plus exactement ce que signifient les « hachages de mot de passe alternatifs » mentionnés dans le README.
@michaeld, pourriez-vous fournir plus de conseils sur l’utilisation du plugin ?
À ma connaissance, l’importateur bbPress prend en charge ce plugin, vous avez donc tout fait correctement et c’est tout ce qu’il y a à faire.
Oh mon Dieu, après quelques tests supplémentaires, il s’est avéré que cela a finalement fonctionné. Le problème venait d’un mot de passe modifié lors de mes tests 
Désolé ! Merci pour l’excellent plugin ! Cela m’a beaucoup facilité la vie !
Salut, je rencontre des problèmes pour que cela fonctionne. J’ai créé un champ personnalisé import_pass et installé le plugin. J’ai relancé le script d’importation sur ma base de données SMF, mais sans succès : personne ne peut se connecter par la suite. Sur le champ personnalisé, je ne vois qu’un « - » au lieu d’un hachage.
Comme d’autres utilisateurs l’ont déjà souligné, je ne suis pas sûr de quoi faire avec ceci :
user = User.find_by(username: 'user')
user.custom_fields['import_pass'] = '5f4dcc3b5aa765d61d8327deb882cf99'
user.save
Je vous remercie par avance pour tout conseil. Ce code doit-il être placé dans le fichier de script d’importation smf2.rb ou quoi que ce soit d’autre ?
Cela ne fonctionnera pas. Mais il n’est pas nécessaire d’installer le plugin pendant l’importation ni de créer un champ personnalisé manuellement. Cela devrait déjà être géré par le script SMF2. Donc, il y a autre chose qui ne va pas.
Le code est présent à titre d’exemple pour les auteurs de scripts. Il est déjà inclus dans le script SMF2.
Merci. C’est formidable. Vous voulez dire que si je supprime le champ personnalisé créé manuellement et que je laisse simplement le plugin activé, il devrait fonctionner de lui-même et récupérer les hachages de mot de passe au besoin.
Y a-t-il un journal que nous pouvons consulter pour voir pourquoi le plugin ne fait pas ce qu’il est censé faire ?
Le plugin se charge d’interpréter et d’utiliser les champs personnalisés définis par l’outil d’importation. Si les champs personnalisés sont vides ou absents, le problème ne vient pas du plugin, mais de l’outil d’importation.
Le plugin doit-il être installé avant ou après la migration ? Ou cela ne change-t-il rien ?
TL;DR : après.
Vous devez installer le plugin sur l’instance qui exécute réellement le forum migré.
Nous avons constaté des cas où le plugin causait des problèmes lorsqu’il était installé sur une instance exécutant le script de migration ; nous vous déconseillons donc de l’installer dans ce cas.
Bonjour,
Quelqu’un a-t-il déjà testé avec des hachages de mots de passe provenant d’Auth0 ?
Je ne peux pas simplement tester car l’exportation des hachages de mots de passe est un service payant réservé aux clients. Je voulais simplement savoir si quelqu’un a déjà essayé avant de me lancer moi-même dans cette voie.
Il semble que leurs mots de passe soient hachés avec bcrypt, avec 10 tours de sel.
Merci.
Bonjour, y a-t-il eu des changements concernant la prise en charge de Drupal 7 ?
Oups, question datant de 2 ans que j’ai manquée !
bcrypt devrait être pris en charge quel que soit le nombre de tours, tant que les tours sont encodés de la manière habituelle ($2a$10$...)
Non, ce code n’a pas été touché depuis plus de 3 ans.
Nous avons migré un forum vers Discourse il y a plusieurs années en utilisant le plugin migratepassword. Existe-t-il un moyen de vérifier combien de nos utilisateurs utilisent encore les hachages de mot de passe hérités de notre ancien forum ?
Techniquement, un utilisateur n’utilise pas le hachage de mot de passe hérité.
Lorsqu’un utilisateur se connecte pour la première fois après une migration et que le mot de passe ne correspond pas au mot de passe Discourse (qui sera initialement une chaîne aléatoire de caractères), le plugin effectue son travail.
import_pass en utilisant toutes les méthodes de hachage qu’il connaîtimport_pass.Ainsi, après quelques années, seuls les utilisateurs qui n’ont pas « utilisé » le mot de passe migré pour se connecter auront encore un champ personnalisé import_pass.
a) ils ne se sont jamais connectés (vous pouvez vérifier cela avec la date de dernière connexion)
b) ils n’ont pas utilisé le mot de passe migré mais se sont connectés via e-mail, une autre méthode d’authentification, ou ils ont réinitialisé leur mot de passe
Je viens de réaliser que la situation b peut introduire un problème de sécurité. Si un utilisateur ne se souvient pas de son mot de passe et le change, ou s’il utilise une autre méthode d’authentification, le hachage de mot de passe migré restera présent et pourra encore être utilisé à côté du nouveau mot de passe. Je viens de publier une mise à jour du plugin pour qu’il supprime le champ personnalisé import_pass à chaque connexion réussie.
Désormais, le champ personnalisé import_pass ne sera présent que pour les utilisateurs qui ne se sont jamais connectés.