Hinweis: Dies ist aus Sicherheitssicht ein wünschenswertes Verhalten, aber wir können die Benutzerfreundlichkeit verbessern, wenn dies bei einem Benutzer auftritt
Wenn ein Benutzer ein U2F-Token registriert hat, funktioniert dieses nicht, wenn sich der Hostname der Seite seit der Registrierung geändert hat.
Es gibt jedoch keine Rückmeldung an den Benutzer, dass dies möglicherweise daran liegt, dass sich der Hostname geändert hat, da wir diese Information in Discourse nicht speichern. Und wenn der Benutzer nicht weiß, warum dies der Fall sein könnte, wird er verwirrt sein.
Eine Verbesserung für diesen Fall könnte auf diesem Bildschirm sein:
Deaktivierung von „Mit Sicherheitsschlüssel authentifizieren"
Eine Meldung wie: „Wir haben einen Sicherheitsschlüssel für dieses Konto, er gehört jedoch nicht zum Hostname, an den Sie die Anfrage senden (www.example.com)"
Zu beachten:
Wenn wir das oben Genannte tun, müssen wir sicherstellen, dass wir den alten Hostnamen nicht auf den neuen Hostnamen in der Tabelle UserSecurityKey ummappen.
Ja, wir müssen hier bei @sam noch etwas Text hinzufügen, um den Fall einer Domain-Änderung abzudecken. Ich denke, es handelt sich hauptsächlich um eine Aktualisierung des Textes, etwa einen Haftungsausschluss am unteren Rand oder so etwas?
Das könnte ein wenig knifflig sein, da ich glaube, dass der Hostname innerhalb des öffentlichen Schlüssels in der Tabelle für Sicherheitsschlüssel gespeichert ist (es ist eine Weile her, seit ich daran gearbeitet habe, also könnte ich mich irren). Es wird etwas Fummelei erfordern, um dieses Problem in der Benutzeroberfläche zu melden, den Button zu deaktivieren und die Meldung anzuzeigen. Außerdem würde dies nur angezeigt werden, wenn alle registrierten Sicherheitsschlüssel den falschen Hostnamen haben – wenn einer übereinstimmt, ist der Benutzer in Ordnung.
Etwas verwandt damit muss ich auch 2fa security key breaks when migrating to custom domain - #6 by balboah beheben. Ich werde dieses Thema auch mir selbst zuweisen, denn ich denke, wenn wir Hostnamen ändern, sollten wir wahrscheinlich alle bestehenden Sicherheitsschlüssel deaktivieren, da sie effektiv nutzlos werden.
Ich stelle häufig eine Datenbank von einer Produktionsumgebung auf eine Testumgebung mit einem anderen Hostnamen wieder her. Es wäre toll, wenn dabei alle ungültigen Schlüssel deaktiviert und Administratoren aufgefordert werden könnten, sie zurückzusetzen (obwohl ein verantwortungsbewusster Benutzer Sicherungsschlüssel hinterlegt hat, also hilft das nicht wirklich. ).
).