Granulare gruppenbasierte Berechtigungen für anonyme und angemeldete Benutzer

Nachrichten und Veranstaltungen Ankündigungen
23

Kein Problem! Schön, dass disallowed_groups hilfreich sein wird. Ich habe diesen PR jetzt gemerged.

Ich muss jetzt alle unsere offiziellen Themes und Komponenten durchgehen, jetzt da wir disallowed_groups und resolve_group_memberships zur Verfügung stehen. Ich schlage vor, dass du und @moin dasselbe für eure eigenen Themes und Komponenten macht, sobald ihr könnt, denn nachdem ich Änderungen an unseren offiziellen Repos vorgenommen habe, möchte ich wirklich voranreiten und die im Eröffnungspost beschriebene Änderung als stable freigeben.

Viele andere Kernfunktionen verlassen sich jetzt auf oder nutzen anonymous_users und logged_in_users, und ich würde die Gruppe everyone wirklich gerne löschen.

3 „Gefällt mir“
24

hey Martin – eine Frage:

ich habe gerade ein vollständiges Update meiner Instanz durchgeführt und füge nun das disallowed_groups-Objekteinstellung zu meinem Komponenteneinstellung für everyone und anonymous_users hinzu, basierend auf den automatischen Gruppen-IDs hier:

so wie hier:

      groups:
        type: groups
        disallowed_groups: "0|4"
        required: true
        resolve_group_membership: true
        validations:
          max: 20

aber es zeigt immer noch everyone in der Gruppen-Dropdown-Einstellung der Komponente an:

Screenshot 2026-07-19 at 5.21.44 PM
Screenshot 2026-07-19 at 5.21.44 PM890×1010 38.6 KB

was mache ich bei der Objekteinstellung falsch? ich stelle fest, dass selbst ohne disallowed_groups in den Objekten die anonymous_users-Gruppe nicht angezeigt wird (also gibt es im Moment keinen Unterschied in der Liste meiner Komponente, ob ich disallowed_groups setze oder nicht). ich habe mit anderen Gruppen-IDs getestet und ich muss etwas falsch machen, wie ich disallowed_groups verwende (oder die Syntax), weil es scheint, als hätte es keine Auswirkung, egal welche ich verwende.

4 „Gefällt mir“
25

Oh, es gab heute Morgen einige GitHub-Probleme, daher ist die Änderung von disallowed_groups erst jetzt in den neuesten Stand von Commits · discourse/discourse · GitHub eingeflossen.

Ich bin mir nicht ganz sicher, ob das das Problem ist, aber könntest du versuchen, erneut zu aktualisieren, und schauen, ob es weiterhin auftritt? Wenn nicht, sag mir Bescheid und verweise mich auf dein Theme-Komponente (oder ist es nur deine Gruppen-Sidebar?), damit ich debuggen kann :slight_smile:

1 „Gefällt mir“
26

Ich denke, das lag daran, dass die anstehende Änderung im Forum, das du zum Testen genutzt hast, deaktiviert war. Ich habe sie aktiviert, und jetzt ist sie sichtbar.

Screenshot_20260720_081640_Firefox
Screenshot_20260720_081640_Firefox691×1038 99.8 KB

Ich habe das Forum auch aktualisiert, und everyone sowie anonymous_users werden wie erwartet ausgeblendet.

Um Missverständnisse zu vermeiden: Ich war es, der die Änderung vor etwa zwei Wochen deaktiviert hat :innocent:

3 „Gefällt mir“
27

hah :smiley: danke Moin! ich habe tatsächlich vergessen, dass die neue granulare Gruppen-Einstellung sowieso in den kommenden Änderungen enthalten war.

Martin, die disallowed_groups-Objekteinstellung funktioniert perfekt. ich mag diese Änderung sehr. nochmal danke an das Team - großartige Verbesserung. :discourse: :chefs_kiss:

6 „Gefällt mir“
28

Könnten Sie mir die CSS-Klassen für anonyme und registrierte Benutzer nennen? Ich verwende deren interne IDs nicht, da ich auf reines CSS setze.

29

Wir fügen diese CSS-Klassen standardmäßig nicht zum body-Element hinzu. Meinst du vielleicht CSS Classes for Current User's Groups ?

Diese Komponente muss aktualisiert werden, um je nach Vorhandensein eines aktuellen Benutzers entweder group-anonymous oder group-logged-in-users hinzuzufügen.

2 „Gefällt mir“
30

Hey Martin :wave:

Ich habe einen schnellen PR erstellt, um diese beiden Klassen (anonymous_users und logged_in_users) hinzuzufügen.

Ich habe es nicht wirklich getestet (lol), aber ich denke, es ist ziemlich straightforward. Der Code prüft einfach, ob der aktuelle Benutzer existiert. Wenn ja, ist er Mitglied von logged_in_users, und wenn nicht, dann von anonymous_users. :grin:

Hinweis: Ich bin mir ziemlich sicher, dass Discourse sowieso automatisch .anon hinzufügt, sodass die CSS-Unterscheidung zwischen anonymen und angemeldeten Benutzern auch ohne das Komponente erreicht werden kann. Dies nutzt jedoch einfach die neuen Gruppenkonventionen.

2 „Gefällt mir“
31

Oh ja, du hast recht, das hatte ich vorher nicht bemerkt, ich habe nur auf <body> geachtet :slight_smile:

Ich habe deinen PR für das Plugin trotzdem genehmigt, das ist in Ordnung :slight_smile:

2 „Gefällt mir“
33

Außerdem zur Information für alle: Ich hatte hier noch nichts gepostet, aber ich habe diese PRs für offizielle Komponenten zusammengeführt, um resolve_group_membership und disallowed_groups zu verwenden:

Ich arbeite gerade an einem Plan für die nächsten Schritte dieser anstehenden Änderung. Ich denke, es gibt immer noch einige Stellen in den Core-/Plugin-Codebasen, die direkt auf everyone zugreifen oder user.in_any_groups? auf der Serverseite nicht verwenden.

2 „Gefällt mir“
34

Gibt es einen Grund, warum dies noch nicht zusammengeführt wurde?

Der Grund, warum ich dieses Thema eröffnet habe, ist, dass ich meine Komponente endlich aktualisiert habe.

Das habe ich gemacht. Aber ich habe immer noch den Eindruck, dass dies nur für Foren hilft, die die Komponente hinzufügen, nachdem ich dies geändert habe. Bei denen, die es bereits verwenden, wird der neue Standardwert nicht angewendet (was normalerweise gut ist!). Ich sehe also immer noch das Problem, dass es für diejenigen, die die Komponente bereits verwenden, zu einer unerwarteten Verhaltensänderung kommt.

Außerdem weißt du, was passiert, wenn ein Administrator eine Einstellung mit einer Gruppe konfiguriert hat, die ich in meinem Update als nicht erlaubte Gruppe hinzufüge?

Da ich nicht glaube, dass die Komponente auf vielen Foren verwendet wird, war ich nicht allzu besorgt und habe trotzdem zusammengeführt, aber sowohl die Migration als auch das Festlegen nicht erlaubter Gruppen könnten auch für andere Themenentwickler relevant sein.

35

Nein, aus irgendeinem Grund dachte mein Gehirn wohl, das sei kein PR in der Discourse-Organisation :man_facepalming: Ich werde es gleich mergen, nachdem die CI-Checks durchgelaufen sind.

Für solche Fälle und andere in der Zukunft ist es wahrscheinlich am besten, eine Migration pro Theme/Component zu schreiben Migrate Discourse theme settings

36

In meinem obigen Beitrag habe ich gefragt, wann dies geschehen muss. Eine Migration, ohne sicherzustellen, dass die neuen Gruppen auf allen Foren funktionieren, könnte auch Probleme verursachen, und Administratoren können die Änderung ein- und ausschalten. Daher scheint es unmöglich, zur richtigen Zeit zu migrieren.

37

Entschuldigung, falls dies bereits erwähnt wurde und ich es übersehen habe…

Ich habe festgestellt, dass, wenn resolve_group_membership in den Einstellungen enthalten ist, ich nur auf den booleschen Wert über das user_in_-Präfix zugreifen kann, aber nicht mehr auf den Rohwert des Einstellungsfeldes.

aabbccdd_allowed_groups:
  refresh: true
  default: "1|2"
  type: list
  list_type: group
  resolve_group_membership: true

console.log(settings.aabbccdd_allowed_groups); // undefined

console.log(settings.user_in_aabbccdd_allowed_groups); // true oder false

Ist dies beabsichtigt?

1 „Gefällt mir“
38

Ich denke schon. Andernfalls hätte die Lösung für diesen Bug anders aussehen können.

Das ergibt für mich auch Sinn. user_in_x überprüft auch Gruppen, von denen das Frontend nichts weiß, weil die Gruppe nur für Administratoren sichtbar ist oder ihre Sichtbarkeit standardmäßig eingeschränkt ist, wie bei everyone. Je nachdem, was man verwendet, erhält man also unterschiedliche Ergebnisse, und die Kombination der beiden könnte unerwartete Folgen haben.

2 „Gefällt mir“
39

Danke, Moin, das ist genau richtig. @gormus der einzige Ort, an dem die tatsächlichen Gruppen-IDs weiterhin durchkommen, ist die Admin-UI für die Theme-Einstellungen.

Ich bin mir nicht sicher, ob dies klar ist, basierend auf dem, was ich zuvor gepostet habe, aber die anonymous_users und logged_in_users sind jederzeit nutzbar, ohne dass diese bevorstehende Änderung aktiviert sein muss; ich habe sie vor Monaten unabhängig hinzugefügt. Das ist die Hauptfunktion der bevorstehenden Änderung:

In jedem Fall bist du auf der sicheren Seite, wenn du everyone überall dort entfernst, wo es verwendet wird, und ab jetzt nur noch anonymous_users und logged_in_users verwendest.

Heute plane ich, einen Plan für die verbleibenden Arbeiten zu erstellen, die ich noch erledigen muss, um everyone bei Site-Einstellungen endgültig zu entfernen (Kategorie-Einstellungen bleiben vorerst unberührt), und ich werde ihn hier posten, damit wir hoffentlich auf derselben Seite bleiben und ich diesen Plan fortlaufend aktualisieren kann.

3 „Gefällt mir“
40

Aber die Gruppen sind in der Benutzeroberfläche nicht sichtbar, wenn die Änderung deaktiviert ist. Administratoren können keine Einstellungen für diese Gruppen vornehmen. Wenn ich also „everyone“ (jeder) als nicht erlaubte Gruppe hinzufüge, sehen sie keine Gruppen mehr, die es ihnen ermöglichen, eine Komponente so einzurichten, dass sie für Besucher sichtbar ist. Für mich impliziert „nutzbar“ nicht nur, dass etwas funktioniert, sondern auch, dass es sichtbar ist. Da es weiterhin möglich ist, die Änderung zu deaktivieren, würde ich es nicht als „sicher“ bezeichnen, sich nur auf die neuen Gruppen zu verlassen.

1 „Gefällt mir“
41

Hmm, du hast recht. Es gibt noch ein paar weitere Dinge, die ich beheben muss, damit das Problem mit disallowed_group verschwindet, wenn die kommende Änderung deaktiviert ist:

  1. anonymous_users und logged_in_users sind im Gruppenauswähler überhaupt nicht vorhanden. Ich denke, es ist jetzt sicher, diese hier zu erlauben. Dann spielt es keine Rolle, ob du everyone zu disallowed_groups hinzugefügt hast, wenn die kommende Änderung deaktiviert ist.
  2. Guardian::AnonymousUser#in_any_groups? so korrigieren, dass es anonymous_users respektiert, wenn die kommende Änderung deaktiviert ist.
  3. Die gleiche Aliasing-Logik für die Lesezeit von 0 (everyone) → 5 (logged_in_users) für Themeneinstellungen hinzufügen, die wir bereits für Site-Einstellungen verwenden.

Ich werde wahrscheinlich auch everyone im Gruppenauswähler mit (legacy) kennzeichnen, solange die kommende Änderung noch optional und deaktiviert ist.

Ich werde diese Punkte priorisieren und in meinen Gesamtplan aufnehmen, an dem ich gerade arbeite.

The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions
42

Ich habe hier ein eigenes Thema erstellt @moin The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions . Der Originalbeitrag ist noch unvollständig; ich arbeite gerade lokal alle Fälle durch und werde ihn weiterhin aktualisieren. Es macht mir nichts aus, wenn ihr in diesem Thema weiter schreibt, aber ich würde es bevorzugen, wenn wir weitere Diskussionen im neuen Thema führen würden, damit ich Teile des Originalbeitrags zitieren oder entsprechend ergänzen kann.

2 „Gefällt mir“
43

Warte, ich habe das gerade erst gesehen.

Also waren manche verwirrt, weil „everyone“ nur eingeloggte Benutzer bedeutet?

Wer?! „Everyone“ bedeutet doch „everyone“ – das ist doch sehr klar.

„Everyone“ ist doch jeder, der die Seite aufruft, egal ob er eingeloggt ist oder nicht – das ist doch einfach, oder?

Heißt das jetzt, dass eine vollständig öffentliche Kategorie mindestens zwei Gruppen statt einer braucht – „eingeloggte“ und „anonym“? Das ist doch lächerlich und keine Verbesserung?

Und falls nicht, und man nur „anon“ eintragen muss, weil das ein Synonym für „everyone“ ist – dann ist das nicht mehr korrekt, da eingeloggte Benutzer ja nicht anonym sind.

Wo es bei Discourse etwas „Lernbedarf“ gab, war, dass TL0 in manchen Fällen „alle, die ein Konto haben und eingeloggt sind“, in anderen aber auch „die, die noch nicht TL1 erreicht haben, aber ein Konto haben und eingeloggt sind“ bedeutete.

Der entscheidende Punkt hier ist, dass es keine einzelne Gruppe von Personen darstellte, sondern eine Schwelle – und das war der Schlüssel.

Indem man TL0 einfach in „eingeloggte Benutzer“ umbenennt, bricht man die Konsistenz, dass jede Sicherheitsstufe eine Schwelle darstellt. TL1 ist ebenfalls eine Schwelle und keine echte „einzelne Gruppe“. Heißt das dann, dass wir eine Gruppe namens „eingeloggte Benutzer mit mindestens Trust Level 1“ brauchen?!

Ich bin mir absolut nicht sicher, ob diese Änderung nötig war – Änderung um der Änderung willen?

2 „Gefällt mir“