Ändern der E-Mail-Adresse eines Benutzers

RGJ · 18. September 2020 um 22:17

Ich bin beim Prozess, wenn ein Administrator die E-Mail-Adresse eines Benutzers ändert, etwas verwirrt.

Einige Dinge verstehe ich einfach nicht, und es gibt einen Fehler (deshalb poste ich dies im #bug-Kanal und nicht im #support-Kanal).

Laut diesem Pull Request sollte es wie folgt funktionieren:

Wenn ein Administrator die E-Mail-Adresse eines Benutzers über die Einstellungsseite dieses Benutzers ändert:

Der Benutzer erhält keine E-Mail zur Bestätigung der E-Mail-Änderung. Stattdessen wird eine E-Mail zum Zurücksetzen des Passworts gesendet, damit er das Passwort für sein Konto an der neuen E-Mail-Adresse festlegen kann.

Der Benutzer erhält weiterhin eine E-Mail an seine alte E-Mail-Adresse, um ihn über die Änderung zu informieren.

#1 Ich verstehe nicht, warum eine E-Mail zum Zurücksetzen des Passworts gesendet wird („damit sie das Passwort für ihr Konto festlegen können). Sie müssen ihr Passwort doch nicht ändern? Und die Benutzererfahrung ist verwirrend – der Benutzer erwartet keine E-Mail zum Zurücksetzen des Passworts, und es gibt keinen begleitenden Text; es heißt einfach nur: „Jemand hat angefordert, Ihr Passwort auf [Name des Forums] zurückzusetzen“.

#2 Diese E-Mail zum Zurücksetzen des Passworts wird an die alte Adresse gesendet, statt an die neue E-Mail-Adresse.

Obwohl die Benutzer-E-Mail in update_user_email in Zeile 46 aktualisiert wird, wird das @user-Objekt nicht neu geladen und enthält immer noch die alte E-Mail-Adresse.

github.com/discourse/discourse

lib/email_updater.rb

main


      
          if @guardian.is_staff? && @guardian.user != @user
            StaffActionLogger.new(@guardian.user).log_add_email(@user)
          else
            UserHistory.create!(action: UserHistory.actions[:add_email], acting_user_id: @user.id)
          end

#3 Wenn der Administrator der handelnde Benutzer ist und der betroffene Benutzer kein Mitarbeiter ist, wird gemäß der oben genannten Spezifikation keine Bestätigungs-E-Mail gesendet. Trotzdem erhält der Administrator nach der Änderung der E-Mail-Adresse folgende Erfolgsmeldung: „Wir haben eine E-Mail an diese Adresse gesendet. Bitte befolgen Sie die Bestätigungshinweise.“

#4 Warum muss der Benutzer seine neue E-Mail-Adresse nicht bestätigen? Der Pull-Request verweist auf dieses Thema, aber es scheinen viele Beiträge darin zu fehlen. Dennoch heißt es im Thema: „Für einen normalen Benutzer ist nur die NEUE E-Mail-Adresse zu verifizieren.“ EDIT: Oh warte, siehe #6 / #7.

#5 Dieser Prozess, bei dem ein Administrator die E-Mail-Adresse eines Benutzers ändert, wird typischerweise verwendet, wenn die alte E-Mail-Adresse nicht mehr zugänglich ist (nehme ich an). Warum wird dann trotzdem eine Benachrichtigung an die alte Adresse gesendet?

#6 Wenn dieser Benutzer sich einzuloggen versucht, erscheint ein Popup:

Sie können sich noch nicht anmelden. Wir haben Ihnen zuvor eine Aktivierungs-E-Mail an alte E-Mail-Adresse gesendet. Bitte befolgen Sie die Anweisungen in dieser E-Mail, um Ihr Konto zu aktivieren.

Es wurde keine solche E-Mail gesendet.
Die alte E-Mail-Adresse wird erwähnt.

Beim Drücken der Schaltfläche „Erneut senden“ heißt es:

Wir haben Ihnen eine weitere Aktivierungs-E-Mail an neue E-Mail-Adresse gesendet. Es kann einige Minuten dauern, bis sie ankommt; prüfen Sie bitte auch Ihren Spam-Ordner.

#7 Diese Aktivierungs-E-Mail kommt tatsächlich an der neuen E-Mail-Adresse an und trägt den Titel „Bestätigen Sie Ihr neues Konto“ (und nicht „Bestätigen Sie Ihre neue E-Mail-Adresse“).

Sollte das nicht einfach so sein:

Eine E-Mail wird an die neue E-Mail-Adresse gesendet mit der Aussage: „Ihre E-Mail-Adresse wurde von [Name des Administrators] geändert. Bitte klicken Sie auf den folgenden Link, um dies zu bestätigen: [Link].“

Edit: #8 Die E-Mail-Adresse kann von einem Administrator über das öffentliche Profil des Benutzers (/u/username) geändert werden, aber nicht über die Admin-Seite für diesen Benutzer (/admin/users/id/username). Das ist kontraintuitiv.

codinghorror · 21. September 2020 um 00:17

Können wir das @tshenry reproduzieren? Haben wir hier eine Regression?

tshenry · 25. September 2020 um 00:40

Ich beginne damit, den aktuellen Ablauf so darzustellen, wie ich ihn beobachte (die meisten, wenn nicht alle Punkte stimmen mit dem überein, was @RGJ skizziert hat):

Ein Administrator geht zu den Einstellungen eines Nicht-Mitarbeiter-Benutzers und ändert dessen E-Mail-Adresse:

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

Nach dem Absenden sieht der Administrator folgende Meldung:

Wir haben eine E-Mail an diese Adresse gesendet. Bitte befolgen Sie die Bestätigungsinstruktionen.
Die obige Meldung scheint nicht korrekt zu sein, da ZWEI E-Mails an die alte E-Mail-Adresse gesendet werden:

[Demo] Ihre E-Mail-Adresse wurde geändert

Dies ist eine automatisierte Nachricht, um Sie darüber zu informieren, dass Ihre E-Mail-Adresse für
Demo geändert wurde. Falls dies versehentlich geschehen ist, kontaktieren Sie bitte
einen Site-Administrator.

Ihre E-Mail-Adresse wurde geändert in:

neu@email.com

[Demo] Passwort zurücksetzen

Jemand hat angefordert, Ihr Passwort für Demo zurückzusetzen.

Falls dies nicht von Ihnen stammt, können Sie diese E-Mail sicher ignorieren.

Klicken Sie auf den folgenden Link, um ein neues Passwort festzulegen:
https://example.discourse.site/u/password-reset/74d53d7d2cf20dsbc360614844c653s2
Ich habe ab diesem Punkt drei verschiedene Szenarien getestet. Jeder Aufzählungspunkt stellt ein eigenes Szenario dar:
- Der Benutzer hat Zugriff auf die alte E-Mail-Adresse und folgt dem Link zum Zurücksetzen des Passworts. Nach dem Aktualisieren des Passworts wird er eingeloggt. Von dort aus kann er sich mit seinem Benutzernamen oder der alten E-Mail-Adresse anmelden. Die neue E-Mail-Adresse scheint zu diesem Zeitpunkt noch nicht wirksam zu sein.
- Der Benutzer versucht, sich mit seinem Benutzernamen oder der neuen E-Mail-Adresse anzumelden und erhält folgende Meldung:
  
  Screen Shot 2020-09-24 at 4.38.01 PM1418×394 35.5 KB
  
  Option 1: Das Klicken auf „Erneut senden

codinghorror · 25. September 2020 um 00:54

Warum ist das regressiert?

Edit: Ich kann auch bestätigen, dass es regressiert ist. Beim Bearbeiten der E-Mail-Adresse eines normalen Benutzers werden die Bestätigung und dergleichen an die ALTE E-Mail-Adresse gesendet. So hat das in der Vergangenheit nicht funktioniert..

martin · 27. September 2020 um 23:11

Dieses unangenehme Gefühl der Vertrautheit, wenn man die zitierte Beschreibung eines Pull Requests liest und merkt, dass man selbst der Übeltäter ist…

Danke für die detaillierten Anweisungen, @tshenry und @RGJ. Ich werde das diese Woche ganz oben auf meine To-Do-Liste setzen, um das zu beheben.

martin · 28. September 2020 um 02:48

Okay, ich habe das jetzt verstanden und habe mir den alten Thread zu gelöschten Kommentaren für den Verlauf angesehen. Ich habe dies von @sam ausgegraben, an das ich mich jetzt erinnere:

Das Zurücksetzen der E-Mail-Adresse durch den Admin ist ein völlig anderer Fall; es geht eigentlich darum, dass der Admin sowohl E-Mail als auch Passwort zurücksetzt. Denn wenn der Nutzer Zugriff auf das Konto hätte, könnte er das alles selbst über den Selbstbedienungsservice erledigen.

Wir sagen also, dass, da der Admin die E-Mail-Adresse ändert, eine E-Mail zum Zurücksetzen des Passworts gesendet werden sollte. Denn wenn der Nutzer Zugriff auf die alte E-Mail-Adresse hätte, könnte er sich einfach… einloggen und es selbst erledigen? Aber die E-Mail zum Zurücksetzen des Passworts dient auch als Bestätigung. Ohne den Prozess zum Zurücksetzen des Passworts abzuschließen (was aktuell unmöglich ist, da die E-Mail an die alte Adresse gesendet wird), ist die neue E-Mail-Adresse nicht „bestätigt“. Genau das bewirkt, dass dieses Modal erscheint:

Das Problem, dass die E-Mail zum Zurücksetzen des Passworts an die alte Adresse gesendet wird, lässt sich leicht beheben. Damit erreichen wir zumindest einen Zustand, in dem der Zurücksetzungsprozess fortgesetzt werden kann:

RGJ:

Obwohl die E-Mail-Adresse des Nutzers in update_user_email auf Zeile 46 aktualisiert wird, wird das @user-Objekt nicht neu geladen und enthält immer noch die alte E-Mail-Adresse.

github.com

discourse/discourse/blob/master/lib/email_updater.rb#L44-L49
if @guardian.is_staff? && !@user.staff?
  send_email_notification(@user.email, email)
  update_user_email(old_email, email)
  send_email(:forgot_password, @user.email_tokens.create!(email: @user.email))
  return
end

Außerdem wird die E-Mail zum Zurücksetzen des Passworts derzeit an die alte E-Mail-Adresse gesendet. Wenn diese bestätigt wird, wird fälschlicherweise die alte Adresse bestätigt und die E-Mail-Adresse des Nutzers wieder auf die alte zurückgesetzt.

Ich werde die Meldung für den Admin, der die E-Mail-Adresse ändert, so anpassen, dass klar wird, dass der Nutzer den Link in der neuen E-Mail anklicken und sein Passwort ändern muss, damit die Änderung vollständig wirksam wird (und um das Problem mit der falschen E-Mail-Adresse ebenfalls zu beheben).

RGJ · 28. September 2020 um 11:28

Warte. Ich verstehe das nicht.

Es besteht ein Unterschied zwischen der Möglichkeit eines Benutzers, auf die alte E-Mail-Adresse zuzugreifen, und der Notwendigkeit eines Passwort-Resets für sein Discourse-Konto. Das eine impliziert das andere überhaupt nicht; das sind völlig unterschiedliche Situationen.

Ein Großteil der E-Mail-Änderungen durch Administratoren erfolgt auch deshalb, weil der Benutzer nicht weiß, wie er es selbst tun soll, oder weil der Administrator die Einschränkung email_editable = false vorübergehend aufheben muss.

Ich finde es sehr verwirrend, dass ein Passwort-Reset gleichzeitig als E-Mail-Bestätigung dient. Persönlich würde ich auf die E-Mail zum Zurücksetzen des Passworts nicht einmal reagieren, da ich sie nicht angefordert habe, und ich würde nicht merken, dass dies ein notwendiger Bestätigungsschritt ist (und ich denke, das ist es auch nicht; eine reguläre Bestätigungsmail würde ausreichen?)

Steve_Pavlina · 28. September 2020 um 16:47

Könnte damit zusammenhängen:

Wenn einer meiner Forenbenutzer heute versucht, sein Passwort zurückzusetzen (wir nutzen die neueste Version von Discourse, Stand heute Morgen), erhält er zwar die E-Mail, aber beim Klicken auf den Link in der E-Mail erscheint ein Fehler:

Dieser Fehler tritt in mehreren Browsern auf, und der Benutzer verwendet keinen Adblocker.

Wenn ich auf die Präferenzen-Seite seines Kontos gehe und auf „Passwort-Zurücksetzungs-E-Mail senden

codinghorror · 28. September 2020 um 16:54

Überprüfe die Discourse-Fehlerprotokolle im Webbrowser, wenn du als Administrator angemeldet bist. Dort sollte ein Fehlerbericht mit weiteren Details zu finden sein.

Steve_Pavlina · 28. September 2020 um 17:05

Hier ist der Fehler-Eintrag:

398 Job exception: The specified copy source is larger than the maximum allowable size for a copy source: 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'

RGJ · 28. September 2020 um 17:28

Nein, das hat absolut nichts miteinander zu tun. Versuche, die Protokolle zu löschen und diesen Fehler erneut auszulösen, und überprüfe dann die Protokolle.

Steve_Pavlina · 28. September 2020 um 18:22

Anschließend bleiben die Protokolle nach dem Auftreten des Fehlers leer.

martin · 28. September 2020 um 23:44

RGJ:

Warte. Ich verstehe das nicht.

Es besteht ein Unterschied zwischen der Möglichkeit eines Benutzers, auf die alte E-Mail-Adresse zuzugreifen, und der Anforderung eines Benutzers, sein Discourse-Konto zurückzusetzen. Das eine impliziert das andere überhaupt nicht; das sind völlig unterschiedliche Situationen.

Eine große Anzahl von E-Mail-Änderungen durch Administratoren erfolgt auch, weil der Benutzer nicht weiß, wie er dies tun soll, oder weil der Administrator die Einschränkung email_editable = false vorübergehend aufheben muss.

…

Ich finde es sehr verwirrend, dass ein Passwort-Reset gleichzeitig als E-Mail-Bestätigung dient. Persönlich würde ich auf das Passwort-Reset sogar nicht reagieren, da ich es nicht angefordert habe, und ich würde nicht merken, dass es ein notwendiger Bestätigungsschritt ist (und ich denke, das ist es nicht; eine reguläre Bestätigungsmail würde ausreichen?)

Ich kann nachvollziehen, woher du kommst. Für mich hat mich die Sache mit dem Passwort-Reset als Bestätigung gestern verwirrt. Ich finde, dies könnte eine sekundäre Option für den Administrator beim Ändern der E-Mail eines Benutzers sein: Ein Häkchen setzen mit der Beschriftung „Passwort des Benutzers ebenfalls zurücksetzen“. Ich werde den PR, den ich für eine Korrektur habe, so wie er ist zusammenführen, da der Prozess derzeit völlig kaputt ist.

Ich möchte, dass @sam sich zu einem neuen Prozess/Workflow äußert, da Sam ursprünglich über die Gründe hinter dem Passwort-Reset-Workflow gesprochen hat:

Der Administrator ändert die E-Mail-Adresse des Benutzers. Er hat die Option, gleichzeitig das Passwort zurückzusetzen.
Der Benutzer erhält eine E-Mail an seine neue Adresse, in der um Bestätigung der E-Mail-Änderung gebeten wird.
- Wenn er mit „Ja“ antwortet, wird die E-Mail-Adresse geändert. Wir senden eine E-Mail an die alte Adresse, dass die E-Mail-Adresse geändert wurde.
- Wenn er mit „Nein“ antwortet, wird nichts unternommen.
Wenn der Administrator in Schritt 1 angegeben hat, dass er einen Reset wünscht, erhält der Benutzer, sobald er die E-Mail-Änderung bestätigt, eine E-Mail zur Passwort-Reset an die neue Adresse.

Ich denke, das wäre viel klarer, und das Passwort-Reset hätte nichts mit der Bestätigung der E-Mail-Änderung zu tun.

codinghorror · 28. September 2020 um 23:48

Ja, ich sehe auch nicht, warum diese beiden Dinge überhaupt zusammenhängen sollten?

IAmGav · 29. September 2020 um 00:56

Ich sehe einen schönen neuen zusammengeführten Commit, über den sich alle freuen werden

github.com/discourse/discourse

FIX: Admin change email for user process improvements and fixes (#10755)

master ← issue/fix-admin-changing-user-email-process

merged 11:45PM - 28 Sep 20 UTC

martin-brennan

+33 -10

See https://meta.discourse.org/t/changing-a-users-email/164512 for context. W…hen admin changes an email for a user, we were incorrectly sending the password reset email to the user's old address. Also the new email does not come into effect until the reset password process is done, so this PR adds some notes to the admin to make this clearer.

martin · 29. September 2020 um 01:03

Danke, damit wird nur eine Korrektur für den „völlig kaputten

martin · 7. Oktober 2020 um 03:03

Ich habe gerade diesen PR zusammengeführt, der Folgendes bewirkt:

github.com/discourse/discourse

FIX: When admin changes an email for the user the user must confirm the change (#10830)

master ← issue/fix-admin-change-user-email-flow

merged 03:02AM - 07 Oct 20 UTC

martin-brennan

+155 -62

See https://meta.discourse.org/t/changing-a-users-email/164512 for additional co…ntext. Previously when an admin user changed a user's email we assumed that they would need a password reset too because they likely did not have access to their account. This proved to be incorrect, as there are other reasons a user needs admin to change their email. This PR: * Changes the admin change email for user flow so the user is sent an email to confirm the change * We now record who the email change request was requested by * If the requested by user is admin and not the user we note this in the email sent to the user * We also make the confirm change email route open to anonymous users, so it can be clicked by the user even if they do not have access to their account. If there is a logged in user we make sure the confirmation matches the current user.

Ändert den Ablauf für die E-Mail-Änderung im Admin-Bereich, sodass der Benutzer eine E-Mail zur Bestätigung erhält.
Wir erfassen nun, von wem die E-Mail-Änderungsanfrage gestellt wurde.
Wenn der Antragsteller ein Admin und nicht der Benutzer selbst ist, wird dies in der an den Benutzer gesendeten E-Mail vermerkt.
Außerdem machen wir die Route zur Bestätigung der E-Mail-Änderung für anonyme Benutzer zugänglich, sodass sie auch dann geklickt werden kann, wenn der Benutzer keinen Zugriff auf sein Konto hat. Falls ein angemeldeter Benutzer vorhanden ist, stellen wir sicher, dass die Bestätigung mit dem aktuellen Benutzer übereinstimmt.

Hoffentlich ergibt dieser Prozess nun viel mehr Sinn!

Thema		Antworten	Aufrufe
On email address change second confirm fails due to email customization Support	20	1968	26. Dezember 2019
Users getting Internal Server Error when trying to change email address Bug	6	182	15. Mai 2025
Change email for SSO user? SSO	35	9757	9. September 2024
User can't change his email address Support	10	756	24. Juli 2023
PUT /u/{username}.json does not change the email Bug rest-api	8	694	10. August 2023

Ändern der E-Mail-Adresse eines Benutzers

[Demo] Ihre E-Mail-Adresse wurde geändert

[Demo] Passwort zurücksetzen

Verwandte Themen