[Erledigt] Funktionsberechtigungne, Rollen und Vererbung von Rechten

Geryon · 20.10.2010, 18:05

Hallo,

mich würde interessieren, ob ich in folgender Überlegung Funktionsberechtigungen, Rollen und die Vererbung von Rollen designtechnisch gut umgesetzt habe.

Für mein CMS benutze ich Funktionsberechtigungen. An einem Punkt im System wird abgefragt, ob eine Funktion mit dem angegebenen Parameter überhaupt ausgeführt werden darf.
Diese Funktionalität ist Grundlegend und gilt somit für fast alle Funktionen im System, die über eine bestimmte Methode aufgerufen werden. Also auch für alle Extensions von Dritten.
Zum Beispiel: Darf ich die Funktion artikelBearbeiten() mit dem Parameter 4 ausführen? Also den Artikel mit der ID 4 bearbeiten?

Ich habe hier zunächst einmal mein Datenbankmodell beschrieben. Ich denke daran lässt sich das alles am einfachsten veranschaulichen.

Grundlegend verfügt jeder User über eine einzige Rolle (siehe Tabelle USERS). Diese bündelt Rechte. Des Weitern können Rechte Benutzern auch direkt zugeteilt werden.
Das ist sinnvoll, wenn es zum Beispiel darum geht einen eigenen Beitrag zu bearbeiten oder zu löschen. Die Zuteilung der Rechte an User oder an Rollen geschieht in der Tabelle RIGHT_BIND.

Wobei ich mir noch unsicher bin ist die Art und Weise wie Rollen bei mir Teile einer anderen Rolle werden können. (Ist Vererbung hier das richtige Wort?)Ich habe das in der Datenbank mit roll_parent beschrieben. Siehe Tabelle ROLLS.

Und eine andere Frage, die mich dahingehend beschäftigt ist das Ausmaß an Datenmengen, die meine Tabelle RIGHT_BIND annehmen würde. So würde zum Beispiel dort für jeden User gespeichert werden, welchen seinen eigenen Beiträge er bearbeiten oder löschen darf.
Und da ja die Rollen rekursiv geladen werden, also die Rechte von Unterrollen der jeweiligen Rolle mit einbezogen werden, würde sich für Benutzer der Rolle Administrator, oder Forummoderatoren eine gewaltige Datenmenge beim laden der Rolle ergeben.
Weil ja eben die Rechte aller Unterrollen mit einbezogen würden. Denn ein Moderator soll ja zum Beispiel auch alles bearbeiten oder löschen dürfen. Daher braucht er die Rechte der schreibenden Benutzer auch.
Und da ist jetzt meine Frage, ob es dann wirklich Sinn macht alle Rechte des Administrators zum Beispiel in ein Array zu speichern. Der Administrator wäre in diesem Fall also die größte 'Vaterrolle'. Alle anderen würden dieser Rolle unterstehen und es würde sich eine hierarchische Struktur in der Datenbank bilden.

Vielleicht gibt es aber auch grundlegende andere Kritik an dieser Vorgehensweise allgemein. Da bin ich mir sogar ziemlich sicher

.

Code:

Tabelle: USERS -> speichert alle benutzer
user_id		user_nick		user_mail			user_pw		user_roll
1		admin			admin@admin.com			md5		1		//unser administrator mit der administrator rolle
2		nickname		mail@mail.com			md5		2		//ein redakteur


Tabelle: Rolls -> speichert alle rollen
roll_id		roll_name			roll_description		roll_parent
1		Administrator			bliblatext					//die Administrator Rolle
2		Redakteur			bliblatext			1	
3		Moderationsbereich1		bliblatext			5		//diese rolle ist teil von rolle 5
4		Moderationsbereich2		bliblatext			5		//diese rolle ist teil von rolle 5
5		SuperModerator			bliblatext			1				
6		Entwicklerrolle1		bliblatext			1
7		Entwicklerrolle2		bliblatext			1


TABELLE: RIGHTS	-> speichert alle funktionen, deren Ausführung geprüft werden muss
right_id		right_function
1			drawPage			//php funktion zum laden einer seite
2			editFile			//php funktion zum bearbeiten einer datei
3			editPost			//php funktion zum bearbeiten eines beitrags
4			editArticle			//php funktion zum bearbeiten eines artikels


TABELLE: RIGHT_BIND
right_user		right_roll		right_id		right_reference
			1			1			4		//ich darf die funktion drawPage mit dem parameter (4) aufrufen
			1			4			1		//ich darf die funktion editArticle mit dem parameter (1) aufrufen
			1			4			2		//ich darf die funktion editArticle mit dem parameter (2) aufrufen
			1			4			3		//ich darf die funktion editArticle mit dem parameter (3) aufrufen
			1			4			4		//ich darf die funktion editArticle mit dem parameter (4) aufrufen
			1			4			5		//ich darf die funktion editArticle mit dem parameter (5) aufrufen
			1			4			6		//ich darf die funktion editArticle mit dem parameter (6) aufrufen
1						2			1		//ich darf die funktion editFile mit dem parameter (1) aufrufen
1						3			1		//ich darf die funktion editPost mit dem parameter (1) aufrufen
1						3			2		//ich darf die funktion editPost mit dem parameter (2) aufrufen
1						3			3		//ich darf die funktion editPost mit dem parameter (3) aufrufen
1						3			4		//ich darf die funktion editPost mit dem parameter (4) aufrufen
1						3			5		//ich darf die funktion editPost mit dem parameter (5) aufrufen
1						3			6		//ich darf die funktion editPost mit dem parameter (6) aufrufen

Das solltet ihr am Besten in einen Texteditor kopieren...dann ist das besser lesbar...

Edit: habe gerade gesehen, dass ich mich im Titel vertippt habe...könnte das evtl. jemand ändern?

nikosch · 20.10.2010, 18:07

Zitat:

Das solltet ihr am Besten in einen Texteditor kopieren...dann ist das besser lesbar...

Kann ich nicht bestätigen

Geryon · 20.10.2010, 18:38

Sorry. Ich hoffe jetzt ist es besser. Es sind die Strukturen von 4 Tabellen abgebildet. Die erste Zeile einer Tabelle beschreibt den Namen der jeweiligen Spalte.

dr.e. · 20.10.2010, 22:52

Hallo Geryone,

hast du dir mal die Threads zu diesem Thema hier angesehen? Wir haben kürzlich unter http://www.php.de/software-design/50...erwaltung.html (Rechteverwaltung) über das Thema ausführlich diskutiert. Zu der von mir dort vorgeschlagenen Lösung hätte ich auch hier tendiert, da es weniger um Vererbung, denn um generische Abbildung von Funktions-Berechtigungen auf Rollen geht. Darüber hinaus sollte dieses Konzept mit Sichtbarkeits-Berechtigungen kombiniert, deinen Anwendungsfall abdecken.

Geryon · 21.10.2010, 21:48

Hallo und danke für die Antwort.

Ja ich habe dieses Thema ausführlich gelesen. Und auch verstanden soweit ich glaube. Nur ist mir das alles etwas tu theoretisch. Mir ist allerdings erst jetzt wieder aufgefallen, das ich schon wieder Rollen und Gruppen vermixt habe. Aber das soll erstmal nicht so wild sein. Ich wollte einfach mal eine praxisnähere Diskusion anstreben. Zunächst stellt sich mir die Frage ob das was ich da tue wirklich Funktionsberechtigungen sind, und ob das so gängig ist. Also ich meine vor einem call() speziell zu erfragen, ob eine Funktion mit einem gewissen Parameter ausgeführt werden darf. Und des weiteren bin ich mir einfach unsicher, ob ich alle Rechte von Anfang an laden soll oder ob es besser ist, das Recht erst dann aus der Datenbank zu erfragen, wenn es benötigt wird. Denn ersteres könnte sehr viel Speicher beim Ausführen der Anwendung zur Folge haben und letzteres ist Datenbankintensiver. Zumindest in meiner aktuellen Vorstellung.

dr.e. · 21.10.2010, 22:43

Hallo Geryon,

Zitat:

Nur ist mir das alles etwas tu theoretisch.

wie Praxis-nah soll denn eine Diskussion in einem Software-Design-Forum sein?

Was die Anwendung angeht, kommt das auf die Umsetzung deines CMS an. Hier stellt sich die Frage, ob du einen optimistischen oder pessimistischen Schutz Anwendung finden lassen möchtest. Erstere ist recht einfach, er zeigt dir bei fehlender Permission den Navi- oder Kontext-Menü-Punkt erst garnicht an. Sofern du eine pessimistische Sicherung einbauen möchtest, zeigst du den Punkt nicht an und prüfst zusätzlich in der Aktion noch auf Berechtigung. Dies kann man technisch als decorator pattern für einen Business-Service nach dem transaction script pattern umsetzen. Der Wrapper-Service beinhaltet dabei lediglich den Check auf die Berechtigung und delegiert die reine Funktion an den "eigentlichen" Service.

Zitat:

Mir ist allerdings erst jetzt wieder aufgefallen, das ich schon wieder Rollen und Gruppen vermixt habe. Aber das soll erstmal nicht so wild sein

Das ist es IMHO schon, denn Gruppen können zwar zur Zuordnung einer Sichtbarkeits-Berechtigung genutzt werden, sie mit Rollen gleichzusetzen mindert die Flexibilität. Gerade bei einem CMS ist das kontraproduktiv, denn so lässt sich beispielweise keine Trennung zwischen einem "junior editor" und "senior editor" schaffen, die beide die selben Objekte sehen, mit ihnen jedoch unterschiedliche Aktionen verknüpfen. Ein "junior editor" darf eben keinen Inhalt publizieren, ein "senior editor" hingegen schon.

Zitat:

Also ich meine vor einem call() speziell zu erfragen, ob eine Funktion mit einem gewissen Parameter ausgeführt werden darf.

Das hatte ich oben schon erwähnt. Entweder beim Aufbau des Menüs oder in der Funktion selbst. Letzteres sollte wenn möglich abstrahiert werden, denn sonst vermischst du Regulierung mit Funktionalität (uncle bob lässt grüßen).

Zitat:

Und des weiteren bin ich mir einfach unsicher, ob ich alle Rechte von Anfang an laden soll oder ob es besser ist, das Recht erst dann aus der Datenbank zu erfragen, wenn es benötigt wird. Denn ersteres könnte sehr viel Speicher beim Ausführen der Anwendung zur Folge haben und letzteres ist Datenbankintensiver. Zumindest in meiner aktuellen Vorstellung.

Sofern du mit "Recht" hier Funktionsberechtigungen meinst, würde ich diese entweder direkt dem User-Objekt beim Login mitgeben und dieses in der Session halten oder das User-Objekt als Facade/Proxy abfassen, das transparent beim Zugriff nachläd und zwischenspeichert. Was die Anzeige von Inhalten angeht (Sichtbarkeitsberechtigungen), so bist du in einer Live-Anwendung (CMS-Backend) auf Grund der Aktualität gezwungen, die Berechtigungen vor dem Anzeigen der Inhalten zu lesen. Das ist aber meiner Erfahrung nach nicht Kriegs-entscheidend, denn ein Backend ist nicht auf eine so extreme Belastung ausgelegt, wie ein Frontend (Webseite). Sicher muss es den Redakteuren ein angenehmes Arbeitsumfeld gewährleisten, das ist jedoch nicht allzu schwer.

Was das Thema Implementierung angeht, so lässt sich durch geschickte Daten-Modellierung ein einfacher Lade-Mechanismus erreichen. Alternativ dazu kann ein generischer Ansatz für die Sichtbarkeits-Berechtigungen genutzt werden, wie es das Usermanagement-Modul des APF tut. Hier werden Stellvertreter-Objekte angelegt, die auf Basis von Beziehungen zu einem Benutzer, einer Gruppe oder eines Berechtigungs-Typen geladen werden können. Auf Basis dieser Informationen können dann die "echten" Objekte angezogen werden. Das hat den Vorteil, dass sich so jede beliebige Anwendung in ds Modul integrieren lässt.

Um dir ein paar Quellcode-Beispiele zu geben, hier das Anlegen einer Berechtigung beim Erstellen eines CMS-Artikels:

PHP-Code:

  $uM = $this->getUmgtManager();
$type = $uM->loadVisibilityDefinitionTypeByName('Page');

$proxy = new GenericDomainObject('AppProxy');
$proxy->setProperty('AppObjectId',$pageId);
               $uM->createVisibilityDefinition($type,$proxy,array($user),$this->getDefaultVisibilityGroups());

Es wird zunächst ein Proxy-Objekt angelegt, das die Id der angelegten Seite beinhaltet und wird mit der Methode createVisibilityDefinition() mit einem Objekt-Typen (identifiziert mehr oder weniger die Anwendung, aus der das Obejkt stammt), kein oder mehreren Benutzern und kein oder mehreren Gruppen verknüpft.

Möchte ich eine Liste von Artikeln laden, die ein Benutzer über sich selbst oder einer seiner Gruppen berechtigt ist zuzugreifen, so funktioniert das wie folgt:

PHP-Code:

  $type = $uM->loadVisibilityDefinitionTypeByName('Page');
$articles = $uM->loadAllVisibilityDefinitions($user,$type);

Die Liste kann dann genutzt werden um in einer weiteren Anfrage die Daten der Proxy-Objekte zu echten Daten aufzulösen.

Sofern du Interesse an weiteren Beispielen hast, kann ich gerne noch eines aufbereiten.

Geryon · 22.10.2010, 15:52

Danke für diese ausführliche Antwort. Meine erste Frage wurde damit schon konkret beantwortet. Nun ist mir aber beim lesen zu meinem zweiten anliegen (dem laden der Rechte) aber noch etwas eingefallen:

Zitat:

so bist du in einer Live-Anwendung (CMS-Backend) auf Grund der Aktualität gezwungen, die Berechtigungen vor dem Anzeigen der Inhalten zu lesen. Das ist aber meiner Erfahrung nach nicht Kriegs-entscheidend, denn ein Backend ist nicht auf eine so extreme Belastung ausgelegt, wie ein Frontend (Webseite).

Mein CMS kennt die Unterscheidung zwischen Front- und Backend nicht. Das 'Backend' ist bei mir komplett in die Frontendausgabe integriert. Daher: alle Verwaltungsaufgaben lassen sich genau dort steuern, wo diese auch optisch anfallen. Zum Beispiel kann ein Artikel genau da bearbeitet werden, wo er auch angezeigt wird. Andere Verwaltungsaufgaben lassen sich als Content in Seiten einbauen. So baut man sich nicht nur das Frontend sondern letztendlich auch sein Backend selber. Wenn man möchte. Aber grundsätzlich gilt: Wenn es ein Backend bei mir gibt, dann ist es eigentlich nur das Frontend, welches als Content verschiedene Administrative Fnktionen zur Verfügung stellt. Zum Beispiel könnte man eine Seite mit dem Namen 'Backend' erstellen auf der man Seiten, Artikel und Benutzer verwalten kann, weil man entsprechenden Content dort eingestellt hat.

Aber ich glaube das ist eine extra Diskussion.

Ich würde gerne einmal eine Grafik hier einstellen, die mein Hauptproblem mit Rechten, Rollen und Gruppen ziemlich genau beschreibt. Aber ich werde noch ein bischen Zeit brauchen die zu erstellen.

Danke aber schonmal, dass du dir die Zeit für Beispiele genommen hast.

dr.e. · 23.10.2010, 10:42

Hallo Geryon,

Zitat:

Mein CMS kennt die Unterscheidung zwischen Front- und Backend nicht. Das 'Backend' ist bei mir komplett in die Frontendausgabe integriert.

Wir sprechen also von "on-site editing". Auch das ist kein Problem, denn da bist du trotzdem in einem Offline-Modus der Seite und kannst evtl. Performance-Engpässe mit asynchronen Ladevorgängen abpassen. Aber auch hier gehe ich zunächst nicht von Engpässen aus, da das Datenbank-Konzept auf indizierten Beziehungen basiert, die sehr schnell abgefragt und bearbeitet werden können.

Zitat:

Daher: alle Verwaltungsaufgaben lassen sich genau dort steuern, wo diese auch optisch anfallen. Zum Beispiel kann ein Artikel genau da bearbeitet werden, wo er auch angezeigt wird. Andere Verwaltungsaufgaben lassen sich als Content in Seiten einbauen. So baut man sich nicht nur das Frontend sondern letztendlich auch sein Backend selber. Wenn man möchte. Aber grundsätzlich gilt: Wenn es ein Backend bei mir gibt, dann ist es eigentlich nur das Frontend, welches als Content verschiedene Administrative Fnktionen zur Verfügung stellt. Zum Beispiel könnte man eine Seite mit dem Namen 'Backend' erstellen auf der man Seiten, Artikel und Benutzer verwalten kann, weil man entsprechenden Content dort eingestellt hat.

Das ist konzeptionell nichts besonders neues, hat aber den Charm, dass der Redakteur/Administrator (in Rolle gesprochen) nur eine Oberfläche hat. Nachteil ist sicher die Komplexität der Entwicklung, weil du an Hand des eingeloggten Benutzers viele Funktionen zu oder abschalten musst und das zu Lasten der reinen Frontend-Performance geht. Sofern du auf der Seite noch eine Community oder ein Feature, das Login erfordert betreibst muss das trennbar von den Funktionen des "Backend" sein. Entweder duch Rollen oder durch einen eigenen Login-Mechanismus (Security). Für gravierender halte ich aber die Abhängigkeit von Frontend-Funktionen zu Backend-Prozessen aus Sicht der Performance. Sofern du das APF als Basis betrachten würdest, könnte man aber sehr einfach Pattern/Konzepte wie view based caching einführen um im Fall des "Online Modus" (Benutzer surft auf der Seite), die Ausgabe-Generierung nicht von Backend-Prozessen abhängig zu machen.

Zitat:

Ich würde gerne einmal eine Grafik hier einstellen, die mein Hauptproblem mit Rechten, Rollen und Gruppen ziemlich genau beschreibt. Aber ich werde noch ein bischen Zeit brauchen die zu erstellen.

Versuche doch einfach mal aufzuzeigen, welche Stakeholder dein System hat und welche Funktionen und Entitäten dem gegenüber stehen. Das kannst du rein textuell beschreiben und daraus lässt sich sicher eine Diskussion bzw. Lösung ableiten, die u.U. mit dem APF-Modul usermanagement schon abbildbar ist.

Zitat:

Danke aber schonmal, dass du dir die Zeit für Beispiele genommen hast.

Gerne.

Geryon · 24.10.2010, 14:09

Hallo. Danke für die Antwort. Ich werde mir die genannten Vorschläge in den nächsten Tagen mal genauer ansehen.
Ich denke ich habe den Ansatz RBAC - besonders Version 2 - ganz gut verstanden. Nur etwas bleibt für mich dabei offen. Da ich eigentlich aus dem Bereich ACL komme habe ich ne Weile gebraucht um das RBAC zu begreifen. Dennoch fehlt mir dort etwas. Beim RBAC werden Rollen benutzt um Rechte zu bündeln. Und durch Vererbung kann man mit den Rollen auch indirekt Benutzer bündeln. Jede Rolle beinhaltet Rechte, die aus Objekten und Aktionen bestehen. Soweit ist mir das total klar.
Jetzt kommt mein Problem: Ein Benutzer hat das Recht, dass er im Forum mit der ID 3 einen neuen Beitrag verfassen darf. Dazu hat er die Rolle "Forum User" inne. Um seinen eigenen Beitrag jedoch löschen oder bearbeiten zu dürfen müssen diese beiden neuen Rechte unmitelbr und ohne Rolle dem User zugeordnet werden. Das hat aber an dieser Stelle nichts mehr mit RBAC zu tun. Ich habe unzählige Artikel gelesen. Aber in keinem war die Rede davon, dass es auch möglich ist, Rechte direkt an Benutzer zu knüpfen. Das ist ja glaube ich auch ein Merkmal von RBAC. Es geht mir also darum, dass es Rechte geben muss, die nicht in Rollen sein dürfen, sondern dem User direkt zugeteilt sind. Also eine Art ACL neben dem RBAC.

Ich hoffe ich konnte mein Problem so ganz gut verdeutlichen

dr.e. · 24.10.2010, 17:41

Hallo Geryon,

Zitat:

Jetzt kommt mein Problem: Ein Benutzer hat das Recht, dass er im Forum mit der ID 3 einen neuen Beitrag verfassen darf. Dazu hat er die Rolle "Forum User" inne. Um seinen eigenen Beitrag jedoch löschen oder bearbeiten zu dürfen müssen diese beiden neuen Rechte unmitelbr und ohne Rolle dem User zugeordnet werden.

Ich fasse zusammen: die Aufgabenstellung lautet unterscheiden zu können, ob ein Benutzer in einem Forum Beiträge anlegen, bearbeiten oder löschen darf.
Dies ist mit dem Rollen-Konzept (hier ist wichtig zu verstehen, dass ein Benutzer mehrere Rollen haben darf und soll!) sehr einfach möglich. Zunächst sollte das Forum, in dem sich der Benutzer bewegt für ihn sichtbar sein. Hierzu benötigt er eine Sichtbarkeitsberechtigung auf das Forum. In welcher Granularität nun Sichtbarkeitsberechtigungen vergeben werden ist dabei zweitrangig. Ich gehe hier mal davon aus, dass die Berechtigung auf Foren-Basis geschieht und damit jeder Beitrag eines Forums für ihn sichtbar ist. Weiterhin gehe ich davon aus, dass der Benutzer die Sichtbarkeitsberechtigung nicht über seiner selbst, sondern über eine zugehörige Gruppe (z.B. "Angemeldete Benutzer") erhält.
Anschließend wird dem Benutzer eine Standard-Rolle "Mitglied" zugewiesen, die die Funktions-Berechtigungen "create_thread", "edit_own_thread" und "delete_own_thread" mit den Werten "true" beinhaltet. Damit kannst du zur Abzeige des "Bearbeiten"- und "Löschen"-Buttons granular abfragen, ob der Nutzer das überhaupt darf. Sofern angemldete Benutzer innerhalb der für sie sichtbaren Foren ihre Beiträge nicht mehr selbst löschen können sollten, nimmst du der Rolle einfach die Permission "delete_own_threads" weg. Sofern du das auf einzelne Posts restriktieren möchtest, muss einfach eine derartige Funktions-Berechtigung definiert und gesetzt sein.

Zitat:

Das hat aber an dieser Stelle nichts mehr mit RBAC zu tun. Ich habe unzählige Artikel gelesen. Aber in keinem war die Rede davon, dass es auch möglich ist, Rechte direkt an Benutzer zu knüpfen. Das ist ja glaube ich auch ein Merkmal von RBAC. Es geht mir also darum, dass es Rechte geben muss, die nicht in Rollen sein dürfen, sondern dem User direkt zugeteilt sind. Also eine Art ACL neben dem RBAC.

Soweit ich mich erinnern kann, haben wir im APF-Forum auch eine ähnliche Diskussion geführt und festgestellt, dass es mit dem umgt-Modul trotzdem realisierbar ist - es ist nur etwas Umdenken notwendig. Wenn du möchtest, diskutieren wir ein paar Beispiele, die die Abbildung deiner Anforderungen auf das RBAC beschreiben. Ich denke, dann wird es sicher klar(er).

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Komisches Verhalten von $this bei Vererbung	delta	PHP Tipps 2010	27	05.05.2010 17:49
Singleton mit Vererbung -> Ctor Problem	Alex04	PHP-Fortgeschrittene	3	28.03.2010 14:05
Eine Nutzerverwaltung mit Rechten erstellen	timmeyy	PHP Tipps 2009	26	31.07.2009 20:55
Singleton Model oder Vererbung ?	MollocH	PHP-Fortgeschrittene	2	10.02.2009 20:32
[Erledigt] "Klassen" und sinvolle Vererbung	phpdummi	JavaScript, Ajax und mehr	8	28.01.2009 04:01
CSS: div am rechten Rand positieren	Autoterrorist	HTML, Usability und Barrierefreiheit	3	31.07.2008 14:09
Vererbung - Include?	Igäl	PHP Tipps 2008	13	17.08.2007 10:10
Klasse und Vererbung	Rio99	PHP Tipps 2006	4	05.07.2006 16:41
PHP5: DOMDocument + vererbung	Syntaxx	PHP-Fortgeschrittene	4	07.06.2006 09:02
Frage zur Vererbung	250Euro	PHP-Fortgeschrittene	3	15.05.2006 08:53
Vererbung bei Templates	Pain-maker	PHP-Fortgeschrittene	9	28.03.2006 10:05
Vererbung von Klassen und Performance	ggfan	PHP Tipps 2006	5	05.03.2006 12:00
probleme mit rechten an einem ordner: nicht veränderbar?!?!?	Promaetheus	PHP Tipps 2004	8	30.10.2004 18:42
Datenmodell Antragsbearbeitung Rollen?		PHP Tipps 2004	3	14.07.2004 22:41
Datenmodell Antragsbearbeitung Rollen?		Datenbanken	0	14.07.2004 00:57

20.10.2010, 18:05
Geryon Benutzer Registriert seit: 04.10.2010 Beiträge: 62 PHP-Kenntnisse: Fortgeschritten	[Erledigt] Funktionsberechtigungne, Rollen und Vererbung von Rechten Hallo, mich würde interessieren, ob ich in folgender Überlegung Funktionsberechtigungen, Rollen und die Vererbung von Rollen designtechnisch gut umgesetzt habe. Für mein CMS benutze ich Funktionsberechtigungen. An einem Punkt im System wird abgefragt, ob eine Funktion mit dem angegebenen Parameter überhaupt ausgeführt werden darf. Diese Funktionalität ist Grundlegend und gilt somit für fast alle Funktionen im System, die über eine bestimmte Methode aufgerufen werden. Also auch für alle Extensions von Dritten. Zum Beispiel: Darf ich die Funktion artikelBearbeiten() mit dem Parameter 4 ausführen? Also den Artikel mit der ID 4 bearbeiten? Ich habe hier zunächst einmal mein Datenbankmodell beschrieben. Ich denke daran lässt sich das alles am einfachsten veranschaulichen. Grundlegend verfügt jeder User über eine einzige Rolle (siehe Tabelle USERS). Diese bündelt Rechte. Des Weitern können Rechte Benutzern auch direkt zugeteilt werden. Das ist sinnvoll, wenn es zum Beispiel darum geht einen eigenen Beitrag zu bearbeiten oder zu löschen. Die Zuteilung der Rechte an User oder an Rollen geschieht in der Tabelle RIGHT_BIND. Wobei ich mir noch unsicher bin ist die Art und Weise wie Rollen bei mir Teile einer anderen Rolle werden können. (Ist Vererbung hier das richtige Wort?)Ich habe das in der Datenbank mit roll_parent beschrieben. Siehe Tabelle ROLLS. Und eine andere Frage, die mich dahingehend beschäftigt ist das Ausmaß an Datenmengen, die meine Tabelle RIGHT_BIND annehmen würde. So würde zum Beispiel dort für jeden User gespeichert werden, welchen seinen eigenen Beiträge er bearbeiten oder löschen darf. Und da ja die Rollen rekursiv geladen werden, also die Rechte von Unterrollen der jeweiligen Rolle mit einbezogen werden, würde sich für Benutzer der Rolle Administrator, oder Forummoderatoren eine gewaltige Datenmenge beim laden der Rolle ergeben. Weil ja eben die Rechte aller Unterrollen mit einbezogen würden. Denn ein Moderator soll ja zum Beispiel auch alles bearbeiten oder löschen dürfen. Daher braucht er die Rechte der schreibenden Benutzer auch. Und da ist jetzt meine Frage, ob es dann wirklich Sinn macht alle Rechte des Administrators zum Beispiel in ein Array zu speichern. Der Administrator wäre in diesem Fall also die größte 'Vaterrolle'. Alle anderen würden dieser Rolle unterstehen und es würde sich eine hierarchische Struktur in der Datenbank bilden. Vielleicht gibt es aber auch grundlegende andere Kritik an dieser Vorgehensweise allgemein. Da bin ich mir sogar ziemlich sicher . Code: Tabelle: USERS -> speichert alle benutzer user_id user_nick user_mail user_pw user_roll 1 admin admin@admin.com md5 1 //unser administrator mit der administrator rolle 2 nickname mail@mail.com md5 2 //ein redakteur Tabelle: Rolls -> speichert alle rollen roll_id roll_name roll_description roll_parent 1 Administrator bliblatext //die Administrator Rolle 2 Redakteur bliblatext 1 3 Moderationsbereich1 bliblatext 5 //diese rolle ist teil von rolle 5 4 Moderationsbereich2 bliblatext 5 //diese rolle ist teil von rolle 5 5 SuperModerator bliblatext 1 6 Entwicklerrolle1 bliblatext 1 7 Entwicklerrolle2 bliblatext 1 TABELLE: RIGHTS -> speichert alle funktionen, deren Ausführung geprüft werden muss right_id right_function 1 drawPage //php funktion zum laden einer seite 2 editFile //php funktion zum bearbeiten einer datei 3 editPost //php funktion zum bearbeiten eines beitrags 4 editArticle //php funktion zum bearbeiten eines artikels TABELLE: RIGHT_BIND right_user right_roll right_id right_reference 1 1 4 //ich darf die funktion drawPage mit dem parameter (4) aufrufen 1 4 1 //ich darf die funktion editArticle mit dem parameter (1) aufrufen 1 4 2 //ich darf die funktion editArticle mit dem parameter (2) aufrufen 1 4 3 //ich darf die funktion editArticle mit dem parameter (3) aufrufen 1 4 4 //ich darf die funktion editArticle mit dem parameter (4) aufrufen 1 4 5 //ich darf die funktion editArticle mit dem parameter (5) aufrufen 1 4 6 //ich darf die funktion editArticle mit dem parameter (6) aufrufen 1 2 1 //ich darf die funktion editFile mit dem parameter (1) aufrufen 1 3 1 //ich darf die funktion editPost mit dem parameter (1) aufrufen 1 3 2 //ich darf die funktion editPost mit dem parameter (2) aufrufen 1 3 3 //ich darf die funktion editPost mit dem parameter (3) aufrufen 1 3 4 //ich darf die funktion editPost mit dem parameter (4) aufrufen 1 3 5 //ich darf die funktion editPost mit dem parameter (5) aufrufen 1 3 6 //ich darf die funktion editPost mit dem parameter (6) aufrufen Das solltet ihr am Besten in einen Texteditor kopieren...dann ist das besser lesbar... Edit: habe gerade gesehen, dass ich mich im Titel vertippt habe...könnte das evtl. jemand ändern? Geändert von Geryon (20.10.2010 um 18:36 Uhr).


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

20.10.2010, 18:38
Geryon Benutzer Registriert seit: 04.10.2010 Beiträge: 62 PHP-Kenntnisse: Fortgeschritten	Sorry. Ich hoffe jetzt ist es besser. Es sind die Strukturen von 4 Tabellen abgebildet. Die erste Zeile einer Tabelle beschreibt den Namen der jeweiligen Spalte.

20.10.2010, 22:52
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Hallo Geryone, hast du dir mal die Threads zu diesem Thema hier angesehen? Wir haben kürzlich unter http://www.php.de/software-design/50...erwaltung.html (Rechteverwaltung) über das Thema ausführlich diskutiert. Zu der von mir dort vorgeschlagenen Lösung hätte ich auch hier tendiert, da es weniger um Vererbung, denn um generische Abbildung von Funktions-Berechtigungen auf Rollen geht. Darüber hinaus sollte dieses Konzept mit Sichtbarkeits-Berechtigungen kombiniert, deinen Anwendungsfall abdecken. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

21.10.2010, 21:48
Geryon Benutzer Registriert seit: 04.10.2010 Beiträge: 62 PHP-Kenntnisse: Fortgeschritten	Hallo und danke für die Antwort. Ja ich habe dieses Thema ausführlich gelesen. Und auch verstanden soweit ich glaube. Nur ist mir das alles etwas tu theoretisch. Mir ist allerdings erst jetzt wieder aufgefallen, das ich schon wieder Rollen und Gruppen vermixt habe. Aber das soll erstmal nicht so wild sein. Ich wollte einfach mal eine praxisnähere Diskusion anstreben. Zunächst stellt sich mir die Frage ob das was ich da tue wirklich Funktionsberechtigungen sind, und ob das so gängig ist. Also ich meine vor einem call() speziell zu erfragen, ob eine Funktion mit einem gewissen Parameter ausgeführt werden darf. Und des weiteren bin ich mir einfach unsicher, ob ich alle Rechte von Anfang an laden soll oder ob es besser ist, das Recht erst dann aus der Datenbank zu erfragen, wenn es benötigt wird. Denn ersteres könnte sehr viel Speicher beim Ausführen der Anwendung zur Folge haben und letzteres ist Datenbankintensiver. Zumindest in meiner aktuellen Vorstellung.

24.10.2010, 14:09
Geryon Benutzer Registriert seit: 04.10.2010 Beiträge: 62 PHP-Kenntnisse: Fortgeschritten	Hallo. Danke für die Antwort. Ich werde mir die genannten Vorschläge in den nächsten Tagen mal genauer ansehen. Ich denke ich habe den Ansatz RBAC - besonders Version 2 - ganz gut verstanden. Nur etwas bleibt für mich dabei offen. Da ich eigentlich aus dem Bereich ACL komme habe ich ne Weile gebraucht um das RBAC zu begreifen. Dennoch fehlt mir dort etwas. Beim RBAC werden Rollen benutzt um Rechte zu bündeln. Und durch Vererbung kann man mit den Rollen auch indirekt Benutzer bündeln. Jede Rolle beinhaltet Rechte, die aus Objekten und Aktionen bestehen. Soweit ist mir das total klar. Jetzt kommt mein Problem: Ein Benutzer hat das Recht, dass er im Forum mit der ID 3 einen neuen Beitrag verfassen darf. Dazu hat er die Rolle "Forum User" inne. Um seinen eigenen Beitrag jedoch löschen oder bearbeiten zu dürfen müssen diese beiden neuen Rechte unmitelbr und ohne Rolle dem User zugeordnet werden. Das hat aber an dieser Stelle nichts mehr mit RBAC zu tun. Ich habe unzählige Artikel gelesen. Aber in keinem war die Rede davon, dass es auch möglich ist, Rechte direkt an Benutzer zu knüpfen. Das ist ja glaube ich auch ein Merkmal von RBAC. Es geht mir also darum, dass es Rechte geben muss, die nicht in Rollen sein dürfen, sondern dem User direkt zugeteilt sind. Also eine Art ACL neben dem RBAC. Ich hoffe ich konnte mein Problem so ganz gut verdeutlichen