Projet

Général

Profil

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

Ajouté par Benjamin Renard il y a plus de 3 ans. Mis à jour il y a plus de 3 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
04 décembre 2020
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Non
Planning:
Non

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

Révision fd248ebb (diff)
Ajouté par Benjamin Renard il y a plus de 3 ans

Allow users to provide their email or username for password reset process (#49131)

Révision 1f2ea155 (diff)
Ajouté par Benjamin Renard il y a plus de 3 ans

Add A2_RESET_PASSWORD_ID_LABEL parameter (#49131)

Révision 9eb52640 (diff)
Ajouté par Benjamin Dauvergne il y a plus de 3 ans

restore password reset only for active users (#49131)

Bug introduced in commit from #48264

Révision f904f03a (diff)
Ajouté par Benjamin Dauvergne il y a plus de 3 ans

do not store username in password reset tokens (#49131)

Historique

#1

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)

#2

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

  • Statut changé de Nouveau à En cours
  • Assigné à mis à Benjamin Renard
#3

Mis à jour par Benjamin Renard il y a plus de 3 ans

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 !

#4

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 ? :)

#5

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

#6

Mis à jour par Benjamin Renard il y a plus de 3 ans

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.

#7

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 ?

#8

Mis à jour par Benjamin Renard il y a plus de 3 ans

Benjamin Dauvergne a écrit :

Tu as changé des choses au niveau des Token qui n'était pas dans le patch précédent, quelle est la raison ?

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 :
  • 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
#9

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.

#10

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)
#12

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
#13

Mis à jour par Benjamin Dauvergne il y a plus de 3 ans

  • Statut changé de En cours à Résolu (à déployer)
#14

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

Formats disponibles : Atom PDF