Ich bin sowohl Administrator als auch Teilnehmer auf den Fedora-Diskussionsseiten. Ich möchte diese Rollen trennen können. Ich weiß, dass es die „Mitarbeiterfarbe“ für offizielle Beiträge gibt, aber ich meine eher von meiner Seite aus. Anstatt überall Admin-Schraubenschlüssel und Schaltflächen zu haben, wenn ich angemeldet bin, hätte ich gerne einen Menüschalter, der den Admin-Modus ein- und ausschaltet.
Wir haben auch
Diese Plugins ermöglichen es Ihnen, Ihre Identität als Staff-Mitglied zu verschleiern. D.h. Sie können einen Beitrag von einem ‘offizieller’ aussehenden Konto aus erstellen, der nicht offensichtlich auf Sie als Einzelperson zurückgeführt werden kann.
Ich glaube jedoch nicht, dass das ganz das ist, wonach Sie fragen? Sie möchten eine Möglichkeit, Discourse so aussehen/sich so anfühlen zu lassen, wie es für normale Benutzer ist, und dann in den “Sudo-Modus” wechseln, um alle zusätzlichen Admin-Funktionen verfügbar zu machen?
Ich denke, es wäre wahrscheinlich ziemlich schwierig zu implementieren… aber es wäre ziemlich großartig! Vor vielen Jahren (bevor ich dem Team beitrat) habe ich diese Komponente für mein eigenes selbst gehostetes Forum erstellt. Sie hat die gleiche Idee (reguläre/Admin-Privilegien offensichtlich machen), ist aber auf einen sehr spezifischen Fall beschränkt:
Wenn es andere eng gefasste Fälle gibt, die auf Ihrer Website oft verwirrend sind, wäre es möglich, ähnliche Theme-Komponenten zu erstellen, um Warnungen anzuzeigen, bevor Admin-Aktionen durchgeführt werden.
Ja, genau. Ich vermute, das liegt teilweise an jahrelanger Erfahrung als Systemadministrator, bei der mir die Idee des „geringsten notwendigen Privilegs“ durch praktische Erfahrung eingeimpft wurde. (Ein falscher rm -rf-Befehl als Root auf einem Produktionssystem ist eine Art Initiationsritus!)
Das ist auch für mich von Interesse. Meine aktuelle Problemumgehung besteht darin, sowohl Chrome als auch Edge zu verwenden. In Chrome habe ich mein Admin-Konto, aber in Edge bin ich im Admin-Konto und gebe mich als Benutzerkonto mit einer abgelaufenen E-Mail-Adresse aus. Die Identifizierung erfolgt nur, weil ich nicht mit der IT sprechen möchte.
In Ihrer Situation könnten Sie eine zweite Anmeldung erstellen und einen Browser für den Administrator und einen Browser für den Benutzer haben. Nicht perfekt, aber für mich war es gut genug.
Hier ist ein gutes Beispiel dafür, wo dies nützlich wäre:
Ich möchte nicht versehentlich beabsichtigte Tagging-Regeln verletzen können. (Können Nicht-Admin-Moderatoren dies auch versehentlich tun? Ich kann es nicht einmal leicht testen.)
Ich könnte ein separates Admin-Konto erstellen und mein Hauptkonto zu einem normalen Benutzer herabstufen, aber ich befürchte, dass ich wichtige Flaggen-Benachrichtigungen und Nachrichten verpassen würde.
Dies wird vom Browser selbst gehandhabt, siehe
Das sieht so aus, als könnte ich damit ganze Browserprofile tauschen? Das scheint nicht zu helfen, es sei denn, man legt ein komplett anderes Discourse-Benutzerkonto für die Administratorverwendung an.
Oder übersehe ich etwas. Zum Beispiel ist Ihr Konto als Administrator aufgeführt hier, @codinghorror, daher gehe ich davon aus, dass Sie gerade im Administrator-Modus laufen, es sei denn, Sie tun etwas, das ich völlig missverstanden habe. Aber Sie agieren auch als Seitenbenutzer. Laufen Sie nicht in Dinge, wo Sie (zum Beispiel) versehentlich Beiträge erstellen, die nicht den konfigurierten Tag-Regeln folgen? (Das ist mir schon mehr als einmal versehentlich passiert…)
Nicht wirklich – Teil der Rolle eines Administrators ist es, die Verantwortung zu verstehen, die man hat, und die Grenzen, die man respektieren muss. Wenn man das nicht kann, sollte man keine Administratorrechte haben.
Aber ich habe auch Verständnis für Leute, die extrem vorsichtig sein wollen, und ich empfehle ihnen, zwei Konten zu verwenden und sich als normaler Benutzer anzumelden, wenn sie absolut sicher sein müssen. Und mit der integrierten Unterstützung für Browserprofile ist das sehr einfach zu bewerkstelligen.
Nun, es ist so ähnlich wie ständig als Root auf einem Linux-System zu laufen. Es geht nicht nur darum, Grenzen zu respektieren, sondern auch darum, nicht versehentlich über sie zu stolpern, wenn man nicht merkt, dass sie da sind. Einige Dinge, wie das Aufrufen der Einstellungen, werden nicht versehentlich passieren, aber es scheint eine Menge kleiner Dinge zu geben, bei denen der Administrator die Konfiguration umgeht, ohne jeglichen Hinweis darauf, dass etwas umgangen wird.
Wie oben gesagt, ist ein zweites Konto nicht wirklich gut, da ich die Benachrichtigungen dieses Kontos nur selten sehen würde.
Ich verstehe die Bedenken, aber in der Praxis ist es kein großes Problem, zumindest nicht über die 10 Jahre, in denen ich an diesem Projekt arbeite.
(Beachten Sie auch, dass wir den Zugriff von Mitarbeitern automatisch widerrufen und eine erneute E-Mail-Validierung für abwesende Mitarbeiter verlangen, was meiner Meinung nach die meisten dieser Probleme automatisch behebt)
Hallo Matt!
Um das Ganze etwas anschaulicher zu gestalten: Die Möglichkeit für einen Administrator, als regulärer Benutzer zu agieren, würde der gesamten administrativen Autorisierungslogik eine zusätzliche Dimension verleihen.
Obwohl diese Logik größtenteils in guardian.rb und /lib/guardian/*.rb zentralisiert ist, wäre die Komplexität und das Fehlerrisiko einer solchen Änderung sehr groß. Die Notwendigkeit dieser Funktion müsste dies bei weitem überwiegen, was angesichts der Alternativen nicht der Fall ist.
Wäre es möglich, gezielteren „Schutz“ für einige der eher zufällig möglichen Dinge in Betracht zu ziehen? Wie eine Einstellung: „Mitarbeiter müssen die Regeln für die Kategorisierung befolgen“? Ehrlich gesagt würde allein das die meisten der praktischen Probleme lösen, auf die ich stoße.
Oder… finden Sie es irgendwie seltsam, dass andere Dinge wie die Beitragslänge immer noch geschützt sind, selbst für Administratoren… vielleicht ist gerade diese spezielle Sache eher eine Frage der Funktionsweise als des Hinzufügens einer Option?
Das Hinzufügen einer Beitragslänge würde eine Änderung der gesamten Datenbank erfordern. Es gibt eine maximale Anzahl von Zeichen, die wir pro Feld in der Datenbank speichern können.
Das kommt mir wie ein Non sequitur vor, aber vielleicht übersehe ich etwas. Ich meine:
- Wenn ich ein Administrator bin und versuche, einen Beitrag zu posten, der kürzer als die
min post lengthist, erhalte ich die normale Fehlermeldung und kann nicht fortfahren. - Wenn ich ein Administrator bin und versuche, ohne Tags in einer Kategorie zu posten, die einen erfordert, lässt es mich einfach fortfahren.
Was wird hier in der Datenbank gespeichert?
Oh Entschuldigung, ich meinte nur die Länge von Beiträgen/Titeln – es gibt eine maximale Länge für den Inhalt eines Beitrags in dem Datenbankfeld, in dem er gespeichert wird. Es gibt eine ähnliche Regel für den Beitragstitel, eine maximale Anzahl von Zeichen, die für dieses spezielle Feld in der Datenbank vorgesehen ist.
Wenn also ein Administrator entscheiden würde: „Hey, ich möchte einen Beitrag mit 900.000 Zeichen“ oder „Hey, ich möchte einen Beitrag mit einem 500 Zeichen langen Titel“, ist das ohne Änderung der Datenbank nicht möglich.
Es ist wirklich eine technische Kleinigkeit, aber da Sie die Beitragslänge erwähnt haben, habe ich darüber nachgedacht.
Ah OK. Ja, das ist genau das Gegenteil von dem Problem, das mich beschäftigt ![]()
Ich gehe davon aus, dass der OP beabsichtigte, die meiste Zeit als normaler Benutzer zu arbeiten. Ich möchte mich auch wie ein einfacher Benutzer fühlen:
- weniger Schaltflächen
- kein Zugriff auf Moderations-/Admin-Aktionen
- einfache Anwendungsfälle verwenden
Nach Upgrades oder Abstimmungen möchte ich mit dem Forum als normaler Benutzer interagieren, um Missverständnisse zu vermeiden.
Für meine Community ist der Admin-Modus nur für Upgrades oder Tests mit Plugins und Benutzeroberflächen erforderlich. Ich muss auch nicht die ganze Zeit Moderator sein. Außerdem denke ich, dass für manche Leute wie mich das vorübergehende Wechseln zum Admin besser ist, als zwei Konten zu haben.
Der OP schrieb über sudo. Das ist fast dasselbe, aber umgekehrt. Normalerweise wechsle ich vorübergehend zu anonym, um einige Fälle zu überprüfen. Es wäre jedoch großartig, eine einfache Option zu haben, den Admin-Modus wie ‘impersonate’ unter einem speziellen normalen Konto zu aktivieren.
Das erinnert mich an etwas, das vor ein paar Tagen passiert ist. Ich bin gerade dabei, ein Forum zu migrieren.
Ich habe dem Administrator des alten Forums Administratorrechte verliehen.
Er ist Discourse-Nutzer auf zwei anderen Foren und auch Moderator. Er kennt sich also ein wenig mit der Discourse-Oberfläche und Navigation aus.
Von seinem Admin-Konto aus (ich habe ihm keine Richtlinien geschrieben, ich ließ ihn Dinge entdecken) sagte er mir, er sei überrascht gewesen, dass er direkten Zugriff auf Nachrichten anderer Leute hatte; Er klickte etwas zufällig auf eine öffentliche Profilseite und sah eine Liste von Direktnachrichten, was ihn überraschte.
Er sagte mir, er habe plötzlich gedacht: „Oh, es scheint, als wäre ich irgendwo, wo ich nicht sein sollte“ (zu verstehen als: Er sollte hier nicht sein, wenn er gerade keine administrativen/moderatorischen Aufgaben hat).
Er hat keine Ahnung, dass er über die Benutzeroberfläche so einfach auf diese Nachrichten zugreifen kann, wie man von seinem Profil aus auf seine eigenen Direktnachrichten zugreift.
Und das ist mir auch vor ein paar Wochen passiert, obwohl ich seit 2018 Administrator von zwei Discourse-Foren bin… ![]()
Meiner Meinung nach sollte auf dem Tab „Direktnachricht“ im öffentlichen Profil eines Nutzers als Admin ein Symbol oder eine Art Warnung angezeigt werden, dass das Anklicken eine Moderations- oder Administrationsaktion ist, da man Dinge sieht, die (in den Köpfen von 99 % der Nutzer) „privat“ sind. ![]()
Also… ich habe darüber nachgedacht und bin weniger davon überzeugt, dass es sich doch um eine große Änderung handelt. Sicher, es gibt viel verstreute Logik, aber läuft nicht alles darauf hinaus, is_admin oder is_staff zu überprüfen?
Der „sudo“-Befehl müsste lediglich einen „staff_mode“-Schalter hinzufügen, und die Funktionen is_staff und is_admin könnten den Zustand dieses Schalters UND das Flag user.admin oder user.staff überprüfen. (Natürlich müsste die Aktivierung des Schalters eine spezielle Prüfung beinhalten, die nur den Wert user.admin oder user.staff betrachtet.)