Eines unserer Benutzerkonten wurde kompromittiert. Der Workflow zur Behebung dieses Problems war alles andere als ideal.
Die Rails-Konsole wurde benötigt für:
Erzwingen der Änderung der E-Mail-Adresse
Erzwingen der Änderung des Passworts in ein zufälliges, um eine Passwortzurücksetzung per E-Mail zu erzwingen
Beenden aller aktiven Sitzungen
Darüber hinaus stellten wir fest, dass die E-Mail-Änderung nur in den Protokollen für ausgehende E-Mails und nirgendwo sonst sichtbar war.
Der KI-Spam-Detektor hat diesen Spam bei neuen Konten abgefangen, war aber für dieses Vertrauenslevel und diese Beitragsanzahl nicht aktiviert. Vielleicht wäre es eine gute Idee, die Option zum Aktivieren des KI-Spam-Detektors für Länderänderungen und/oder wenn über ein Jahr lang keine Beiträge verfasst wurden, aufzunehmen.
Vielen Dank an alle für die großartige Software im Laufe der Jahre, trotz kleinerer Mängel wie diesem.
Alle diese Aktionen können auch über die Seite Admin > Benutzer ausgeführt werden. Ich bin mir nicht sicher, was Ihnen den Eindruck vermittelt hat, dass dies nur über die Konsole möglich ist?
Das Ändern der E-Mail-Adresse sendet zwar eine Bestätigungsaufforderung an die neue Adresse, entfernt aber die alte nicht sofort.
Der Button zum Deaktivieren des Kontos war möglicherweise richtig, aber es ist nicht klar gekennzeichnet, ob dies eine Passwortzurücksetzung per E-Mail erzwingt.
Ich konnte immer noch keinen Alle Sitzungen beenden-Button finden, und die Passwortänderung per Imponieren funktioniert theoretisch, ist aber sehr unübersichtlich, besonders wenn Benutzer ihr Konto auf eine Sprache eingestellt haben, die der Administrator/Moderator nicht spricht.
Wenn Sie plausible Gründe dafür haben, dass die E-Mail-Adresse eines Benutzers kompromittiert wurde und dies zur Kompromittierung seines Discourse-Kontos geführt hat, können Sie als Administrator deren E-Mail-Adresse ändern und die alte E-Mail-Adresse entfernen.
Sie können ein Konto einfach als deaktiviert markieren, was eine erneute E-Mail-Verifizierung erzwingt und im Wesentlichen alle vorhandenen Sitzungen beendet.
Nein, das habe ich versucht und konnte es nicht tun, weil eine Bestätigungs-E-Mail für die neue E-Mail-Adresse generiert wurde und solange diese nicht angeklickt wurde, war die alte noch in der Datenbank und wahrscheinlich gültig.
Ich habe dies absichtlich als Fehlerbericht/Funktionsanfrage eröffnet, um es möglicherweise später zu verbessern. Die konkrete Aufgabe ist bereits erledigt und der Benutzer hat sein Konto zurückerhalten.
Ich bin mir nicht sicher, ob dies ein Fehler ist. Meiner Meinung nach ist dies nicht einmal ein Randfall. Unvorsichtigkeit der Benutzer mit ihren Daten oder Identitäten ist kein häufiges Vorkommnis, und es sind genügend Schutzmaßnahmen vorhanden. Diesen Prozess einfacher zu gestalten, könnte mehr Nebenwirkungen haben. Dies ist nichts, womit sich Leute täglich auseinandersetzen sollten, und wenn die Situation kritisch genug ist, wissen Administratoren, wie sie Abhilfe schaffen können. Vielleicht könnte der Text etwas verbessert werden, aber definitiv nicht zugunsten des Hinzufügens weiterer Optionen zur Benutzeroberfläche.
Was spricht gegen eine Schaltfläche zum Abmelden von allen Sitzungen und zum Erzwingen einer Passwort- und E-Mail-Änderung? Habe das schon in anderer Software gesehen.
Ich habe kürzlich eine Funktionsanfrage für mehr Kontrolle über Benutzer-E-Mail-Adressen für Administratoren gestellt, die diesen Anwendungsfall ebenfalls abdecken würde:
Ja, kein häufiges Ereignis (glücklicherweise). Aber kritisch, wenn es (oder etwas Ähnliches) passiert und eine schnelle Reaktion erfordert. Nicht die Zeit, um zu lernen, wie man sich im Bash / in der Rails-Konsole zurechtfindet, oder um ein Support-Ticket zu eröffnen!
Aber die Deaktivierung des Kontos in der Zwischenzeit erfordert keine Navigation in der Rails-Konsole. In fast 10 Jahren der Verwaltung verschiedener Discourse-Communitys ist mir noch keine Situation untergekommen, die die Rails-Konsole erfordert hätte (abgesehen von der Migration von Communitys oder der Durchführung von Massenaktionen). Ich weiß die Tatsache zu schätzen, dass es Fälle geben mag, in denen Änderungen direkt an der Datenbank als die sicherere Wahl angesehen werden, um weiteren Schaden zu verhindern, aber ich bin mir nicht sicher, ob das Hinzufügen weiterer Optionen zu Benutzerprofilen oder Admin-Seiten sinnvoll ist, da beide bereits sehr überladen sind.
Ich bin mir auch ziemlich sicher, dass eine vom Administrator erzwungene Zusammenführung von Konten mit anschließender Löschung der anstößigen (jetzt nicht primären) E-Mail-Adresse wirksam wäre – und auch in anderen Situationen zur Erzwingung von E-Mail-Änderungen genutzt werden könnte. Aber das ist sehr viel ein Workaround.