Rechtesystem

Eine der Dinge, die zumindest grundsätzlich gelöst werden sollten, ist das Rechtesystem von fjorum. Zur Zeit besteht es aus zwei Flags (mod, admin) an der User-Klasse. Ich glaube nicht, dass das besonders gut skaliert

Aber da sich Berechtigungen quer durch die Anwendung ziehen, brauchen wir meiner Meinung nach **jetzt **eine solide (aber nicht over-engineerte) Lösung.

Meine Gedanken dazu:

• ein einfaches System aus Rollen und Permissions sollte ausreichen
• Permissions sollten nicht zu granular sein
• man könnte einige Rollen vordefinieren (User, Mod, Admin), sie sollten aber prinzipiell frei definiert werden können (wobei man vernünftige Standards vorgeben kann)
• es gibt aber die „magische“ Rolle Guest, die jeder Gast automatisch hat, so dass man auch Gästen Zugriff auf etwas gewähren kann
• Permissions müssen fest vorgegeben sein, dürfen also keine Entities sein (später sollte man die Möglichkeit für Plugins u.s.w. vorsehen, neue Permissions einzuführen)
• Es ist nicht notwendig, Permissions direkt an Nutzer vergeben zu können, das sollte immer über Rollen geschehen
• für die Autorisierung in der Anwendung (z.B. Admin-Bereich) sollten normalerweise nur Permissions relevant sein, außer im eigentlich Forum
• Im Forum kann über Rollen der Zugang zu Themen geregelt werden (z.B. ein Forenbereich für Admins, oder einen „Ü18 Schweinskram“-Bereich, der an eine Rolle „Adult“ gekoppelt ist). Dabei wird zwischen Leserecht und Vollzugriff unterscheiden (was ausreichen sollte)
• Man muss nicht alles über Rechte lösen, bei manchen Sachen bin ich mir da auch noch nicht sicher (z.B. zeitliche Nutzersperre)

Klingt das soweit vernünftig, habe ich was übersehen, oder gibts da schon was fertiges bei OBI?

Warum nicht?

Was meinst du damit? Bezieht sich das auf den Nachfolgenden Satz, dass der Zugang zu Themen über Rollen geregelt werden kann?

Den Zugang zu Themen würde ich genauso an Permissions, die ja wiederum an Rollen hängen, regeln. Es macht doch keinen Sinn, dafür einen extra Fall zu schaffen.

Ich habe einen Moment lang nachgedacht, ob das tatsächlich ausreichend wäre. Wenn man die Berechtigungen sowohl für Themen als auch für Beiträge ermittelt, könnte das reichen.

Ansonsten stimme ich dir eigentlich weitestgehend zu bzw. habe keine Anmerkungen.

Möchtest du auch schon Anmerkungen zur technischen Umsetzung?

Weil die Anwendung ja mit unbekannten Permissions nicht anfangen kann. Bei Permissions denke ich an Sachen wie „darf in den Admin-Bereich“, „darf Nutzer bearbeiten/anlegen“, und die müssen natürlich schon bekannt sein, um sie abtesten zu können.

Was meinst du damit? Bezieht sich das auf den Nachfolgenden Satz, dass der Zugang zu Themen über Rollen geregelt werden kann?

Ja.

Den Zugang zu Themen würde ich genauso an Permissions, die ja wiederum an Rollen hängen, regeln. Es macht doch keinen Sinn, dafür einen extra Fall zu schaffen.

Wieso einen Extra-Fall? Rollen brauchen wir meiner Meinung sowieso, und an dieser Stelle können wir ausnutzen, dass man die in Gegensatz zu Permissions anlegen kann.

Ich habe einen Moment lang nachgedacht, ob das tatsächlich ausreichend wäre. Wenn man die Berechtigungen sowohl für Themen als auch für Beiträge ermittelt, könnte das reichen.

Ich bin mir nicht sicher, ob eine Kontrolle auf Kategorie-Ebene („Unter-Foren“) nicht ausreicht. Ich denke, es verwirrt mehr, wenn innerhalb einer Kategorie verschiedene Berechtigungen gelten. Was mir etwas Kopfzerbrechen bereitet ist die Frage, ob man eventuell auch rekursive Kategorien (Unter-Unter-Foren u.s.w.) erlauben will, was die Berechtigungsfrage noch einmal ziemlich komplizieren würde.

Ich habe vergessen, dass es im Forum neben Leserechten und Vollzugriff auch noch Moderationsrechte geben muss (z.B. Thema schließen, sticky machen…)

Möchtest du auch schon Anmerkungen zur technischen Umsetzung?

Ich denke, die technische Umsetzung sollte nicht so schwer sein, wenn man es nicht viel komplizierter macht.

Ich hatte mal ein Forum wie das von Byte-Welt administriert. Nach etwas Verwirrung bekommt man doch mit, wie das Ganze funktioniert.

Landei, hast Du auch schon mal ein Forum administriert? Wenn nicht, mache ein eigenes auf oder lass Dir die Rechte geben.

Das klärt viele Fragen denke ich.

bestimmt die technische Prüfung,
eine Aktion sollte mit einer Bedingung hinterlegt sein ‚benötige Permission EditUser‘,
wenn schon Permissions, dann konsequent alles danach, nicht parallel auch noch Rollen abfragen,

Rollen wären dann nur noch ein Hintergrundwerkzeug um Permissions effizient zu organisieren,
in der User-Verwaltung, große Programmteile bräuchten davon keine Ahnung haben

wenn beliebige Plugins dazu kommen, z.B. Blogs oder Umfragen, dann kann es dafür doch dynamisch neue Permissions geben,
neu zu vergeben an Rollen und von den neuen Programmteilen abzufragen

dynamisch beliebige neue Rollen abfragen zu lassen wäre ein unschöner Umweg zum gleichen Ziel,
für den Fall dass es Permissions gibt, wenn nicht dann nur Rollen auch denkbar, nächster Absatz:

für den Anfang klingt das freilich etwas unnötig kompliziert,
eine Rollenleiter Gast, neuer User, normaler User, Stammuser, Moderator, Admin könnte reichen, die höhere Stufe immer mit den Rechten der vorherigen + mehr,
nicht ‚benötige Permission EditUser‘ abfragen sondern ‚benötige Stufe Mod (oder höher)‘ wie mit ModAdminAuthorizationFilter & Co.

für einzelne parallele Konzepte wie das Beispiel Adult könnte die zusätzliche Rolle reichen, einfach nur die Rolle, keine (gleichlautende und 1:1 verteilte) Permission dahinter

Permissions über Rollen lohnt sich doch erst wenn es komplizierter zu verteilen ist, sollte nicht wenigstens ein Beispiel vorher als notwendig bekannt sein?
wie sieht das denn hier im Forum aus, Benutzergruppen als Rollen gibt es ja einige, auch Mehrfachvergabe, stehen Permissions dahinter und nötig?

gleich größeres Modell kann aber nicht schaden

Ok, zumindest für Foren sollte man festlegen können, wer was darf. Wie das Mapping aussieht ist da wohl die entscheidende Frage.

Allgemein glaube ich, dass das mit den Berechtigungen doch etwas komplizierter ist. Man bedenke noch Dinge wie Beiträge / Themen, die erst durch Moderatoren freigeschaltet werden. Oder geschlossene Themen, etc…

Ein erster Baustein, den man wohl auf jeden Fall braucht, sind Rollen und Berechtigungen. Ob die Berechtigungen konfigurierbar sein sollten hängt davon ab, wie Berechtigungen geprüft werden. Wenn bei Foren / Themen die Berechtigungen konfigurierbar sind, könnte es auch sinnvoll sein, eigene Berechtigungen anlegen zu können.

Wofür es Berechtigungen gibt, das muss wohl, wie du ja schon geschrieben hast, im Programmcode verankert sein. Die Berechtigungen selbst könnten dynamisch hinzufügbar sein.

Ja.
Rechte für Foren/Forengruppen. Rechte für Benutzer/Benutzergruppen. Eigene Benutzergruppen erstellen, dafür Rechte zuweisen. Öffentlich/nicht öffentlich. Wir haben hier verschiedene Projekte, wo jeder eigene Rechte hat u.s.w. …
Da bekommt man schon Kopfschmerzen, wenn man das administrieren muss (bei fertiger, über Jahre entwickelter Software). Das Alles neu zu bauen?
@Landei Du solltest mal in ein Admin-Paneel reinschauen, damit du eine Vorstellung von dem Umfang bekommst. Deine Idee ist super! Aber, ob sich die Arbeit lohnt?
Als Anreiz könnte man dir mal einen Blick ins Admin Paneel einrichten - aber das muss Kay entscheiden.

Ich kenne den Admin-Panel, ich bin Admin in einem anderen vBulletin-Forum. Und diesen Overkill will ich mit meinem Projekt vermeiden

DAS! Wäre mal was richtig sinnvolles.

Ich habe mir überlegt, dass man statt der einen “magischen” Gastrolle vielleicht generell automatische regelbasierte Rollenzuweisungen (parallel zur manuellen Nutzerzuweisung) erlauben könnte:

Rolle Guest: isGuest
Rolle Adult: age >= 18
Rolle Veteran: posts >= 1000
u.s.w.

Aber das nur als spätere Ergänzung. Würde aber viele Anwendungsfälle abdecken.

braucht es überhaupt eine Rolle Gast? wofür verwendet, ob mit Permissions oder nicht, nicht eher wegzulassen?
geblockte IPs/ einzelne anonyme Sessions davon sicher unabhängig, wird wohl kaum durch Entzug der Rolle Gast passieren

wenn man voll auf Rollen/ Permissions geht könnte es eine Verbiegung sein, bestimmte Rollen erst jeweils einzeln abzufragen, dabei zig Daten des Users zu benötigten,
evtl. lieber glatte Sache: X Rollen vorhanden → Y Permissions vorhanden, darauf die Filter, ja oder nein, fertig

die automatischen Rollen können statt durch Berechnung bei gelegentlichen Durchläufen (1x täglich), evtl. passend nach jedem Posting/ Profiländerung zugewiesen werden,
wobei das mit dem Alter ziemlich unsicher ist

vielleicht die Automation auch nur für wirklich kleine Sachen wie nach Email-Bestätigung oder nach 10 Postings, für Rollen die auch nie zur Entziehung in Frage kommen
(Sperre usw. unabhängig davon)

bei den Beispielen Adult + Veteran kann ich mir für mich vorstellen, dass ich die auch manuell zurücknehmen möchte, egal was im Profil steht,

im dem Fall hätte man Verwaltungsaufwand, dass nicht Rolle automatisch wieder zugeteilt wird,
egal ob bei direkter Rollenberechnung oder bei gelegentlichen Durchläufen

→ solch relevanten und dann meist seltenen Rollen durchaus der manuellen Zuordnung überlassen,
evtl. durch manuell aufgerufene Hilfsmethoden unterstützt, ‚liste alle Nicht-Veteraten mit über 1000 Postings auf‘,
dann kann man sehen/ erinnern warum da einer mit 2300 dabei ist und den deselektieren, nicht zusammen mit den anderen durch einen Mausklick freischalten

notfalls zur Sicherheit explizit Gegenrollen (zweite Liste der normalen Rollen?)/ sonstige Markierungen ‚User nicht für Adult berücksichtigen‘,
um bei diesem komischen Beispiel weiterhin zu bleiben

Die regelbasierte Rollenzuweisung macht nur Sinn im Zusammenhang mit nutzerspezifischen Daten. Welche Daten stehen dafür zur Verfügung? Eigentlich nur wenige, da man sonst Probleme mit dem Recht zu personenbezogenen Daten bekommt. Man kann also nur Sachen wie Aktivität, Posts in bestimmten Foren, Anzahl der Posts, Bewertung des Mitglieds durch andere, Qualität der Posts, Anzahl der Dankeschöns… nutzen.

Um mal bei dem Beispiel Alter zu bleiben: das ist sehr heikel! Die Rechtelage kenne ich da nicht, aber man kann da schnell gegen das Gesetz verstossen denke ich. Ich weiss, dass das Problem mit dem Alter zB mit einer Überweisung gelöst wird. Dabei wird davon ausgegangen, dass nur Leute > 18 eigenmächtig Überweisungen durchführen können.

Wichtig ist ich denke, nicht nur wie eine Einordnung in die Rolle erfolgen soll, (automatisch oder durch Leute einer speziellen Rolle) sondern auch welche Auswirkungen Rollen haben können (Restriktionen auf Hauptforen, Unterforen, Themen in Bezug auf Lesen oder Schreiben…) Also speziell: was kann ein Veteran, was andere nicht können?

Wahl von Rollen, mögliche und eingesetzte Rechte usw. ist eine ganz andere Frage,
kann nebenher etwas interessieren für Beispiele, für wünschenswerte Optionen zum System,

aber das Hauptthema hier ist sicherlich das System an sich, die Technik dahinter, unabhängig von konkreten Inhalten

Wenn man vernünftig arbeitet, dann gibt es meiner Meinung nach drei Bausteine im Rechtesystem, die weitestgehend unabhängig voneinander sind (Edit: bzw. die zwei letzten bauen auf den ersten Baustein auf, sind aber voneinander unabhängig).

Zum einen gibt es den Baustein Roles und Permissions. Damit kann man die Autorisierung aller Anwendungsfälle abdecken.
Dazu müssen die Nutzer and die Rollen gebunden werden. Wie diese Bindung erfolgt, ist ein weiterer Baustein.
Vorstellbar wäre, dass es Trigger gibt, die automatisch bestimmte Rollen zuweisen (Anzahl Beiträge überschreitet / unterschreitet X => Rolle wird hinzugefügt / gelöscht; Nutzer registriert sich => Default-Rolle wird zugewiesen; …)
Außerdem gäbe es noch manuell zugewiesene Rollen, wie beispielsweise “VIPs” oder Projektrollen.

Der letzte Baustein ist die eigentliche Autorisierung einer Aktion. Die könnte bei dem oben beschriebenen Konzept so ablaufen, dass geprüft wird: hat der aktuelle Nutzer Permission X um Aktion Y auszuführen. Boolsche Verkettungen von Überprüfungen und ggf. weitere Prüfungen (ist der Nutzer Ersteller eines Themas / Beitrages) müssten auch noch möglich sein.

Ja, das trifft es ziemlich genau, wobei es mir hier primär um den ersten Baustein geht.

Wie oben dargestellt, sehe ich den ersten Baustein als Fundament, auf den der Rest aufbaut. Meiner Meinung nach müsste also “nur” geprüft werden, ob es einen Use-Case gibt, der sich nicht mittels Roles & Permissions umsetzen lässt.
Meines Erachtens ist das nicht der Fall, wodurch die Gestaltung relativ eindeutig ist.

Offen wäre dabei noch, ob auch Permissions dynamisch erzeugt werden können sollen.

Ich glaube es gibt zwei Arten um eine Verknüpfung von einem Nutzer zu einer Aktion herzustellen.

1. Über eine Rolle (per Definition besteht eine Erlaubnis, wenn Nutzer in irgendeiner Rolle ist, die eine Verbindung zu der Aktion hat)

   • man braucht: Menge Nutzer N, Menge Aktionen A (beide erweiterbar), Verknüpfung von N mit Rollen R und Verknüpfung R mit A
   • Aktionen könnten sein: Anzeigen von Foren, Unterforen, Editieren von Beiträgen…

2. direkt über eine Wahrheitsfunktion (Wenn eingeloggter Nutzer von zu editierenden Element = Eigentümer), dann Aktion editieren…

dabei muss man eine Kombination oder eine Priorisierung beider Wege festlegen können. Also wenn es um eine Editierbarkeit eines Beitrags geht, wird zB erst gecheckt, ob ein Recht über den Weg 1) besteht, und wenn nicht ob Weg 2) wahr ergibt.

Na ja, für solche Fälle würde man eine Permission “darf_eigenes_Profil_bearbeiten” oder so anlegen (*), und im jeweiligen Modul dann auch noch die Zusatzbedingung, dass man nur in sein eigenes Profil darf, “manuell” abprüfen. Das sollte nicht allzu oft vorkommen, und solche Spezialfälle mit ins Rechtesystem aufzunehmen, würde die Sache mächtig komplizieren, ohne großartigen Nutzen zu bringen. Die Mehrzahl der Aktionen lässt sich mit 1) abfrühstücken, und die Fälle wo 2) relevant ist, lassen sich meist gut isolieren (also die Profilseite ist entsprechend gesichert, und wenn man da erst einmal drin ist, braucht dort nicht jede einzelne Aktion überprüft zu werden).

(*) Natürlich kann es parallel auch eine Permission “darf_alle Profile_bearbeiten” geben.

Eine Erlaubnis oder Permission gibt es meiner Meinung nach nicht per se. Sie entsteht, wenn Eine Person auf eine Aktion mappt. Und eine Aktion mündet in der Anzeige eines bestimmten Elements (zB ein Edit-Button oder ein Eintrag in einer Liste zum Ansehen) Wobei das Mappen von einer Person auf eine Aktion immer über das Mapping Person - Rollen und das Mapping Rolle - Aktion geht.

Den zweiten Spezialfall dachte ich für das Anzeigen von besonderen Buttons wie ‘Nachträgliche Edition’ eines eigenen Beitrags. Alle Spezialfälle lassen sich auch über die zweite Variante abdecken. Wobei nur eine Java-Methode ausgewertet werden soll (Parameter: ZB Eingeloggter Nutzer, Rang dessen, und angezeigtes Element )

Um nicht nur um den heissen Brei herumzureden ein mehr oder weniger konkreter Vorschlag unter der annahme das auf ein RDBMS zurückgegriffen wird.

Angenommen wir haben diese 3 Tabellen

[SQL]create table users(id, …, role);
create table roles(id, description);
create table permissions(id, description, role, allowed);[/SQL]

Dann könnte die Abfrage ob ein user mit der id, die folgende Erlaubnis hat so aussehen. (geht mit joins schöner und performanter)

[SQL]select p.allowed
from users u, roles r, permissions p
where u.role = r.id
and r.id = p.role
and u.id = ?
and p.id = ?;[/SQL]

Würde so funktionieren.

Nachteil: Hoher Aufwand, da für jede Rolle explizit entschieden werden muss ob die Permission gewährt wird.

Angenommen ein User könnte mehrere Rollen zugewiesen bekommen

[SQL]create table users(id, …);
create table users_roles(user, role);
create table roles(id, description);
create table permissions(id, description, role, allowed);[/SQL]

Dann könnte die Abfrage ob ein user mit der id, die folgende Erlaubnis hat so aussehen.

[SQL]select count(*)
from users u, users_roles ur, roles r, permissions p
where u.id = ur.user
and ur.role = r.id
and r.id = p.role
and p.allowed = 1
and u.id = ?
and p.id = ?;[/SQL]

Vorteil: Ein bestimmter Bereich von Berechtigungen könnte in einer Rolle zusammengefasst werden. Insgesamt weniger Berechtigungen pro Rolle.

Nachteil: Es könnte ein starker Wildwuchs an Rollen entstehen, die den Usern zugeteilt werden müssten.

Konstruktive Kritik oder alternative Vorschläge sind höchst erwünscht.