Admins immer in der Lage sein, E-Mails zu bearbeiten, auch wenn „E-Mail nach der Anmeldung bearbeiten

Beitragen Merkmal
1

Bearbeitet, um wesentliche Klarstellungen vorzunehmen und die Kriterien für die Vorschläge besser durchdacht zu gestalten, um anderen Community-Mitgliedern zu helfen, den Nutzen dieser Funktionsverbesserung zu verstehen.

Aktualisieren Sie die Einstellung E-Mail bearbeitbar, um zusätzliche Optionen dafür bereitzustellen, wer E-Mail-Adressen bearbeiten darf. Die Einstellung ist beispielsweise wie folgt konzipiert:

  • Alle Benutzer
  • Nur Benutzer [Normale Administratoren oder Moderatoren können dies nicht ohne Verwendung der Rails-Konsole oder Änderung der Einstellung tun.]
  • Nur Mitarbeiter
  • Nur Administratoren

Wenn die Einstellung aktiviert ist (was standardmäßig der Fall ist), führen Sie eine Sudo-Modus-Sicherheitsmaßnahme ein, um die Aktion als Administrator durchzuführen (nicht als der Benutzer, dem das bearbeitete Konto gehört). Dies ermöglicht die Einführung dieser Einstellung mit einigen wichtigen Punkten, die unten erwähnt werden, um sie gegen unerwünschte Änderungen zu schützen.

Begründung/Warum dies erforderlich ist

Wenn Sie die Einstellung deaktivieren möchten, weil Sie entweder die Kontrolle darüber haben möchten (z. B. müssen Änderungen beantragt werden, Sie tun dies aus Sicherheitsgründen oder aus einem anderen Grund), aber aus irgendeinem Grund die E-Mail bearbeiten müssen: Mit dieser Einstellung deaktiviert können selbst Administratoren die E-Mails nicht bearbeiten.

Genau hier entsteht ein neues Problem, wenn einer oder mehrere Anwendungsfälle zutreffen.

Um derzeit E-Mails für Benutzer zu bearbeiten, können Sie entweder 1) die Einstellung in einem anderen Tab aktivieren und die E-Mail schnell bearbeiten, oder 2) die Rails-Konsole öffnen und die E-Mail manuell ändern.

Für die meisten regulären Administratoren im Tagesgeschäft kann dies zu einer unerwünskten technischen Herausforderung führen, wenn Sie sich ausschließlich darauf verlassen, alles in der Rails-Konsole zu erledigen, obwohl die Einstellung existiert.

Warum zusätzliche Sicherheitsmaßnahmen helfen könnten, diese Funktion Wirklichkeit werden zu lassen:

  • Wenn sie aufgrund technischer Implikationen aktiviert bleibt, könnten kompromittierte Benutzer ihre E-Mails geändert bekommen.
  • Administratoren könnten Fehler machen oder unbefugte Änderungen vornehmen.
  • Benutzer werden das Gefühl haben, dass diejenigen mit diesem Zugriff vor böswilligen Änderungen geschützt sind.

Dies wurde zuletzt in 2015 diskutiert. Und obwohl es wahr ist, dass Sie E-Mails bearbeiten können, können Sie sie nicht in der Administrationsansicht bearbeiten. Es wird Ihnen mitgeteilt, dass Sie zur Ansicht der Benutzereinstellungen wechseln sollen, was ich tue, und selbst als Administrator kann ich dies aufgrund der Einschränkungen dieser Einstellung nicht tun.

image
image1025×291 11.5 KB

1 „Gefällt mir“
2

Ja, ich stimme dem hier sehr stark nicht zu. Auch wenn dein konkreter Anwendungsfall für dich vielleicht einfach genug erscheint, würde die Implementierung einer einfachen Überschreibung in der Benutzeroberfläche ein erhebliches Sicherheitsrisiko für einen nur geringfügigen Komfortgewinn einführen.

Der Widerstand ist ein Sicherheitsfeature!

Die Unannehmlichkeit, die Rails-Konsole nutzen oder eine siteweite Einstellung umschalten zu müssen, ist tatsächlich ein kritisches Sicherheitsfeature, da sie als „Sicherheitsbremse

1 „Gefällt mir“
3

Danke für die Besorgnis, aber ich glaube, du verstehst die gesamte Situation hier falsch. Dein Argument zur „Sicherheit“ enthält eine erhebliche Lücke.

Du kannst die E-Mails bereits bearbeiten, wenn diese Einstellung aktiviert ist; und das ist standardmäßig der Fall.

Kompromittierung von Admin-Konten! – Dies ist das größte Risiko. Wenn ein Angreifer Zugriff auf ein Admin-Konto erlangt (durch Phishing, Wiederverwendung von Passwörtern usw.), würde ihm ein einfacher Button oder Schalter in der Benutzeroberfläche erlauben, still und einfach jedes andere Benutzerkonto zu übernehmen, einschließlich der Konten anderer Mitarbeiter. Die Anforderung, über die Rails-Konsole Shell-Zugriff zu haben, bietet eine starke Sicherheitsebene.

Wenn ein Admin-Konto kompromittiert ist, könnte der Eindringling einfach die Einstellung, die es heute bereits gibt, aktivieren und die von dir genannten Dinge tun.

Das Ändern der E-Mail-Adresse eines Benutzers ist gleichbedeutend damit, ihm die Schlüssel zu seinem Konto zu übergeben, da die neue E-Mail-Adresse genutzt werden kann, um ein Zurücksetzen des Passworts auszulösen. Dadurch wird der ursprüngliche Benutzer effektiv ausgesperrt, und der neue E-Mail-Inhaber erhält die vollständige Kontrolle.

Für diese Art von seltenen, hochriskanten administrativen Aktionen ist die Rails-Konsole angemessen, da sie sicherstellt, dass die Person, die die Aktion durchführt, Serverzugriff hat und nicht nur über eine kompromittierte Sitzung verfügt. Außerdem ist die Aktion bewusst und erfordert spezifisches technisches Wissen (und sie wird in der Shell-Historie protokolliert).

Nicht immer, und wie ich bereits im Eröffnungspost erwähnt habe: Du kannst die Einstellung einfach ein- und ausschalten, um die Bearbeitungsfunktion zu aktivieren. Das einzige Problem ist, dass das Umschalten der Einstellung, die standardmäßig [von Haus aus] aktiviert ist, die Möglichkeit einführt, dass Benutzer, die keine Admins sind, ihre E-Mail-Adresse bearbeiten können, während eine einfache Bearbeitung stattfindet.

1 „Gefällt mir“
4

Okay, ich verstehe jetzt Ihren Punkt bezüglich des Umschaltens dieser Einstellung.

Ich bin immer noch fest der Meinung, dass die Rails-Konsole hier der richtige Weg ist. Vielleicht ist auch ein Plugin möglich.

5

Wenn die Einstellung AKTIVIERT ist

„Benutzern das Ändern ihrer E-Mail-Adresse nach der Registrierung erlauben"

Dies ermöglicht die Bearbeitung für ALLE Benutzer (und Administratoren). Die einfache Funktionsanforderung lautet: Die Einstellung soll für folgende Optionen verfügbar sein – zum Beispiel: „Nur Administratoren, Administratoren + Benutzer oder Benutzer"

Wenn ich es einfach **„aktiviere

1 „Gefällt mir“
6

Okay, bei genauerer Überlegung scheint ein sudo-ähnlicher Ansatz mit hoher Hürde in der Benutzeroberfläche der richtige Weg zu sein, da diese Einstellung für das Bearbeitungsfenster als „unsicher

1 „Gefällt mir“
7

Ja, das Feature braucht definitiv etwas Liebe und Updates. Wenn man es aktuell aktiviert, kann ein Administrator als Admin die E-Mail-Adresse jedes Benutzerkontos bearbeiten, ohne zusätzliche Schutzmaßnahmen. Deine Idee mit 2FA oder einem Passwort gefällt mir gut.

1 „Gefällt mir“
8

Danke, dass du mich zum Nachdenken über die Funktion „bearbeitbare E-Mail“ angeregt hast. Das ist eine interessante und etwas komplexe Diskussion! :slight_smile:

1 „Gefällt mir“
9

Ich habe eine Bearbeitung am ursprünglichen Beitrag vorgenommen, um die Formulierung erheblich zu verbessern und die zusätzlichen Vorschläge zum Absichern der Änderung hinzuzufügen :wink: Ich denke, das wird die Sache insgesamt deutlich verbessern.

1 „Gefällt mir“
10

Ich frage mich, wann das geändert wurde. Im Laufe der Jahre habe ich Konten von Mitgliedern repariert, indem ich als Administrator die E-Mail-Adresse geändert habe. Das ist praktisch, um ein Konto zu reparieren, wenn ein Moderator ein Mitglied skrupellos oder versehentlich anonymisiert hat.

Kann dies also in der app.yml-Datei behoben werden, um den Admin-Zugriff in der Benutzeroberfläche wiederherzustellen? Administratorkonten sollten ordnungsgemäß gesichert sein, wenn man sorgfältig arbeitet.

Das sei gesagt: Discourse sollte eine Admin-Stufung für eine bessere granulare Kontrolle von Admin-Funktionen ermöglichen. (Alte Diskussion). Ein Top-Admin-Konto ist ideal, um volle Macht/Kontrolle zu haben. Während andere möglicherweise nur Zugriff auf das Theming benötigen.

1 „Gefällt mir“
11

Dies war ein Bedenken, das aufkam, als die Funktion „Imitieren“ entdeckt wurde. Sicherlich kann argumentiert werden, dass sie nützlich sein kann, um Benutzerprobleme zu beheben. Oder um zu Testzwecken zu Testkonten zu wechseln und Funktionen als normaler Nutzer zu testen; aber es ist sehr einfach, Tabs/Fenster zu verwenden, um Testbenutzer angemeldet zu halten.

Eine einfache, kluge Lösung wäre, eine Sicherheitsvorkehrung ähnlich wie unter Linux hinzuzufügen, bei der bestimmte Aktionen als Administrator ein zusätzliches Site-Passwort erfordern. Zum Beispiel die Änderung der Benutzer-E-Mail-Adresse.

1 „Gefällt mir“
12

Ist die Site-Einstellung email_editable auf deiner Site aktiviert? Standardmäßig ist sie aktiviert, sodass das Ändern der E-Mail-Adresse kein Problem darstellt. Wenn die Einstellung jedoch deaktiviert ist, wird es problematisch.

1 „Gefällt mir“
13

Ich habe gerade nachgesehen. Meine Seiten erlauben Admins keine Bearbeitung mehr. Offensichtlich hat ein Update dieses Verhalten geändert. Regelmäßige Benutzer durften E-Mail-Adressen ohnehin nicht ändern, aber als Admin habe ich das in der Vergangenheit bereits für verloren gegangene E-Mail-Konten vorgenommen und auch, als ich einen schlechten Moderator hatte, der Leute anonymisierte, mit denen er nicht einverstanden war (dieses Problem ist gelöst, da dieser Mitarbeiter zu einer anderen Firma gewechselt ist).

Die Änderung von E-Mail-Adressen durch Admins sollte eine separate Einstellung sein, nicht für alle Benutzer aktiviert. Selbst wenn es zunächst in der Konsole geändert werden muss, um dies für Admins zu aktivieren.

14

Genau das hat dazu geführt, dass dieser Vorschlag aufgekommen ist – denn ich möchte nicht, dass Mitglieder ihre E-Mail-Adressen selbst bearbeiten können. Ich bevorzuge es, eine Admin-Überprüfung beizubehalten. Das Deaktivieren dieser Bearbeitungsfunktion für E-Mail-Adressen betrifft jedoch alle Benutzer, einschließlich Administratoren, und nicht nur normale Mitglieder.

Ursprünglich hatte ich vorgeschlagen, Administratoren die Änderung unabhängig von der Einstellung zu ermöglichen, habe den Vorschlag aber aufgrund der ersten Antworten strukturierter angepasst.

1 „Gefällt mir“