Einfachere Kontoregistrierung per E-Mail-Code

[rishabh]

Discourse-Communities können es Nutzern nun ermöglichen, sich mit einem kurzen per E-Mail zugesandten Code anzumelden, anstatt einen magischen Link zu verwenden. Dies bietet einen passwortlosen Anmeldevorgang, der vielen anderen SaaS-Plattformen vertraut ist und neben Ihrer bestehenden Zwei-Faktor-Authentifizierung funktioniert.

In diesem Thema fassen wir die wichtigsten Änderungen zusammen und zeigen, wie Sie diese heute bereits nutzen können.

Was sich geändert hat

Wenn diese Funktion aktiviert ist, sehen die Mitglieder einen einfacheren Ablauf:

:

1. Sie geben eine E-Mail-Adresse ein und klicken auf Weiter.
2. Ein sechsstelliger Code landet in ihrem Postfach. Sie fügen ihn ein (oder tippen ihn ein) und das Formular wird automatisch abgeschickt, sobald die letzte Ziffer eingegeben ist.
3. Wenn sie die Zwei-Faktor-Authentifizierung aktiviert haben (TOTP, Backup-Codes oder Sicherheits-Tastatur), erscheint als Nächstes der Standard-2FA-Schritt.

Einige Details, die es zu wissen gilt: Codes sind 10 Minuten gültig, laufen nach 5 fehlgeschlagenen Versuchen ab und können nur einmal eingelöst werden.

Einmalige Login-Codes in Ihrer Community aktivieren

Derzeit gilt dies als experimentelle Änderung! Bevor wir sie breiter einführen, freuen wir uns über Ihr Feedback, um Verbesserungen vorzunehmen.

Um dies zu aktivieren, gehen Sie auf die Seite Anstehende Änderungen in Ihrem Admin-Bereich (/admin/config/upcoming-changes) und suchen Sie den Eintrag Lokale Logins per Code aktivieren. Aktualisieren Sie das Feld Aktiviert für…, um Ihre Website für dieses neue Design zu registrieren:

Stellen Sie vor der Aktivierung sicher, dass sowohl enable_local_logins als auch enable_local_logins_via_email ebenfalls auf true gesetzt sind, da die Funktion ohne diese nicht aktiviert werden kann. Wenn Sie DiscourseConnect (enable_discourse_connect) verwenden, kann diese Funktion nicht aktiviert werden.

Sobald die Änderung aktiviert ist, erscheint der Code-Login-Weg automatisch.

Optionale zufällige Benutzernamen für neue Konten

Sie können neuen Mitgliedern, die sich ohne einen erkennbaren Benutzernamen in ihrer E-Mail-Adresse anmelden, einen freundlichen generierten Namen wie „QuietFalcon42“ statt eines generischen Platzhalters wie user1 zuweisen.

Wenn Sie auf Zugehörige Einstellungen anzeigen für diese anstehende Änderung klicken und die Seiteneinstellung enable_random_usernames aktivieren, füllt der Konto-bereit-Schritt den Vorschlag vor und enthält einen Würfel-Button, um einen neuen zu würfeln:

Die Wortlisten hinter den Vorschlägen können über die Seiteneinstellungen random_username_adjectives und random_username_nouns konfiguriert werden, sodass Communities sie an ihren Ton oder ihre Sprache anpassen können.

Was haltet ihr davon?

Jetzt seid ihr dran: Wir würden gerne hören, was ihr von dieser neuen Funktion haltet. Was gefällt euch und was nicht; was funktioniert gut und was könnte verbessert werden?

[darkpixlz (Pyx)]

Ich habe es gerade auf meiner Website ausprobiert. Ich bin mir nicht sicher, was die anderen alle denken, aber für mich als Passwort-Manager-Nutzer wirkt das wie ein ziemlich großer Rückschritt…

Dieser neue Ablauf entfernt die aktuelle Strategie „E-Mail generieren, Benutzernamen eingeben, Passwort generieren, speichern“, in die mich mein Passwort-Manager gedrängt hat, und zwingt dich dazu, zuerst die E-Mail-Adresse einzugeben, bevor alles andere passiert. Ich habe kein Problem mit der Sache mit dem E-Mail-Code (und bevorzuge sie sogar fast, besonders wenn der Code im Betreff der E-Mail enthalten ist), aber ich lehne das Entfernen der anderen Kontodaten-Felder entschieden ab. Wenn ich ein Nutzer ohne jegliche technische Vorkenntnisse wäre, würde ich es auch ablehnen, meine E-Mail-Adresse in ein Feld ohne jegliche Informationen wie dieses einzugeben, da dies kein gängiges Design ist. Bevor dies zur dauerhaften Lösung wird, wäre es großartig, wenn die Felder wieder hinzugefügt würden.

[dfabulich (Dan Fabulich)]

E-Mail-Codes, auch bekannt als „Magic Links“, sind in Ordnung, aber Nutzer zu Passkeys zu lenken, verbessert das Erlebnis erheblich.

Magic Links Have Rough Edges, but Passkeys Can Smooth Them Over

Eines der größten Probleme mit E-Mail-Codes ist, dass sie in In-App-Browsern, einschließlich des In-App-Browsers von Gmail, nicht das tun, was man von ihnen erwarten würde.

Das wahrscheinlich häufigste Problem, auf das Menschen mit Magic Links stoßen, ist, dass sie denken, sie hätten sich auf ihrer normalen Website eingeloggt, während sie sich tatsächlich über einen In-App-Browser eingeloggt haben. Zum Beispiel könnte jemand den Login-Link per E-Mail erhalten. Er öffnet die Gmail-App, klickt auf die Schaltfläche „Bei 404 Media anmelden“, und sein Telefon lädt die Webseite. Aber diese wird im Webbrowser von Gmail geladen, nicht im nativen Safari-Browser.

Passkeys lösen dieses Problem.

Websites, die Magic Links verwenden, könnten Passkeys zunächst als optionales Feature für Kunden anbieten, die sich über die Funktionsweise ihrer Magic Links beschwert haben. Um sicherzustellen, dass dies keine Probleme verursacht, könnte das Feature zunächst zu 100 % opt-in sein, als eine Art sanfter Start.

Etwas später, wenn die Betreibenden der Website überzeugt sind, dass Passkeys die Benutzererfahrung im Zusammenhang mit Magic Links tatsächlich verbessern, können sie Nutzer dazu auffordern, Passkeys nach der Anmeldung hinzuzufügen, etwa alle 90 Tage oder immer dann, wenn sie die geräteübergreifende Anmeldefunktion von Passkeys nutzen. Die Formulierung einer solchen Aufforderung könnte für Nutzer von Apple-Geräten etwa so lauten: Möchten Sie beim nächsten Mal nicht wieder Ihre E-Mails prüfen müssen? Richten Sie einen Passkey ein, um sich schnell und sicher mit Face ID oder Touch ID anzumelden.

Nutzer zu Passkeys zu lenken, ist dasselbe wie sie zur Verwendung eines Passwortmanagers zu ermutigen, denn Passkeys sind im Grunde nur Passwörter, die einen Passwortmanager erfordern.

[Don]

Hallo

Ich mag diesen Ansatz sehr! Allerdings stört es mich ein bisschen, dass der Anzeigename nicht geändert werden kann, bevor die Registrierung abgeschlossen ist. Ich denke, es wäre großartig, eine Option hinzuzufügen, um ihn während des Prozesses zu ändern.

In meiner Community habe ich die Website-Einstellung Benutzernamen in der UX priorisieren deaktiviert, was bedeutet, dass der vollständige Name/Anzeigename in der gesamten Benutzeroberfläche priorisiert wird. Aus diesem Grund sehen automatisch zugewiesene Namen wie “user21” auf der Front-End-Seite ziemlich schlecht aus, wenn der Benutzer keine sofortige Option zur Anpassung hat.

Danke!

[pmusaraj (Penar Musaraj)]

@dfabulich

Eines der größten Probleme mit E-Mail-Codes ist, dass sie in In-App-Browsern, einschließlich des In-App-Browsers von Gmail, nicht so funktionieren, wie man es erwarten würde.

Dieser neue Ablauf sendet keinen Magic Link. Er sendet nur den Code. Der Benutzer bleibt auf derselben Seite und kopiert den Code aus seiner E-Mail in das Registrierungsformular. Dieser neue Ansatz hilft also bei In-App-Browsern (das ist einer der Hauptvorteile der Änderung).

@dfabulich

Benutzer zu Passkeys ermutigen

Das ist sicher etwas, das wir als Nächstes tun möchten, und zwar im Passwort-Schritt der Registrierung. Apps und Websites haben ihre Unterstützung für Passkeys ausgebaut, ich sehe den Passkeys-Hinweis in vielen Kontexten, daher macht es auch für Discourse Sinn, dies hinzuzufügen. (Eine kritische Masse an Unterstützung ist bei diesem Wechsel von Passwörtern zu Passkeys sehr hilfreich.)

[DomMcD (Dominic McDevitt)]

Mein einziges Problem mit dieser Funktion ist, dass sie die Felder für Namen und Benutzernamen von meiner Registrierungsseite entfernt. Ist das beabsichtigt? Ich möchte nicht, dass Benutzer sich direkt nach der Registrierung durch die Einstellungen graben müssen, nur um einen Benutzernamen zu vergeben, der nicht „user63“ lautet.

[kddkd (16)]

Diese Methode der E-Mail-Verifizierungscode-Registrierung ist genau die Änderung, die ich mir schon immer gewünscht habe!

[Moin]

Ohne diese Änderung hatten der Link „Passwort vergessen“ und der Link „An E-Mail senden“ die gleiche Größe. Jetzt ist der letztere größer. Ist das beabsichtigt?

[Moin]

Es wurde behoben in

UX: Match font size of one-time code login link (#41879)

[rishabh]

Danke für das Feedback, ja, das ist beabsichtigt, um einen schnelleren Weg zur Kontenerstellung zu bieten.

@DomMcD

Ich möchte nicht, dass Benutzer direkt nach der Registrierung in den Einstellungen herumschnüffeln müssen, nur um einen Benutzernamen zu setzen, der nicht „user63“ ist.

Verstanden, ja, wir untersuchen Möglichkeiten, diesen nächsten Schritt zu vereinfachen oder die anfänglichen Benutzernamen mit einer anderen Methode festzulegen.

[Moin]

Ich stimme zu. Diese generischen Benutzernamen machen die Interaktion mit den Nutzern verwirrender. Da die Nutzer standardmäßig nur drei Tage Zeit haben, ihre Namen zu aktualisieren, erwarte ich, dass sie dies oft erst nach Ablauf dieser Frist bemerken, sodass das Personal sich um das Umbenennen kümmern muss.
Ich fand es wirklich toll, dass Offering blank username suggestions rather than ‘UserN’ at signup hier auf Meta zum Beispiel verhinderte, dass dies geschieht. Der letzte NutzerXXX wurde am 7. Januar erstellt, bevor dieser Fix eingepflegt wurde. Danach gab es keinen neuen NutzerXXX, bis diese Funktion aktiviert wurde, und seitdem gibt es 12 neue.

[Thomas_Rother (Thommie Rother)]

Diese Funktion ist äußerst nützlich. Immer mehr Plattformen nutzen die Funktion „Einmalcode per E-Mail“, um sichere Anmeldevorgänge mit MFA anzubieten, ohne dass ein spezifisches Gerät (mit dem entsprechenden Authentifikator) zur Hand sein muss.

[rishabh]

@DomMcD

Ich möchte Nutzer nicht dazu zwingen, gleich nach der Registrierung in den Einstellungen zu stöbern, nur um einen Benutzernamen zu vergeben, der nicht „user63“ lautet.

@Moin

Dem stimme ich zu. Diese generischen Benutzernamen machen die Interaktion mit Nutzern verwirrender. Da Nutzer standardmäßig nur 3 Tage Zeit haben, ihre Namen zu aktualisieren, erwarte ich, dass sie dies häufig erst nach Ablauf dieser Frist bemerken. In solchen Fällen muss sich das Support-Team um die Umbenennung kümmern.

Siehst du diesen Schritt während der Konterstellung nicht?

[Moin]

Das ist ein seltsames Zitat: Es sieht so aus, als hätte DomMcD mich zitiert, was aber nicht stimmt.

Ich habe die Schritte nicht getestet. Ich habe lediglich darauf hingewiesen, was ich hier auf Meta bei neuen Nutzern beobachtet habe. Es ist mir egal, ob ich ein bestimmtes Feld bei der Registrierung sehe. Ich muss damit umgehen, was andere mit diesem Feld anstellen.

Ich frage mich auch, wie mit Namen umgegangen wird. Während es nicht so scheint, als würden alle Nutzer die generierten Benutzernamen verwenden, fällt mir auf, dass noch mehr Nutzer einen Namen der Form „userXXX“ tragen.

Scheinbar bekommen sie das sogar dann, wenn sie den Benutzernamen ändern. Infolgedessen wird dieselbe Nummer immer wieder verwendet, bis der Benutzername bereits vergeben ist, und dann fängt der Vorgang mit der nächsten Nummer von vorne an.

Zum Beispiel haben 0102100988082, mohamedasarudeen und user603 alle „user603“ als Namen.

Ich weiß, dass sie den Namen ändern könnten, aber ich kann es nicht ändern, wie sich meine Interaktion mit ihnen anfühlt.

[rishabh]

Danke für die Meldungen, alle zusammen. Ein Fix wird in Kürze übernommen:

FIX: Stop placeholder usernames sticking after email code signup (#42796)

[rishabh]

Update

Dank der neuesten Arbeit von @keegan gibt es in diesem Schritt nun eine Funktion zur Benutzernamensgenerierung, die einen Vorschlag vorbefüllt:

@rishabh

Zufällige Benutzernamen für neue Konten

Neue Mitglieder, die sich ohne einen erkennbaren Benutzernamen in ihrer E-Mail-Adresse anmelden, erhalten nun einen freundlichen generierten Namen wie „QuietFalcon42“ statt eines generischen Platzhalters wie user1. Der Schritt „Konto bereit“ befüllt den Vorschlag vor und enthält einen Würfel-Button, um einen neuen Namen zu würfeln.

Die hinter den Vorschlägen stehenden Wortlisten können über die Seiteneinstellungen random_username_adjectives und random_username_nouns konfiguriert werden, sodass Communities sie an ihren Ton oder ihre Sprache anpassen können. Um die Funktion zu deaktivieren und den alten nummerierten Fallback zu behalten, muss enable_random_usernames deaktiviert werden.

[Jagster (Jakke Flemming)]

Ein UX-mäßiger Wunsch, falls möglich. Dieser hier:

Meine Geräte sind sich ziemlich sicher, dass hier ein Passwort benötigt wird, aber es sollte nach der E-Mail-Adresse gefragt werden. Dann würden meine Telefone usw. wissen, dass sie eine Adresse statt anderer Zugangsdaten anbieten sollen.

[thisisjoshjones (Joshua Jones)]

Könnte dieser Registrierungsprozess auch auf der Landing Page für Einladungen umgesetzt werden? Ich bin mir sicher, dass das über den Rahmen dieser Alpha-Phase hinausgeht, aber diese Umsetzung wäre nach der Stabilisierung der Funktion sehr nützlich. Das senkt die Einstiegshürde für die Mitglieder meiner Community tatsächlich erheblich, also vielen Dank!

[mcwumbly (Dave McClure)]

Zufällig gibt es hier in dieser Hinsicht bereits laufende Arbeiten:

https://github.com/discourse/discourse/pull/43138

[ecki (Bernd)]

Ich mag die Funktion im Allgemeinen (erster Registrierungs-Schritt nur mit E-Mail und Code), aber sie hat noch einige Macken:

a) Login und Registrierung sollten separate Konfigurationen sein.
b) Das Ausblenden des Benutzernamensfelds im Registrierungsformular sollte eine zusätzliche Option sein, da Benutzernamen immer noch eine wichtige Kommunikationsfunktion erfüllen. Zufällige oder nummerierte Benutzernamen wirken ziemlich seltsam.
c) Seltsamerweise funktionierten die zufälligen Benutzernamen auf meiner Seite für einige Spam-Registrierungen (nicht verifizierte Benutzereinträge), aber nicht für zwei echte Benutzer. Beide bekamen „user1“ und „user2“ als Namen, äh. (Ich bin mir nicht sicher, worin der Unterschied zwischen den Spam-Sendern und den Benutzern liegt.)
d) Könnte man für den Login einen zusätzlichen Button anbieten, vielleicht einen, der eine E-Mail mit einem Magic Link und einem Code sendet? Ich sehe keinen Grund, dies getrennt zu halten.
e) Die Dokumentation sollte klarstellen, dass das Benutzernamensfeld entfernt wird (oder besser: es nicht entfernt wird).