Changer l'e-mail d'un utilisateur

Contribuer Bug
1

Je suis un peu confus quant au processus lorsque qu’un administrateur modifie l’adresse e-mail d’un utilisateur.

Certaines choses m’échappent simplement, et il y a un bug (c’est pourquoi je poste ceci dans Contribute > Bug et non dans Support).

  • Selon cette pull request, le processus devrait fonctionner ainsi :

Lorsqu’un administrateur modifie l’adresse e-mail d’un utilisateur depuis la page de préférences de cet utilisateur :

  • L’utilisateur ne recevra pas d’e-mail pour confirmer le changement d’adresse. Il recevra un e-mail de réinitialisation de mot de passe afin qu’il puisse définir le mot de passe de son compte à la nouvelle adresse.
  • L’utilisateur recevra toujours un e-mail à son ancienne adresse pour l’informer du changement.

#1 Je ne comprends pas pourquoi un e-mail de réinitialisation de mot de passe est envoyé (« afin qu’il puisse définir le mot de passe de son compte »). Ils n’ont pas besoin de changer leur mot de passe ? De plus, l’expérience utilisateur est confuse : l’utilisateur ne s’attend pas à recevoir un e-mail de réinitialisation de mot de passe, et il n’y a aucun texte explicatif ; il est simplement indiqué « Quelqu’un a demandé la réinitialisation de votre mot de passe sur [nom du forum] ».

#2 Cet e-mail de réinitialisation de mot de passe est envoyé à l’adresse ancienne au lieu de la nouvelle adresse e-mail.

Même si l’adresse e-mail de l’utilisateur est mise à jour dans update_user_email à la ligne 46, l’objet @user n’est pas rechargé et contient toujours l’ancienne adresse e-mail.

#3 Si l’administrateur est l’utilisateur agissant, et que l’utilisateur concerné n’est pas membre du personnel, aucun e-mail de confirmation n’est envoyé conformément à la spécification ci-dessus. Néanmoins, après avoir modifié l’adresse e-mail, l’administrateur reçoit le message de succès suivant : « Nous avons envoyé un e-mail à cette adresse. Veuillez suivre les instructions de confirmation ».

#4 Pourquoi l’utilisateur n’a-t-il pas besoin de confirmer sa nouvelle adresse e-mail ? La pull request fait référence à ce sujet, mais il semble que de nombreux messages y manquent. Toutefois, le sujet mentionne toujours : « Pour un utilisateur normal, la seule adresse e-mail qui doit être vérifiée est la NOUVELLE adresse e-mail ». EDIT : oh, attendez, voir #6 / #7.

#5 Ce processus, où un administrateur modifie l’adresse e-mail d’un utilisateur, est généralement utilisé lorsque l’ancienne adresse n’est plus accessible (je suppose ?). Pourquoi un e-mail de notification est-il toujours envoyé à l’ancienne adresse ?

#6 Lorsque cet utilisateur tente de se connecter, une fenêtre contextuelle s’affiche :

Vous ne pouvez pas encore vous connecter. Nous vous avons précédemment envoyé un e-mail d’activation à l’ancienne adresse e-mail. Veuillez suivre les instructions contenues dans cet e-mail pour activer votre compte.

  • aucun tel e-mail n’a été envoyé
  • l’ancienne adresse e-mail est mentionnée

Le fait d’appuyer sur le bouton « Renvoyer » indique :

Nous vous avons envoyé un autre e-mail d’activation à la nouvelle adresse e-mail. Cela peut prendre quelques minutes avant qu’il n’arrive ; assurez-vous de vérifier votre dossier de spams.

#7 Cet e-mail d’activation arrive effectivement à la nouvelle adresse e-mail et porte le titre « confirmer votre nouveau compte » (et non « confirmer votre nouvelle adresse e-mail »).

Ne devrait-ce pas être simplement cela :

Un e-mail est envoyé à la nouvelle adresse e-mail, indiquant : « Votre adresse e-mail a été modifiée par [nom de l’administrateur]. Veuillez cliquer sur le lien suivant pour confirmer [lien]. »

Édition : #8 L’adresse e-mail peut être modifiée par un administrateur depuis le profil public de l’utilisateur (/u/username), mais pas depuis la page d’administration dédiée à cet utilisateur (/admin/users/id/username). Cela est contre-intuitif.

10 « J'aime »
2

Peut-on reproduire ce problème @tshenry ? Y a-t-il eu une régression ici ?

2 « J'aime »
4

Je vais d’abord décrire le flux actuel tel que je le vois se dérouler (la plupart, sinon la totalité, de ces éléments correspondent à ce que @RGJ a décrit) :

  1. Un administrateur accède aux préférences d’un utilisateur non membre du personnel et modifie son adresse e-mail :

    Screen Shot 2020-09-24 at 4.16.04 PM
    Screen Shot 2020-09-24 at 4.16.04 PM1758×590 35.2 KB

    Une fois soumis, l’administrateur voit le message suivant :

    Nous avons envoyé un e-mail à cette adresse. Veuillez suivre les instructions de confirmation.

  2. Le message ci-dessus ne semble pas exact, car DEUX e-mails sont envoyés à l’adresse e-mail ancienne :

    [Démo] Votre adresse e-mail a été modifiée

    Il s’agit d’un message automatique pour vous informer que votre adresse e-mail pour
    Démo a été modifiée. Si cela a été fait par erreur, veuillez contacter
    un administrateur du site.

    Votre adresse e-mail a été modifiée en :

    new@email.com

    [Démo] Réinitialisation du mot de passe

    Quelqu’un a demandé de réinitialiser votre mot de passe sur Démo.

    Si ce n’était pas vous, vous pouvez ignorer cet e-mail en toute sécurité.

    Cliquez sur le lien suivant pour choisir un nouveau mot de passe :
    https://example.discourse.site/u/password-reset/74d53d7d2cf20dsbc360614844c653s2

  3. J’ai testé trois scénarios distincts à partir de ce point. Chaque puce représente un scénario :

    • L’utilisateur a accès à l’ancienne adresse e-mail et suit le lien de réinitialisation du mot de passe. Après avoir mis à jour son mot de passe, il est connecté. À partir de là, il peut se connecter avec son nom d’utilisateur ou l’adresse e-mail ancienne. La nouvelle adresse e-mail ne semble pas être en vigueur à ce stade.

    • L’utilisateur tente de se connecter avec son nom d’utilisateur ou l’adresse e-mail nouvelle et reçoit ceci :

      Screen Shot 2020-09-24 at 4.38.01 PM
      Screen Shot 2020-09-24 at 4.38.01 PM1418×394 35.5 KB

      Option 1 : Cliquer sur « Renvoyer » affiche le message suivant (notez qu’il mentionne cette fois l’adresse e-mail nouvelle) :

      Screen Shot 2020-09-24 at 4.59.42 PM
      Screen Shot 2020-09-24 at 4.59.42 PM1418×390 27.8 KB

      Un e-mail est effectivement envoyé à l’adresse e-mail nouvelle :

      [Démo] Confirmez votre nouveau compte

      Bienvenue sur Démo !

      Cliquez sur le lien suivant pour confirmer et activer votre nouveau compte :
      https://example.discourse.site/u/activate-account/74d53d7d2cf20dsbc360614844c653s2

      Si le lien ci-dessus n’est pas cliquable, essayez de le copier et de le coller dans la barre d’adresse de votre navigateur web.

      En suivant le lien, on passe par certaines pages pour l’activation d’un nouveau compte. À la fin, l’utilisateur se connecte avec succès. À partir de ce moment, l’utilisateur peut se connecter avec son nom d’utilisateur ou l’adresse e-mail ancienne. La nouvelle adresse e-mail ne semble pas être en vigueur à ce stade.

      Option 2 : Cliquer sur le bouton « Modifier l’adresse e-mail » affiche ce qui suit. Le bouton « Mettre à jour l’adresse e-mail » est désactivé lorsque l’adresse e-mail nouvelle est dans le champ de texte, ce qui suggère que la nouvelle adresse e-mail est déjà active (mais cela ne semble pas être le cas).

      Screen Shot 2020-09-24 at 5.17.31 PM
      Screen Shot 2020-09-24 at 5.17.31 PM938×492 27.2 KB

    • L’utilisateur initie une réinitialisation du mot de passe. L’e-mail est envoyé à l’adresse e-mail nouvelle et l’utilisateur peut se connecter via le lien. Comme dans les autres scénarios, l’utilisateur peut se connecter avec son nom d’utilisateur ou l’adresse e-mail ancienne. La nouvelle adresse e-mail ne semble pas être en vigueur à ce stade.

Donc, nous reproduisons clairement ces problèmes ici. C’est difficile à expliquer clairement, mais j’espère qu’entre le message initial et cette description, cela deviendra plus clair. Il y a certainement des éléments qui doivent être corrigés.

@martin Je sais que tu as déjà travaillé sur cette partie du cœur du système. Pourrais-tu donner ton avis ici quand tu auras un moment ?

9 « J'aime »
5

Pourquoi cela aurait-il régressé ? :thinking:

edit : Je peux également confirmer que cela a régressé. Lors de la modification de l’e-mail d’un utilisateur standard, la confirmation et autres sont envoyées à l’ANCIEN e-mail. Ce n’est pas ainsi que cela fonctionnait auparavant..

4 « J'aime »
6

Ce sentiment de familiarité inconfortable quand on lit la description du pull request cité et qu’on réalise que c’est soi le coupable…

Merci pour les instructions détaillées @tshenry et @RGJ, je vais mettre cela en haut de ma liste à corriger cette semaine.

4 « J'aime »
7

Bon, j’ai maintenant compris le problème. J’ai consulté l’ancien sujet sur les commentaires supprimés pour retrouver l’historique. J’ai retrouvé cela de la part de @sam, dont je me souviens maintenant :

La réinitialisation de l’adresse e-mail par l’administrateur est très différente ; il s’agit en réalité d’une réinitialisation de l’adresse e-mail et du mot de passe par l’administrateur. En effet, si l’utilisateur avait accès au compte, il pourrait tout faire lui-même via le service autonome.

Donc, nous disons que, puisque c’est l’administrateur qui modifie l’adresse e-mail, un e-mail de réinitialisation du mot de passe doit être envoyé. En effet, si l’utilisateur avait accès à l’ancienne adresse e-mail, il pourrait simplement… se connecter et le faire lui-même ? Mais l’e-mail de réinitialisation du mot de passe sert également de confirmation. Sans terminer le processus de réinitialisation du mot de passe (ce qui est actuellement impossible car l’e-mail est envoyé à l’ancienne adresse), la nouvelle adresse e-mail n’est pas « confirmée », ce qui déclenche l’apparition de cette fenêtre modale :

image
image1124×292 28.1 KB

Le problème où l’e-mail de réinitialisation du mot de passe est envoyé à l’ancienne adresse est facilement résolu, et nous parviendrons au moins à un état où le processus de réinitialisation peut être suivi :

De plus, comme l’e-mail de réinitialisation du mot de passe est actuellement envoyé à l’ancienne adresse, lorsqu’il est confirmé, cela confirme la mauvaise adresse et remet l’adresse e-mail de l’utilisateur à l’ancienne.

Je vais modifier le message destiné à l’administrateur qui modifie l’adresse e-mail afin de lui faire clairement comprendre que l’utilisateur doit cliquer sur le lien dans la nouvelle adresse e-mail et modifier son mot de passe pour que la modification prenne pleinement effet (et corriger également le problème de la mauvaise adresse e-mail).

4 « J'aime »
8

Attends. Je ne comprends pas cela.

Il y a une différence entre le fait qu’un utilisateur puisse accéder à l’ancienne adresse e-mail et le fait qu’un utilisateur doive réinitialiser son mot de passe pour son compte Discourse. Le premier n’implique absolument pas le second ; ce sont des situations totalement différentes.

Un grand nombre de modifications d’adresse e-mail par un administrateur sont également dues au fait que l’utilisateur ne sait pas comment le faire, ou parce que l’administrateur doit temporairement lever la restriction email_editable = false.

Je trouve très confus qu’une réinitialisation de mot de passe serve également de confirmation d’adresse e-mail. Personnellement, je ne répondrais même pas à cet e-mail de réinitialisation du mot de passe puisque je ne l’ai pas demandé, et je ne réaliserais pas qu’il s’agit d’une étape de confirmation nécessaire (et je pense que ce n’est pas le cas ; un simple e-mail de confirmation ordinaire suffirait ?)

4 « J'aime »
9

Cela pourrait être lié :

Lorsqu’un de mes utilisateurs du forum tente de réinitialiser son mot de passe aujourd’hui (avec la dernière version de Discourse disponible ce matin), il reçoit l’e-mail, mais obtient ensuite une erreur en suivant le lien contenu dans l’e-mail :

Capture d'écran du 28 septembre 2020 à 9 h 41 min 04 s
Capture d'écran du 28 septembre 2020 à 9 h 41 min 04 s868×696 46.6 KB

Il rencontre cette erreur sur plusieurs navigateurs et n’utilise pas de bloqueur de publicités.

Lorsque je me rends sur la page des préférences de son compte et que je clique sur « Envoyer un e-mail de réinitialisation du mot de passe », j’obtiens également un message d’erreur :

Capture d'écran du 28 septembre 2020 à 9 h 44 min 10 s
Capture d'écran du 28 septembre 2020 à 9 h 44 min 10 s630×336 12.4 KB

Avant d’afficher « (erreur) » à côté du bouton, il indique brièvement « (envoi de l’e-mail)) ». Il semble cependant qu’aucun e-mail n’ait été envoyé. Je peux confirmer que les autres e-mails du forum sont envoyés normalement aujourd’hui.

Cette fonctionnalité fonctionnait parfaitement auparavant… elle semble avoir cessé de fonctionner à un moment donné au cours de la semaine dernière.

10

Vérifiez les journaux d’erreurs de Discourse dans le navigateur web lorsque vous êtes connecté en tant qu’administrateur ; un rapport d’erreur plus détaillé devrait s’y trouver.

11

Voici l’entrée d’erreur :

398 Exception de tâche : La source de copie spécifiée est plus grande que la taille maximale autorisée pour une source de copie : 5368709120

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/raise_response_errors.rb:15:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:22:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/dualstack.rb:26:in `call'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/plugins/accelerate.rb:35:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:20:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/idempotency_token.rb:17:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/param_converter.rb:24:in `call'

aws-sdk-core-3.99.1/lib/aws-sdk-core/plugins/response_paging.rb:10:in `call'

aws-sdk-core-3.99.1/lib/seahorse/client/plugins/response_target.rb:23:in `call'

aws-sdk-core-3.99.1/lib/seahorse/client/request.rb:70:in `send_request'

aws-sdk-s3-1.66.0/lib/aws-sdk-s3/client.rb:1108:in `copy_object'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:61:in `block in vacate_legacy_prefix'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `each'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `vacate_legacy_prefix'

/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff'

/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute'

/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'

rails_multisite-2.5.0/lib/rails_multisite/connection_management.rb:76:in `with_connection'

/var/www/discourse/app/jobs/base.rb:221:in `block in perform'

/var/www/discourse/app/jobs/base.rb:217:in `each'

/var/www/discourse/app/jobs/base.rb:217:in `perform'

sidekiq-6.1.2/lib/sidekiq/processor.rb:196:in `execute_job'

sidekiq-6.1.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'

/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'

sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'

sidekiq-6.1.2/lib/sidekiq/processor.rb:163:in `block in process'

sidekiq-6.1.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:111:in `local'

sidekiq-6.1.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq.rb:38:in `block in <module:Sidekiq>'

sidekiq-6.1.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/processor.rb:257:in `stats'

sidekiq-6.1.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:13:in `call'

sidekiq-6.1.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'

sidekiq-6.1.2/lib/sidekiq/job_retry.rb:78:in `global'

sidekiq-6.1.2/lib/sidekiq/processor.rb:124:in `block in dispatch'

sidekiq-6.1.2/lib/sidekiq/logger.rb:10:in `with'

sidekiq-6.1.2/lib/sidekiq/job_logger.rb:33:in `prepare'

sidekiq-6.1.2/lib/sidekiq/processor.rb:123:in `dispatch'

sidekiq-6.1.2/lib/sidekiq/processor.rb:162:in `process'

sidekiq-6.1.2/lib/sidekiq/processor.rb:78:in `process_one'

sidekiq-6.1.2/lib/sidekiq/processor.rb:68:in `run'

sidekiq-6.1.2/lib/sidekiq/util.rb:15:in `watchdog'

sidekiq-6.1.2/lib/sidekiq/util.rb:24:in `block in safe_thread'
1 « J'aime »
12

Non, cela n’a absolument aucun rapport. Essayez d’effacer les journaux et de forcer la survenue de cette erreur, puis vérifiez à nouveau les journaux.

13

Ensuite, les journaux restent vides après la survenue de l’erreur.

14

Je comprends votre point de vue ; pour moi, l’idée d’utiliser la réinitialisation de mot de passe comme confirmation m’a trompé hier. Je pense que cela pourrait être une option secondaire pour l’administrateur lors de la modification de l’adresse e-mail d’un utilisateur, avec une case à cocher indiquant « Réinitialiser également le mot de passe de l’utilisateur ». Je vais fusionner la PR que j’ai préparée pour une correction telle quelle, car le processus est actuellement totalement cassé.

J’aimerais que @sam donne son avis sur un nouveau processus/flux, car Sam avait initialement expliqué la logique derrière le flux de réinitialisation de mot de passe :

  1. L’administrateur modifie l’adresse e-mail de l’utilisateur. Il a la possibilité de réinitialiser son mot de passe en même temps.
  2. L’utilisateur reçoit un e-mail à sa nouvelle adresse demandant confirmation du changement d’adresse e-mail.
    • S’il répond Oui, l’adresse e-mail est modifiée. Nous envoyons un e-mail à l’ancienne adresse indiquant que l’adresse e-mail a été changée.
    • S’il répond Non, rien n’est fait.
  3. Si l’administrateur avait spécifié qu’il souhaitait une réinitialisation à l’étape 1, alors dès que l’utilisateur confirme le changement d’adresse e-mail, il reçoit un e-mail de réinitialisation de mot de passe à la nouvelle adresse.

Je pense que cela serait beaucoup plus clair, et la réinitialisation du mot de passe n’aurait rien à voir avec la confirmation du changement d’adresse e-mail.

2 « J'aime »
15

Oui, je ne vois pas pourquoi ces deux éléments seraient liés du tout ?

1 « J'aime »
16

Je vois une belle nouvelle commit fusionnée dont les gens seront heureux :smiley:

3 « J'aime »
17

Merci, cela va simplement fusionner une correction pour l’état « complètement cassé » des choses. Un autre PR suivra !

Cela a été fait ainsi suite à des discussions dans le sujet précédent avec Sam. Je vais procéder avec le nouveau processus pour lever le voile de confusion et supprimer le lien entre ces éléments sans rapport.

4 « J'aime »
18

Je viens de fusionner cette PR qui effectue les actions suivantes :

  • Modifie le flux de changement d’e-mail pour les utilisateurs dans l’administration afin que l’utilisateur reçoive un e-mail pour confirmer le changement
  • Nous enregistrons désormais qui a demandé le changement d’e-mail
  • Si la demande émane d’un administrateur et non de l’utilisateur, nous le mentionnons dans l’e-mail envoyé à l’utilisateur
  • Nous rendons également la route de confirmation du changement d’e-mail accessible aux utilisateurs anonymes, afin qu’elle puisse être cliquée par l’utilisateur même s’il n’a pas accès à son compte. Si un utilisateur est connecté, nous nous assurons que la confirmation correspond à l’utilisateur actuel.

J’espère que cela rendra le processus beaucoup plus clair !

4 « J'aime »