Granulare gruppenbasierte Berechtigungen für anonyme und angemeldete Benutzer

[martin (Martin Brennan)]

In unserem Codebase gibt es historisch bedingt eine verwirrende Pseudogruppe namens @everyone, die für Folgendes verwendet werden kann:

• Site-Einstellungen vom Typ group_list
• Kategorienberechtigungen
• Tag-Gruppen

In einigen Fällen wird @everyone von einigen als „alle anonymen und alle angemeldeten Benutzer“ interpretiert, während andere es nur als „alle angemeldeten Benutzer“ verstehen. In der Realität bedeutet es für Site-Einstellungen jedoch in den meisten Fällen nur „alle angemeldeten Benutzer“.

Verwirrend wird es zusätzlich dadurch, dass diese @everyone-Gruppe auch bei Site-Einstellungen verwendet werden kann, bei denen es keinen Sinn ergibt, dass „alle anonymen und angemeldeten Benutzer“ Zugriff auf die Funktion haben, wie beispielsweise pm_tags_allowed_for_groups.

Dies ist auch aus der Perspektive des Feature-Flaggings und der Entwicklererfahrung verwirrend, da wir für einige anstehende Änderungen oder andere Einstellungen möglicherweise wirklich möchten, dass sie für „alle anonymen und angemeldeten Benutzer“ aktiviert werden.

Lösung

Wir führen zwei separate automatische Pseudogruppen ein:

• anonymous_users (ID 4) – Repräsentiert anonyme Benutzer, die Ihre Site ohne Konto besuchen
• logged_in_users (ID 5) – Repräsentiert alle angemeldeten Benutzer Ihrer Site, ähnlich wie die automatische Gruppe trust_level_0, aber spezifischer

Diese wurden bereits eingeführt, treten jedoch erst in Kraft, wenn die bevorstehende Änderung granular_anonymous_and_logged_in_groups_permissions auf Ihrer Site aktiviert ist.

Wenn die bevorstehende Änderung aktiviert ist, wird jede Einstellung, bei der everyone als ausgewählte Gruppe festgelegt ist, automatisch in die ID logged_in_users übersetzt. Daher werden beim Umschalten der bevorstehenden Änderung keine Daten in der Tabelle der Site-Einstellungen geändert. Sobald die bevorstehende Änderung dauerhaft wird, führen wir eine Datenmigration für alle Gruppeneinstellungen durch, um diese Änderung vorzunehmen.

Zusätzlich haben wir anonymous_users für mehrere Site-Einstellungen, bei denen es keinen Sinn ergibt, als disallowed_group markiert, beispielsweise für personal_message_enabled_groups.

Konflikte mit bestehenden Gruppennamen werden automatisch gelöst, indem die bestehenden Gruppen umbenannt und Erwähnungen von Gruppen in Beiträgen aktualisiert werden.

Was ist mit Tag- und Kategorienberechtigungen?

Diese Berechtigungen bleiben unverändert, da ihr Konzept von „everyone“ in einigen Punkten anders ist und nicht auf der zugrunde liegenden automatischen Gruppe basiert.

[Jagster (Jakke Flemming)]

Warte… was? Bedeutet das, dass alle Kategorien, die jetzt öffentlich (für alle) sind, zu geschlossenen Kategorien werden, die eine Anmeldung erfordern, sobald dies aktiviert ist?

@martin

Jede Einstellung, bei der everyone als ausgewählte Gruppe festgelegt ist, wird automatisch in die ID logged_in_users übersetzt.

[martin (Martin Brennan)]

@Jagster

Warte … was Bedeutet das, dass alle Kategorien, die jetzt öffentlich sind (alle)

Nein, denn:

[quote=“martin, Beitrag:1, Thema:402273”]

Was ist mit Berechtigungen für Tags und Kategorien?

Diese Berechtigungen bleiben unverändert, da ihr Konzept von „alle

[Moin]

Kann mir jemand helfen zu verstehen, wie ich meine Theme-Komponenten anpassen muss?

Ich habe versucht, die copy-post-Komponente als Beispiel zu verwenden, da ich mich erinnere, dass sie ebenfalls eine Gruppeneinstellung verwendet, die den Zugriff auf die Funktion gewährt. Und dass es ein Problem gab, weil die Pseudogruppe „everyone“ eine separate Prüfung erforderte, genau wie in meiner Komponente, denn der Vergleich der IDs der Gruppen, denen der Benutzer angehört, hilft nicht – diese IDs müssen separat geprüft werden. Deshalb habe ich eine kürzliche Änderung dort erwartet, denn wie ich verstehe, sind die neuen Gruppen ebenfalls Pseudogruppen und die ID müsste separat geprüft werden. Fehlt mir etwas, das erklärt, warum dies hier nicht notwendig ist?

Meine favorite filters-Komponente hat zwei Gruppeneinstellungen: eine, die Gruppen erlaubt, ihre eigenen Filter zu speichern, und eine, die Standardfilter anbietet.
Standardmäßig können nur Mitglieder der Gruppe trust_level_0 benutzerdefinierte Filter verwenden, da nur registrierte Benutzer Daten in einem benutzerdefinierten Benutzerfeld speichern können. Hier wäre es also sinnvoll, wenn ich anonymous_users nicht als Auswahl zulassen würde. Wie mache ich das in einer Theme-Komponente? Gibt es dafür bereits ein Beispiel?

Die Standardeinstellung für die Standardfilter ist „everyone“, da ich es hilfreich finde, dass sogar nicht registrierte Benutzer die Standardfilter sehen und verwenden können. Das Problem ist, dass everyone zu ‚logged_in_users‘ geändert wird, obwohl ich es explizit ausgewählt habe. Muss ich dafür eine eigene Migration erstellen, damit Admins, die derzeit everyone verwenden, in Zukunft weiterhin Filter für nicht registrierte Benutzer haben? Wann muss diese Migration stattfinden? Oder muss jeder Admin dies nach der Ausführung der Migration einzeln ändern?

Ist all das, worüber ich mir Sorgen mache, tatsächlich unnötig? Falls Anpassungen erforderlich sind, wirken weniger als vier Wochen angesichts der Anzahl der von der Community gepflegten Komponenten, die potenziell betroffen sein könnten, ziemlich kurz.
Zusätzlich zu „copy-post“ habe ich mir auch die unanswered filter component angesehen, aber auch dort konnte ich keine Änderungen finden. Es fühlt sich an, als würde ich etwas Wichtiges übersehen. Schließlich ist die Änderung seit fast einer Woche standardmäßig aktiviert. Deshalb gehe ich davon aus, dass offizielle Komponenten bereits aktualisiert worden wären, wenn Anpassungen notwendig wären.

[martin (Martin Brennan)]

Bei diesen Komponenten ist currentUser?.groups ohnehin nicht zuverlässig, da sie nur sichtbare Gruppen für den Benutzer enthält, während die Gruppen, die sich auf Berechtigungen auswirken, hier möglicherweise nicht serialisiert sind:

app/serializers/current_user_serializer.rb

Im Kern und in Plugins umgehen wir dieses Problem, indem wir im Current-User-Serializer so etwas wie Folgendes tun:

app/serializers/current_user_serializer.rb

Offensichtlich steht dies jedoch Theme-Komponenten und Themes sowie deren Einstellungen nicht zur Verfügung.

@Moin

Das Problem ist, dass everyone zu ‚logged_in_users’ geändert wird, obwohl ich es explizit ausgewählt habe. Muss ich dafür eine eigene Migration erstellen, damit Administratoren, die derzeit everyone verwenden, auch in Zukunft Filter für nicht registrierte Benutzer behalten? Wann muss diese Migration stattfinden? Oder muss jeder Administrator dies nach Ausführung der Migration einzeln ändern?

Hmm, bin mir nicht sicher, muss mir das noch überlegen. Wenn du wirklich everyone meintest, müsste dies sowohl zu logged_in_users ALS AUCH zu anonymous_users geändert werden. Das war das Hauptproblem mit everyone, wie im ursprünglichen Beitrag (OP) erwähnt – einige verstanden darunter nur angemeldete Benutzer, andere angemeldete plus anonyme Benutzer, und es war stark situationsabhängig.

Ich habe die Interpretation „nur angemeldete Benutzer