Development #49131
Permettre à un utilisateur d'utiliser son nom d'utilisateur ou son email pour déclencher la procédure de récupération de son mot de passe
0%
Description
C'est une demande d'un de nos clients dont les utilisateurs ont l'habitude d'utiliser leur nom d'utilisateur comme identifiant pour se connecter. Du coup, il se trompe systématiquement sur ce formulaire, malgré l'ajout d'un message personnalisé sous le champ...
Je pense avoir fais le tour des adaptations nécessaires et j'ai également repris les tests unitaires en conséquence.
Fichiers
Révisions associées
Add A2_RESET_PASSWORD_ID_LABEL parameter (#49131)
do not store username in password reset tokens (#49131)
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Il faut au minimum que le label (voir la fonctionnalité) restent comme actuellement, sur nos plateformes seul le mail est utilisé comme identifiant, il ne faut pas qu'on amène un changement perturbant à ce niveau.
1. Il faut un flag A2_USER_CAN_RESET_PASSWORD_WITH_USERNAME qui active tout ça (ou alors juste le changement de label, voir simplement rendre le label paramétrable comme le champ username du formulaire de login avec A2_USERNAME_LABEL)
2. Tu ne peux pas changer la signature du hook ni des évènements dans le journal, mais tu peux ajouter un nouvel argument username et laisser email=None dans ce cas, en gros ne rien changer pour l'existant mais ajouter quand la fonctionnalité est activé.
3. Il ne faut pas changer le nom du champ non plus, ça n'apporte pas grand chose et ça évitera toutes les modifications dans les tests.
(C'est vraiment important de décrire ce que tu veux faire avant, j'aurai pu te dire tout ça)
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Statut changé de Nouveau à En cours
- Assigné à mis à Benjamin Renard
Mis à jour par Benjamin Renard il y a plus de 3 ans
- Fichier 0001-Allow-users-to-provide-their-email-or-username-for-p.patch 0001-Allow-users-to-provide-their-email-or-username-for-p.patch ajouté
Benjamin Dauvergne a écrit :
Il faut au minimum que le label (voir la fonctionnalité) restent comme actuellement, sur nos plateformes seul le mail est utilisé comme identifiant, il ne faut pas qu'on amène un changement perturbant à ce niveau.
1. Il faut un flag A2_USER_CAN_RESET_PASSWORD_WITH_USERNAME qui active tout ça (ou alors juste le changement de label, voir simplement rendre le label paramétrable comme le champ username du formulaire de login avec A2_USERNAME_LABEL)
J'ai donc ajouté un paramètre A2_RESET_PASSWORD_ID_LABEL, ça me semble effectivement le plus simple.
2. Tu ne peux pas changer la signature du hook ni des évènements dans le journal, mais tu peux ajouter un nouvel argument username et laisser email=None dans ce cas, en gros ne rien changer pour l'existant mais ajouter quand la fonctionnalité est activée.
Ok, je vois. Dans le hook, on passe le mail + la liste des utilisateurs matchant, donc je pense pas que je peux ajouter le username (sans individualiser le hook pour chaque utilisateur). Pour le journal, c'est l'info qui a servi à déclencher la procédure qui est logguée (le mail ou le login), donc là aussi je laisse qu'une info et je garde le nom email.
3. Il ne faut pas changer le nom du champ non plus, ça n'apporte pas grand chose et ça évitera toutes les modifications dans les tests.
Ok, effectivement, ça simplifie grandement les changements.
(C'est vraiment important de décrire ce que tu veux faire avant, j'aurai pu te dire tout ça)
C'est ce que je voulais faire à la base, mais je voulais pas te faire perdre du temps et venir t'en parler sans avoir étudié le sujet un minimum. Au final, je me suis un peu laissé prendre par l'envie de voir truc fonctionner et du coup je suis aller au bout des choses. C'était une erreur ;)
Voilà un nouveau patch, beaucoup plus simple du coup !
Mis à jour par Benjamin Renard il y a plus de 3 ans
Benjamin Renard a écrit :
Voilà un nouveau patch, beaucoup plus simple du coup !
As-tu pu jeter un œil à ce nouveau patch ? Mon client a testé la fonctionnalité sur son environnement de preprod et il me demande à quel horizon on peut espérer voir ça intégrer upstream ? Une idée sur la question ? :)
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
1. il ne faut modifier aucun message, ni dans les logs ni dans le journal, la fonctionnalité sera invisible sauf si on configure A2_PASSWORD_ID_LABEL (ça devrait rendre inutile le point 1)
2. il faut retirer les traductions, elles sont faites au moment des releases
Mis à jour par Benjamin Renard il y a plus de 3 ans
- Fichier 0002-Add-A2_RESET_PASSWORD_ID_LABEL-parameter.patch 0002-Add-A2_RESET_PASSWORD_ID_LABEL-parameter.patch ajouté
- Fichier 0001-Allow-users-to-provide-their-email-or-username-for-p.patch 0001-Allow-users-to-provide-their-email-or-username-for-p.patch ajouté
Benjamin Dauvergne a écrit :
1. il ne faut modifier aucun message, ni dans les logs ni dans le journal, la fonctionnalité sera invisible sauf si on configure A2_PASSWORD_ID_LABEL (ça devrait rendre inutile le point 1)
Je ne comprends pas vraiment quelle est la finalité que tu recherches, car si j'ai ajusté ces libellés c'est pour coller à la réalité fonctionnelle de l'outil : techniquement, même sans ajuster le libellé du champ, l'utilisateur pourra renseigner son nom d'utilisateur pour lancer la procédure et par conséquence, dans ce cas, les libellés qui suivent ne seront pas forcément adaptés. Quand bien même, les patchs ci-joints devraient correspondre à ce que tu m'as demandé.
2. il faut retirer les traductions, elles sont faites au moment des releases
OK, normalement, il n'y en aura de toutes manières plus aucune.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
Benjamin Renard a écrit :
Je ne comprends pas vraiment quelle est la finalité que tu recherches, car si j'ai ajusté ces libellés c'est pour coller à la réalité fonctionnelle de l'outil : techniquement, même sans ajuster le libellé du champ, l'utilisateur pourra renseigner son nom d'utilisateur pour lancer la procédure et par conséquence, dans ce cas, les libellés qui suivent ne seront pas forcément adaptés. Quand bien même, les patchs ci-joints devraient correspondre à ce que tu m'as demandé.
Modifier le label par défaut va nous obliger à définir le setting A2_PASSWORD_ID_LABEL sur toutes nos productions pour ne pas avoir de changement visible. Que la fonctionnalité existe ne me dérange pas tant qu'elle est invisible pour nous (déjà à cause du label et ensuite parce que les utilisateurs dans nos usages n'ont pas de username) sinon ça va perturber nos clients. Ça vaut aussi pour les logs (en plus ça n'apporte pas grand chose de préciser email or username dans le log, on le voit bien).
--
Tu as changé des choses au niveau des Token qui n'était pas dans le patch précédent, quelle est la raison ?
Mis à jour par Benjamin Renard il y a plus de 3 ans
Benjamin Dauvergne a écrit :
Au niveau du token, j'ai simplement ajouté un champ username dans le contenu pour y stocker le nom d'utilisateur et j'ai fait en sorte que ces informations ne soient plus issues de ce qu'a saisi l'utilisateur dans le formulaire, mais qu'elles soient issues de ce qu'on connait de lui dans la DB. Cela va le sens de ce que tu m'as proposé dans ton point 2 et ça permet :Tu as changé des choses au niveau des Token qui n'était pas dans le patch précédent, quelle est la raison ?
- de faire en sorte que le champ mail du token soit toujours un mail
- de faire en sorte que la fonctionnalité derrière ce token soit aussi bien fonctionnelle lorsque l'utilisateur saisi son mail ou son username, quand bien même il passerait de l'un à l'autre entre ces différentes tentatives
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Statut changé de En cours à Solution validée
Benjamin Renard a écrit :
- de faire en sorte que le champ mail du token soit toujours un mail
- de faire en sorte que la fonctionnalité derrière ce token soit aussi bien fonctionnelle lorsque l'utilisateur saisi son mail ou son username, quand bien même il passerait de l'un à l'autre entre ces différentes tentatives
Ok, je vais intégrer ça.
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 9eb5264024a0ded1db09c4e45676bbabff708ef6 Author: Benjamin Dauvergne <bdauvergne@entrouvert.com> Date: Fri Dec 18 07:39:53 2020 +0100 restore password reset only for active users (#49131) Bug introduced in commit from #48264 commit 1f2ea15580d3b4918cdfc3146d0a6f1c29ef4232 Author: Benjamin Renard <brenard@easter-eggs.com> Date: Thu Dec 17 11:32:06 2020 +0100 Add A2_RESET_PASSWORD_ID_LABEL parameter (#49131) commit fd248ebb89d6d8c83362612e2ecd912242fdfb29 Author: Benjamin Renard <brenard@easter-eggs.com> Date: Thu Dec 17 11:31:43 2020 +0100 Allow users to provide their email or username for password reset process (#49131)
Mis à jour par Frédéric Péters il y a plus de 3 ans
Ça a pété jenkins (https://jenkins.entrouvert.org/job/authentic/1719/)
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Statut changé de Résolu (à déployer) à En cours
- Assigné à changé de Benjamin Renard à Benjamin Dauvergne
Mis à jour par Benjamin Dauvergne il y a plus de 3 ans
- Statut changé de En cours à Résolu (à déployer)
Mis à jour par Frédéric Péters il y a plus de 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
Allow users to provide their email or username for password reset process (#49131)