Nachdem ein Thema als “Off-Topic” im Discobot-Thread markiert wurde, frage ich mich, ob die Discourse-Community diskutieren möchte, ob das Impersonieren von Benutzern mit einem einzigen Klick in Ordnung ist oder ob dies für bestimmte Szenarien reserviert werden sollte.
Aus meiner Sicht ist das so, als würde man die IP-Adresse oder die ID einer anderen Person verwenden. Das sind Verhaltensweisen, die nicht mit Ethik oder Moral vereinbar sind (noch vor rechtlich oder illegal).
Ich denke, das Gleiche gilt für das Impersonieren als Ein-Klick-Lösung, bei der Administratoren mit einem einzigen Klick wie andere Benutzer posten könnten.
Ich meine, um einige Dinge in Discourse zu ändern, muss man sich manuell in die App einloggen, Postgres verwenden und mit vielen Abfragen Daten bearbeiten.
Warum ist das Impersonieren so einfach, wenn es um einen Thread mit mehreren Perspektiven und unterschiedlichen rechtlichen Interessen geht?
Das ist wahrscheinlich den meisten Benutzern nicht bekannt, und wir alle wissen, dass Administratoren auf die Datenbank zugreifen und Dinge ändern können, aber das ist etwas völlig anderes, als auf einen Knopf zu drücken und wie ein anderer Benutzer zu posten.
Administratoren können Benutzer sperren und verbannen, wenn etwas Schlimmes im Forum vor sich geht, und sie sind rechtlich für die Website verantwortlich.
Als Entwickler ist Impersonate eine absolut brillant nützliche Funktion, die den Entwicklungsprozess unterstützt, sodass ich schnell aus einer Admin-Rolle in die Rolle eines neuen Benutzers wechseln kann, um zu überprüfen, was dieser sehen würde …
Ich denke, der Punkt ist, dass eine einfache (und stille) Identitätsübernahme die Erwartungen verletzen könnte, zumindest in einigen Communities.
Wir sollten dies nicht als rechtliche Angelegenheit betrachten – es ist eine Frage der Richtlinien und der Kultur, und es ist vielleicht die Art von Richtlinie, bei der ein Website-Administrator einen oder anderen Ansatz wählen könnte.
Manchmal ist es nützlich, sich auszugeben, aber vielleicht sollte die betreffende Person eine Benachrichtigung erhalten. Vielleicht könnte die betreffende Person für viele Fälle eine Anfrage zur Identitätsübernahme genehmigen.
Ehrlich gesagt, meiner Meinung nach ist die Funktion nicht notwendig und sollte entfernt werden. Aber ich bin sicher, das Team hat Gründe, warum sie da ist. z. B. Wechsel zu einem Testbenutzerkonto.
Was die Funktion betrifft, die zur Identifizierung verwendet wird, um sich als ein anderer Benutzer auszugeben, zumindest öffentlich könnte man einfach mit 3 Klicks die Eigentümerschaft ändern.
Fazit: Nur gut ausgewählte Administratoren einsetzen.
Dies könnte problematisch sein, da einige Administratoren nur die Benutzeroberfläche pflegen, wie im Fall von @pfaffman mit Kunden. Da alle Administratoren volle Berechtigungen haben, aber Dinge außerhalb ihres Jobs nicht nutzen. Wie erwähnt, muss man die Gesetze seiner Region prüfen; es könnte jedoch sein, dass man vorsichtig sein muss, wenn man reist.
Dadurch wird die vorgeschlagene API eingeführt, um einem Benutzer teilweise Administratorfunktionen zu gewähren, die ein Designer/Wartungstechniker benötigt.
Wahr, aber das könnte durch die Verwendung von speziell erstellten Testkonten geschehen. Hier kommt es auf die Integrität des Endbenutzers an. Dies könnte, wie der Ersteller des Threads vorschlägt, missbraucht und korrumpiert werden.
Ich werde an die Warnung in Linux erinnert, wenn der Befehl sudo zum ersten Mal verwendet wird:
Wir vertrauen darauf, dass Sie die übliche Vorlesung vom lokalen Systemadministrator erhalten haben. Sie läuft normalerweise auf diese drei Dinge hinaus:
#1) Respektieren Sie die Privatsphäre anderer.
#2) Denken Sie nach, bevor Sie tippen.
#3) Mit großer Macht kommt große Verantwortung.
Das heißt, bei der erstmaligen oder jeder Verwendung von Impersonate könnte ein Administrator mit einem Klick-Dialog mit einer Nachricht über den Respekt der Privatsphäre und Integrität präsentiert werden.
Die impersonate-Funktion ist eine gute Sache, wenn man einen Moment darüber nachdenkt, aber nicht nur aus den bereits genannten Gründen.
Impersonate protokolliert seine Nutzung im Admin-Log. Sicher, ein Admin könnte den Eintrag mit der Rails-Konsole oder einer direkten SQL-Abfrage in Postgres löschen, aber das hinterlässt seine eigene Spur (eine Lücke in den Log-IDs, die andere Mitarbeiter sehen, wenn sie danach suchen).
Das Fehlen von impersonate würde Admins aktiv dazu ermutigen, die weitaus finsterere Alternative zu missbrauchen, die nicht protokolliert wird, und ich vermute, jeder Entwickler, der das gerade Geschriebene liest, hat bereits erraten, was ich als Nächstes sagen werde.
Möchten Sie einen einzigen Log-Eintrag, der leicht versteckt werden kann und sogar Monate im Voraus erstellt wird, damit andere Forenmitarbeiter die beiden nicht in Verbindung bringen? Sie erstellen einen API-Schlüssel für alle Benutzer. 1 Log-Eintrag, und Sie tun, was Sie wollen, als wer Sie wollen, wann Sie wollen, und solange es sich nicht um etwas handelt, das normalerweise für den Benutzer, als der Sie handeln, protokolliert würde, würde es keine Spur hinterlassen.
Sie sind oft Testkonten in einer Entwicklungsumgebung, aber die Einrichtung von Testkonten in der Entwicklung ist zusätzliche Arbeit. Dies erspart Ihnen das Ab- und Anmelden, was Ihren Arbeitsablauf verlangsamt und besonders ärgerlich ist, da Sie mehrere Passwörter einrichten müssen, was keine angenehme Erfahrung ist, Sie verlangsamt und in der Entwicklung keinen Mehrwert bietet. Mit Impersonate müssen Sie sich nur das Admin-Passwort merken.
Ich zeige lediglich einen zusätzlichen Vorteil dieser Funktionalität für diesen speziellen Anwendungsfall auf.
Das Erstellen von Testkonten dauert wirklich keine Zeit und in dieser Idee wären sie ein Standardbestandteil der Discourse-Installation, ähnlich wie Discobot und System. Die Funktion “Impersonate” würde beibehalten, sie würde nur mit sagen wir 3 oder 4 leeren Testkonten funktionieren, die modifiziert werden könnten, um Benutzer verschiedener Ebenen zu simulieren.
Wie bereits erwähnt, werden Personen mit hohen Werten und Integrität Impersonate möglicherweise nicht für böswillige Zwecke verwenden. Obwohl die Nutzung verlockend ist. Außerdem könnten Mitglieder einer Website, die wissen, dass der Administrator ihr Konto verwenden könnte, um sie zu impersonieren, das Vertrauen in die Plattform verlieren. Derzeit verlässt sich Impersonate ausschließlich auf die Integrität und hat keine optionale Lösung im Gegensatz dazu, wie das “Encrypt Plugin” die Probleme von Benutzern eines Discourse-Forums behebt, um PM/DM privat zu machen, wie es Emd-Benutzer eines Forums erwarten, es sei denn, es wird klar dargelegt, dass DM/PM nicht sicher und privat sind, wie es die erwartete Funktionalität einer Community ist. Auf der Plus-Seite habe ich speziell gefragt, ob Impersonate verwendet werden könnte, um das Encrypt Plugin zu umgehen, woraufhin Sam erklärte und bestätigte, dass es den Schutz nicht umgehen könnte, da es sich um eine Ende-zu-Ende-Verschlüsselung handelt.
Das stimmt nicht. Das Erstellen von Testbenutzern ist jedes Mal eine Qual. Ich erstelle oft frische Entwicklerinstallationen und führe zur Beschleunigung die Entwickler-Fixtures aus. (Diese Fixtured-Benutzer haben meines Wissens keine bekannten Passwörter) Dann muss ich nur noch ein Administratorkonto hinzufügen, und die Personifizierung ermöglicht es mir, schön zwischen den Benutzeroberflächen zu wechseln. Job erledigt.
Ich bin etwas perplex über deine Negativität hier … Ich habe die Plattform einfach für eine nützliche Einrichtung gelobt, die ich regelmäßig bei meiner Arbeit nutze. Jetzt greifst du diese Funktionalität und meinen Ansatz an, mit dem Ziel, was? Um uns das Leben schwerer zu machen? Ich weiß nicht, ob ich das sehr schätze!
Was ist wirklich das Problem mit der „Impersonate“-Funktion? Warum macht ihr Leute aus einer Mücke einen Elefanten? Jedenfalls ist diese Funktion recht nützlich und selbst große Tech-Unternehmen nutzen diese Funktionen, wenn man über Datenschutz spricht, dann kann der Administrator alles sehen und mit den Website-Inhalten alles machen, Google, Facebook und all die großen Tech-Unternehmen tun das. Das ist sowieso nichts Neues.
Und warum sollte ein Entwickler ein Konto erstellen, wenn das Problem beim Benutzer liegt? In diesen Fällen ist diese Funktion recht nützlich. Wenn Sie ein Problem haben, dann nutzen Sie sie nicht.
Ich greife sie überhaupt nicht an. Ich weise lediglich darauf hin, dass es sich um eine leicht missbrauchbare Funktion handelt, die eine Fülle von Problemen verursachen kann. Das Einbacken von Testkonten zur direkten Nutzung behebt den potenziellen Missbrauch, da sie nicht verfügbar ist. Was die Erstellung eines Testkontos betrifft. Ich habe einen zweiten Tab geöffnet, ein Konto mit einer gefälschten Nicht-E-Mail-Adresse erstellt und bin zu meinem angemeldeten Admin-Konto zurückgetabbt und habe es validiert.
Impersonate ist definitiv ein nützliches Werkzeug, das, wenn Standard-Testkonten oder eine Admin-Option im Admin-Panel null Konten erstellen könnten, die mit Impersonate verwendet werden können. Dies würde den potenziellen Missbrauch schließen.
Wie bereits erwähnt, wenn eine Community darauf aufmerksam gemacht wird, dass Staff Accounts sie impersonieren können, vertraut sie der Community-Plattform möglicherweise nicht.
Nach allem, was ich von dir und einer Fülle anderer großartiger Leute hier gelesen habe, würden sie die Funktion wahrscheinlich nie missbrauchen. Aber die offene Funktionalität dieser Funktion könnte dazu führen, dass Communities Discourse als Forenplattform weniger vertrauen.
Eine offene Diskussion sollte nicht als negativ angesehen werden, indem Vor- und Nachteile abgewogen werden.
Sam’s Encrypt Plugin verhindert, dass Administratoren und Moderatoren Direktnachrichten/Privatnachrichten einsehen können, ähnlich wie Apps wie WhatsApp damit werben, dass sie keine Gespräche einsehen können, es sei denn, sie werden eingeladen. Das schließt also die Funktion zum Anzeigen von Direktnachrichten/Privatnachrichten aus, die möglicherweise als Verletzung der erwarteten Privatsphäre angesehen wird, die nicht klar angegeben ist, dass sie nicht wirklich privat sind.
Das ist völlig unerheblich. Wenn Sie wirklich private Mitteilungen von Benutzern lesen möchten, können Sie als Administrator in die Datenbank schauen (es sei denn, Sie aktivieren die Verschlüsselung).
Als Website-Besitzer haben Sie auf jeden Fall Zugriff auf alles, können beliebige Änderungen vornehmen, die Verschlüsselung ein- und ausschalten, was auch immer.
Wenn Sie ein Drittanbietersystem als Benutzer verwenden, haben Sie keine direkte Kontrolle darüber, was Leute mit Ihren Daten tun können.
Ich streite jedenfalls nicht über die Produktion, mein Punkt war nur, dass diese Funktionalität auch in der Entwicklung Vorteile hat und diese leicht zu demonstrieren sind.
Aus meiner Sicht also +1 dafür. Jetzt bin ich zu beschäftigt, um das weiter zu diskutieren. Einen schönen Tag noch.
Dann benutze Google, Facebook, Microsoft und alle anderen nicht, da sie alle es tun. Sie sagen nicht offen, dass sie dich „imitieren“ können. Sie können alles tun, was du dir vorstellen kannst, aber trotzdem vertraust du ihnen und benutzt sie immer noch, obwohl du weißt, dass sie alles tun können. Ich weiß also nicht, was wirklich das Problem ist, Mann. Vielleicht machst du dir Sorgen um deine Forenmoderatoren und Administratoren, aber trotzdem werden alle Aktionen protokolliert, wenn ein Administrator die „Impersonate“-Funktion verwendet. Ich kann also nicht verstehen, wo das Problem liegt. Wenn diese Funktion problematisch wäre, hätte das Discourse-Team sie nicht an erster Stelle eingeführt.
Was natürlich seinen Reiz hat. Aber diese Funktion in einer Produktionsumgebung verfügbar zu haben, ist riskant.
Was also großartig wäre, wäre, wie bei anderen Funktionen, diese Funktion so anzupassen, dass sie auf dem Root-Server eingeschaltet sein muss.
Ich sehe durchaus, wie sie in einer Entwicklungsumgebung von Wert sein kann, da sich die Benutzer dort wahrscheinlich bewusst sind, dass es sich um eine Testumgebung handelt.
Ich habe bereits erwähnt, dass Verschlüsselung verwendet werden kann, um diese offene Funktion zu schließen.
