Rechtesystem

[SlaterB]

oder:
DB-Abfragen bei jedem Request könnten zum Teil zu vermeiden sein,
ist kein PHP, wenn man schon eine zivilisierte mächtige Programmiersprache wie Java mit laufenden intelligenten Server hat, dann auch nutzen

alle Rollen und Permissions sind im Programm dauerhaft gecacht,
sind entweder Enum, falls starre Menge, oder jedenfalls eindeutige einzelne Objekte,
Aktionen kennen ihre benötigten Permissions

jeder User wird zu Beginn seiner Session mit seinen Rollen (Ids) geladen und daraus einmalig für die Session ein Set von Permissions generiert,
Abfragen dann nur noch ob die zu einer Aktion benötigte Permission im Set jeweils vorhanden ist oder nicht

Sonderfälle wie während einer laufenden Session Änderungen der Recht eines Users, gar der Rollen/ Permission-Menge allgemein
sind je nach Bedarf zu ergänzen, aber sollten beherrschbar sein

[Landei]

[QUOTE=MrEuler]
Angenommen ein User könnte mehrere Rollen zugewiesen bekommen[/quote]

Ja, das ist sinnvoll.

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

Das ist fast OK, aber Permissions können nicht fest an Rollen gebunden werden. Es ist ja durchaus vernünftig, wenn unterschiedliche Rollen (sagen wir „Mod“ und „Admin“) die gleiche Permission (etwa „Threads verschieben“) haben können. Also brauchte man da auch eine m:n Zwischentabelle roles_permissions.

Natürlich kann es zu einem Wildwuchs kommen, aber ohne diese Freiheitsgrade kommt es ganz sicher zu einer kombinatorischen Explosion.

[SlaterB]

@Landei

Es ist ja durchaus vernünftig, wenn unterschiedliche Rollen (sagen wir „Mod“ und „Admin“) die gleiche Permission (etwa „Threads verschieben“) haben können.

vernüftig ist es, wenn man Permission dabei hat, aber das Beispiel finde ich nicht so günstig,
wieviele Permissions a la ‚Threads verschieben‘ gibt es auf dieser Ebene, die will man doch nicht alle doppelt verteilen,
und was ist mit User-Grundfunktionen wie ‚Themen anlegen‘, auch an alle verteilt?

entweder (A) auch Vererbung mit ins Spiel bringen, ob im Programm einzeln speziell für ‚Admin ist auch Mod‘ hinterlegt,
oder allgemein beliebig modelliert in weiterer DB-Tabelle,

oder (B) einfacher die Moderator-Permissions nur dort bei Moderator-Rolle vorhalten und eben bei Bedarf zwei Rollen vergeben (+ mehr für normaler User & Co.),
etwas mehr Aufwand bei User-Verwaltung, aber dann eben statt Rolle wechseln weitere Rolle zuzuweisen, kommt aufs gleiche hinaus

ein Admin kann dabei theoretisch auch ohne Moderationsrechte, ohne Posting-Edit usw. auskommen,
kleiner Selbstschutz vor Edits fremder Postings, auch vor entsprechenden User-Anfragen per PN ,

falls aus irgendeinem Grund gar kein Posting schreiben gewünscht dann auch ohne die Rolle User
(edit: ok, Gast gibts noch und Login dann fraglich, aber sicher klar was gemeint)

---

ob Permissions überhaupt benötigt dabei für mich vorerst noch die Frage,
eine Permission wie ‚Threads verschieben‘ nur um sie Mods und Admins zuzuteilen etwas unnütz doppelt verteilt, Absatz zuvor,
sie (und 20 andere) nur einzeln auf Moderator zu legen bringt aber irgendwie auch nicht viel,

da könnten einfach die entsprechenden Aktionen Rolle/ Stufe Moderator verlangen, Rollen für sich reichen ohne Permissions wie schon in #5 geschrieben

[quote=SlaterB;115878]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.[/quote]

ob mit Vererbung (A) wie damals impliziert, oder auch die x Stufen beliebig einzeln zugewiesen (B)

[cmrudolph]

@MrEuler :
Das ist das falsche Abstraktionsniveau. Du bis hier in der technischen Implementierungsebene und da sogar “hinter” dem ORM. Hier in diesem Thread geht es aber eigentlich um abstraktere Konzepte.

*** Edit ***

Ich sehe Rollen (je nach Kontext auch “Gruppen” genannt) so, wie sie im klassischen Sinne eigentlich schon immer eingesetzt wurden: als Instrument um verhältnismäßig feingranulare Berechtigungen etwas grobgranularer zuweisen zu können.
Sicherlich mag es manchmal sinnvoll sein, dass bestimmte Rollen auch für die Autorisierung verwendet werden können. Das wäre aber ein Detail des “dritten Bausteins” aus #14.

Deshalb sollte es auch möglich sein, dass ein Benutzer Permissions “mehrfach” erhält, weil sie in mehreren Rollen enthalten ist.
Eine Art Vererbungshierarchie von Rollen sollte aber der Einfachheit halber auch möglich sein. (Administrator extends Moderator extends User)

[Landei]

@cmrudolph

Eine Art Vererbungshierarchie von Rollen sollte aber der Einfachheit halber auch möglich sein. (Administrator extends Moderator extends User)

Wahrscheinlich zu kompliziert. Vielleicht reicht die Möglichkeit, die Permissions von bestehende Rollen zu kopieren.

[cmrudolph]

@Landei

Wahrscheinlich zu kompliziert.

An welcher Stelle? Es muss ja keine Mehrfachvererbung möglich sein Im Objektmodell müsste es nur eine rekursive Beziehung geben, die die Elternrolle angibt.

Von der technischen Umsetzung her würde ich die Permissions hinterher sowieso „flachklopfen“, sodass bei der Auswertung Rollen, Hierarchien und alles andere gar keine Rolle mehr spielen.

Die Frage bleibt aber, ob man einen echten Mehrwert von einer Vererbungshierarchie hätte. Die (wenigen) Vorteile kämen eher dann zum tragen, wenn man Rollenbasierten Zugriff auf bestimmte Dinge geben möchte („Moderationsbereich kann nur durch Moderatoren eingesehen werden“ statt „Moderationsbereich erfordert ‚darf Moderationsbereich einsehen‘-Berechtigung“).

Daher würde ich das derzeit wohl auch weglassen.

[Landei]

Ich habe nochmal über Rollen und Permissions meditiert, und insbesondere nach den Erfahrungen , die ich mit den selbstreferentiellen Categories gemacht habe, bin ich geneigt, das Thema nochmal zu überdenken, und zwar in die von dir genannte Richtung (wenn ich es richtig verstanden habe): Ich würde also die jetzigen Permissions zu “Top-Level-Rollen” machen, und rekursives aggregieren erlauben, etwa eine Rolle ROLE_USER, die die Rollen ROLE_READ_FORUM, ROLE_WRITE_FORUM, ROLE_EDIT_PROFILE u.s.w. zusammenfasst. ROLE_MODERATOR würde dann von ROLE_USER, ROLE_MODERATE_FORUM u.s.w. erben. Die Auflösung der tatsächlichen Rollen kann dann wieder in den Methoden von CurrentUser erfolgen. Wie jetzt auch schon, wären Teile der Rollen (nämlich die, auf die die Applikation testet) fest vorgegeben. Später könnte man dann einbauen, dass z.B. für ein bestimmtes Unterforum selbst angelegte Rollen zum Lesen, Schreiben und Moderieren benötigt werden.

Ich will das natürlich nicht überstürzen, und habe momentan auch mit der Forum-Seite genug zu tun, aber das ist natürlich eine Sache, die prinzipiell gelöst werden muss, bevor es an die Details geht.

Generell bin ich mit fjorum schon ein paarmal in die falsche Richtung gelaufen (Ninja, Freemarker, ObjectDB), aber jedesmal war es nicht so schwer, die Kurve zu bekommen. Das Projekt ist ja auch dazu da, um verschiedene Wege auszuprobieren und dazuzulernen.

[Landei]

Okay, ich habe die “rekursiven Rollen” als neuen Branch gepusht.

Also: Permissions gibt es nicht mehr, Rollen haben eine einseitige M:N-Beziehung, die aussagt, welche anderen Rollen die aktuelle umfasst. Wenn z.B. Admins auch moderieren können sollen, kann man ihnen entweder einzeln die ganzen Low-Level Rollen zuweisen (gut, da gibt es aktuell noch nicht viel), oder man lässt sie einfach von Moderator “erben”.

[cmrudolph]

[ot]Zuerst einmal einen Meckerpunkt zum Commitverhalten:
Deine Commits sind keine logischen Einheiten, sondern die Anpassung durchzogen mit ein paar Refactorings. Teilweise sind auch funktional nicht dazugehörige Änderungen im selben Commit. Und das unter dem Commit-Kommentar “small improvements” zusammengefasst. Das hilft nicht unbedingt der Nachvollziehbarkeit der Änderungen.[/ot]

Zu den Änderungen der Rollen:
Das sieht grob betrachtet schon einmal ganz gut aus, auch wenn ich noch nicht alles im Detail nachvollzogen habe.
Aufgefallen sind mir zwei Punkte, die vorher aber auch schon gegeben waren: Du solltest dir das Interface GrantedAuthority mal ansehen und ggf. von Role implementieren lassen.

(Wohl nicht mehr relevant: In der Klasse BasicPermission würde ich wahrscheinlich die property descriptionKey weglassen und die Namen anhand des Enum-Konstantennamens generieren. Das hätte den Vorteil, dass nicht nur Schlüssel für Beschreibungen, sondern ggf. auch für Kurztitel etc. generiert werden könnten.)