Bestätigungsmail-Link (nach Änderung) ist aufgrund schlechter E-Mail-Anpassung kaputt („Ups!“)

Dies scheint nur aufzutreten, wenn die E-Mail-Adresse geändert wird. Z. B.:

https://forum.{mySite}.com/u/{user}/preferences/email

  1. Der Benutzer erhält erfolgreich eine Bestätigungs-E-Mail.
  2. Der Benutzer klickt auf den Link.
  3. Der Benutzer erhält einen Fehler: “Hoppla! Seite nicht gefunden oder privat”.

image

Vorlage für den Link in der Bestätigungs-E-Mail:

%{base_url}/u/authorize-email/%{email_token}

Tatsächlicher Link in der Bestätigungs-E-Mail:

https://forum.{mySite}.com/u/authorize-email/{someHash}

Kannst du das @tshenry nachstellen?

Das ist diese Woche auch bei uns passiert, genau wie oben beschrieben.

Sie haben diese E-Mail wahrscheinlich angepasst, bevor wir den Link geändert haben.

Bitte gehen Sie zu /admin/customize/email_templates/user_notifications.confirm_new_email und stellen Sie sicher, dass der Link dort so aussieht:

%{base_url}/u/confirm-new-email/%{email_token}

anstatt

%{base_url}/u/authorize-email/%{email_token}


Es könnte eine gute Idee sein, trotzdem eine Migration hinzuzufügen. Dies wurde bereits mehrfach angesprochen.
cc @sam
https://review.discourse.org/t/feature-improve-email-change-workflow-pr-8377/7150/4

Das hat den defekten Link… sozusagen… behoben; jetzt leitet es den Benutzer nur noch auf den Login-Bildschirm weiter.

Auch wenn es gut ist, dass mir das aufgefallen ist, damit Benutzer ihre E-Mail-Adresse ändern können, warum gibt es im Admin-Bereich keine Möglichkeit, die E-Mail-Adresse eines Benutzers zu bearbeiten? Der einzige Weg war, sich als Benutzer einzuloggen >> Profil >> E-Mail ändern? Das habe ich jedenfalls gelesen – ist das wirklich der offizielle Weg, das zu tun?

Ich kann ein Konto löschen und mich als Benutzer einloggen, aber keine E-Mail-Adresse ändern? Das wirkt etwas kontraintuitiv~

%{base_url}/u/confirm-new-email/%{email_token}

Mein Link sieht so aus, und trotzdem werden die Nutzer auf eine Oops-Fehlermeldung weitergeleitet. Meinen Sie, es sollte umgekehrt sein?

Bei mir leitet %{base_url}/u/confirm-new-email/%{email_token} die Benutzer auf die Anmeldeseite weiter, ohne das Konto zu aktivieren. Die andere Seite ist die „Oops“-Seite.

Das ist seltsam, aber:
Es war das:
%{base_url}/u/confirm-new-email/%{email_token} und lieferte eine Fehlermeldung

Ich habe es geändert in:
%{email_token}/u/authorize-email/%{base_url}. und es lieferte immer noch eine Fehlermeldung

Ich habe es manuell wieder geändert in:
%{base_url}/u/confirm-new-email/%{email_token} (nicht durch Zurücksetzen)
und jetzt funktioniert es! :woman_shrugging:

edit: oh und jetzt funktioniert es wieder nicht.

Ich möchte das noch etwas länger auf die lange Bank schieben.

Wie wäre es mit einem abwärtskompatiblen (veralteten) Spiegel-Link? Oder einem Ersatz-Skript für einige Versionen? Könnte man im nächsten Update das alte %{} durch das neue %{} ersetzen? Falls bereits migriert, würde nichts passieren.

Aber egal wie – mein Problem ist nicht gelöst… oder so scheint es: Es leitet sie einfach zur Anmeldeseite ohne Aktivierung.

https://forum.{mySite}.com/u/confirm-new-email/{someHash}

^ Stimmt das? Die Person besteht darauf, dass sie einen Inkognito-Modus verwendet und einen Screenshot der Anmeldeseite gezeigt hat. Bei der Überprüfung kann ich sehen, dass die alte E-Mail-Adresse im Admin-Bereich noch angezeigt wird.

Ich verstehe nicht, warum du nicht einfach alle deine relevanten Lokalisierungsanpassungen löschst und ganz von vorne beginnst?

Weil weder ich noch andere – sie haben keine Ahnung, dass das überhaupt passiert ist. *Es war nicht so, als hätte der Button „Zum Aktualisieren klicken

Ich wollte nur kurz nachhaken.

Ich habe es nie angepasst. Es enthält %{base_url}/u/confirm-new-email/%{email_token}, wie Sie empfohlen haben, aber in der tatsächlichen E-Mail steht im Link /authorize-email/. Ich vermute also, dass zwischen dem Web-Admin-Panel und einer Konfigurationsdatei tief unten im Maschinenraum von Discourse etwas schiefgeht. Ich verwende Version 2.5.0.beta6.

Edit: Noch seltsamer: Wenn ein Admin die E-Mail-Adresse ändert, erhält die Bestätigung an die alte Adresse %{base_url}/u/confirm-new-email/%{email_token}, aber die neue Adresse bekommt sie mit %{base_url}/u/authorize-email/%{email_token}.

@Willemb2 Wir haben bei unserer Instanz festgestellt, dass das Problem nur bei Benutzern auftrat, deren Schnittstelle auf eine bestimmte Sprache eingestellt war. Egal wie oft ich es versucht habe, die Sprache auf die zu setzen, die ich verwende, es machte für diejenigen, die Französisch sprechen, keinen Unterschied. Ich musste meine eigene Schnittstelle auf Französisch umstellen, und plötzlich konnte ich die französische Version anpassen. Seitdem hatten wir das Problem nicht mehr.

@gh_irina Ich habe das geprüft, aber es tritt auch bei Benutzern mit der Standardsprache (in unserem Fall: Niederländisch) auf.

Oh, das ist ärgerlich. Es tut mir leid.

Ich bin gerade auf dieses Problem in einem Forum gestoßen, in dem ich Mitglied bin. Ich konnte es umgehen, indem ich den Link manuell angepasst habe. Warum nicht für diese Breaking Changes einen Abfangmechanismus für den alten Link einbauen, um den Administrator zu alarmieren?