Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Funktionsberechtigungne, Rollen und Vererbung von Rechten

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [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?

  • #2
    Das solltet ihr am Besten in einen Texteditor kopieren...dann ist das besser lesbar...
    Kann ich nicht bestätigen
    [COLOR="#F5F5FF"]--[/COLOR]
    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
    [COLOR="#F5F5FF"]
    --[/COLOR]

    Kommentar


    • #3
      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.

      Kommentar


      • #4
        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 ü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 [B]before[/B] you start to write code!
        2. Discuss and review it together with [B]experts[/B]!
        3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
        4. Write [I][B]clean and reusable[/B][/I] software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar


        • #5
          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.

          Kommentar


          • #6
            Hallo Geryon,

            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.

            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.

            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).

            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.
            Viele Grüße,
            Dr.E.

            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            1. Think about software design [B]before[/B] you start to write code!
            2. Discuss and review it together with [B]experts[/B]!
            3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
            4. Write [I][B]clean and reusable[/B][/I] software only!
            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            Kommentar


            • #7
              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:

              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.

              Kommentar


              • #8
                Hallo Geryon,

                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.

                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.

                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.

                Danke aber schonmal, dass du dir die Zeit für Beispiele genommen hast.
                Gerne.
                Viele Grüße,
                Dr.E.

                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                1. Think about software design [B]before[/B] you start to write code!
                2. Discuss and review it together with [B]experts[/B]!
                3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                4. Write [I][B]clean and reusable[/B][/I] software only!
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                Kommentar


                • #9
                  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

                  Kommentar


                  • #10
                    Hallo Geryon,

                    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.

                    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).
                    Viele Grüße,
                    Dr.E.

                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    1. Think about software design [B]before[/B] you start to write code!
                    2. Discuss and review it together with [B]experts[/B]!
                    3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                    4. Write [I][B]clean and reusable[/B][/I] software only!
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                    Kommentar


                    • #11
                      Zitat von dr.e. Beitrag anzeigen
                      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.
                      Das klingt echt gut. Daran habe ich noch garnicht gedacht. Denn es handelt sich ja tatsächlich bis jetzt immer um Rechte, die direkt etwas mit Besitz zutun haben. Also die Rechte, die direkt ohne Rolle an einen User gebunden sein müssten. Wenn ich das weiter denke, dann müste es neben dem RBAC noch irgendeine Art von Besitzverwaltung geben. Und diese Besitze müssten auch durch die Rollenhierarchie durchweg vererbt werden damit auch der Admin die edit_own_thread des unterstehenden Users nutzen könnte.

                      Das mit dem Forum ist im Übrigen auch nur ein erfundenes Beispiel von mir andem ich mir das Problem veranschaulicht habe.

                      Wenn du möchtest, diskutieren wir ein paar Beispiele, die die Abbildung deiner Anforderungen auf das RBAC beschreiben.
                      Ja gerne doch. Wenn nicht zu sehr APF lastig wird ... weiß ja mitlerweile, dass das dein Spezialgebiet ist.

                      Kommentar


                      • #12
                        Hallo Geryon,

                        Wenn ich das weiter denke, dann müste es neben dem RBAC noch irgendeine Art von Besitzverwaltung geben.
                        Korrekt. Das bezeichnete ich mit "Sichtbarkeitsberechtigung". Hier geht es darum, dass ein Benutzer ein Objekt sehen darf oder eben nicht. Du kannst das mehr oder weniger mit Dateisystem-Berechtigungen vergleichen.

                        Und diese Besitze müssten auch durch die Rollenhierarchie durchweg vererbt werden damit auch der Admin die edit_own_thread des unterstehenden Users nutzen könnte.
                        Hierzu kannst du eine Abstraktion der Funktions-Berechtigungen gegenüber Rollen einführen. Das umgt-Modul des APF kennt hierzu beispielsweise Permission-Sets, die einer Rolle zugewiesen werden. Damit ist es sehr einfach Berechtigungen in unterschiedlichen Rollen zu "vererben".

                        Ja gerne doch. Wenn nicht zu sehr APF lastig wird ... weiß ja mitlerweile, dass das dein Spezialgebiet ist.
                        Wenn du das APF nicht nutzen möchtest ist das deine Entscheidung. Ich akzeptiere das, jedoch behalte ich mir trotzdem vor, Beispiele mit APF-Code zu posten. Denn warum sollte man Dinge immer wieder neu erfinden, wenn es schon fertige und vernünftig verwendbare Tools gibt. Es schreibt sich schließlich auch nicht jeder eben ein OS für seinen PC zu Hause nur weil LINUX das Spezialgebiet seines Arbeitskollegen ist.
                        Viele Grüße,
                        Dr.E.

                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                        1. Think about software design [B]before[/B] you start to write code!
                        2. Discuss and review it together with [B]experts[/B]!
                        3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                        4. Write [I][B]clean and reusable[/B][/I] software only!
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                        Kommentar


                        • #13
                          Korrekt. Das bezeichnete ich mit "Sichtbarkeitsberechtigung". Hier geht es darum, dass ein Benutzer ein Objekt sehen darf oder eben nicht. Du kannst das mehr oder weniger mit Dateisystem-Berechtigungen vergleichen.
                          Und diese Sichtbarkeitsberechtigungen dürfen nicht an die Rollen gebunden sein. Sondern irgendwie an die User.

                          Wenn du das APF nicht nutzen möchtest ist das deine Entscheidung.
                          Verstehe dich schon. Ich werd mich klar auch auf das APF einlassen. Evtl. finde ich ja noch Gefallen daran.

                          Kommentar


                          • #14
                            Und diese Sichtbarkeitsberechtigungen dürfen nicht an die Rollen gebunden sein. Sondern irgendwie an die User.
                            Korrekt. Als Möglichkeit zur Strukturierung sollten hierfür idealerweise auch Gruppen zur Verfügun stehen. Im Klartext:

                            Code:
                            Object <----- User
                            ^
                            |
                            +-------------Group
                            Verstehe dich schon. Ich werd mich klar auch auf das APF einlassen. Evtl. finde ich ja noch Gefallen daran.
                            Dagegen hätte ich nicht einzuwenden. Apropos: schau dir mal das UML-Diagramm unter http://adventure-php-framework.org/S...-1-Datenmodell an, dort findest du die Zuordnung in Form der Beziehung der AppProxy <--> User und AppProxy <--> Group. AppProxy ist in diesem Fall das Proxy-Objekt auf das reale Objekt in deiner konkreten Anwendung (siehe oben).
                            Viele Grüße,
                            Dr.E.

                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                            1. Think about software design [B]before[/B] you start to write code!
                            2. Discuss and review it together with [B]experts[/B]!
                            3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
                            4. Write [I][B]clean and reusable[/B][/I] software only!
                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                            Kommentar


                            • #15
                              Hi

                              Du meinst, dass Benutzer in Gruppen gebündelt werden, und dass diese Gruppen Besitz an einem oder mehreren Objekt haben oder? Das sagt auch das uml glaube ich aus.



                              Wollte das hier noch gerade los werden. Nur so nebenbei. Wirklich sehr genial gemacht:

                              http://dbis.ipd.uni-karlsruhe.de/download/SS07GroppRbac-Ausarbeitung.pdf

                              Kommentar

                              Lädt...
                              X