Ankündigung

Einklappen
Keine Ankündigung bisher.

Rechteverwaltung

Einklappen

Neue Werbung 2019

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

  • Rechteverwaltung

    Hallo!

    Ich habe vor langer Zeit mal ein eigenes Rechtesystem vorgestellt, das allerdings sehr beschränkt war. Da ich das erkannt hatte habe ich mich einfach mal nach der "Best Practice Benutzerverwaltung" erkundigt. Nun ist es soweit und ich möchte mich endlich an eine oder auch mehrere Klassen setzen, die mir das Verwalten von Nutzern erleichtern sollen. Doch nichts geht ohne ein Konzept und ich würde dies gerne mal mit euch durchkauen.

    Ich habe mir überlegt das ganze auf drei Tabellen zu verteilen. Und zwar soll es eine Tabelle user, die die Benutzerdaten enthält, eine Tabelle categories, für die verschiedenen Bereiche und eine Tabelle permissions für die Rechteverteilung geben.

    Code:
    Table `user`:
    +----+------+
    | id | name |
    +----+------+
    |  1 | Joe  |
    |  2 | Max  |
    |  3 | Mic  |
    +----+------+
    
    
    Table `categories`:
    +----+---------------------+
    | id | name                |
    +----+---------------------+
    |  1 | Artikel lesen       |
    |  2 | Artikel schreiben   |
    |  3 | Artikel feigeben    |
    |  3 | Kommentar lesen     |
    |  3 | Kommentar schreiben |
    |  3 | Kommentar feigeben  |
    +----+---------------------+
    
    
    Table `permissions`:
    +--------+---------+
    | userid | perms   |
    +--------+---------+
    |      1 |       1 |
    |      2 |       1 |
    |      3 |       1 |
    |      3 |       2 |
    +--------+---------+
    Bei den Klassen wollte ich wie immer auf MySQLi setzen. Was haltet ihr davon? Wie würdet ihr die dazugehörigen Klassen aufbauen? Freue mich auf eure Antworten und Anregungen.

    MfG, Andy


  • #2
    kleiner Hinweis vorweg: category

    - Weitere Kategorien wären: Artikel editieren und löschen, Rechte vergeben, User 'anheuern' und weitere Meta-Rechte.
    - Gruppen wären gut, die Kategorien und/oder User bündeln
    - Wie sieht denn das Konzept über die reine DB Struktur hinaus aus?
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Guter Hinweis .... ....

      Kommentar


      • #4
        Es kommt natürlich darauf an, wo du die Rechteverwaltung einsetzt, aber zB. bei einem cms wäre es doch wünschenswert, wenn man einem User auf einigen Unterseiten zB. das Recht zum Bearbeiten geben kann, während er auf anderen Seiten gar nichts darf.

        Kommentar


        • #5
          Hallo Andy,

          wenn es dich interessiert, dann schau mal hier vorbei. auf dieser Seite habe ich ein Benutzer-Management vorgestellt, mit dem das Thema Funktionsberechtigungen gelöst wird. Aus deinen Schilderungen lese ich, dass du nicht nur Rechte auf Objekte (=Blog-Beitrag, ...), sondern auch Rechte auf Funktionen innerhalb einer Applikation verwalten möchtest (=Blog-Beitrag editieren, ...). Dies kann mit dem vorgestellten Datenmodell implizit über die Rolle eines Benutzers (innerhalb einer Applikation) gesteuert werden. Jeder Benutzer erhält über seine Rolle mehrere Permissions, die eine Zuordung von Identifiern und Werten enthalten (z.B. loadadminmenu=true).

          Rechte auf Objekte können ganz einfach damit abgebildet werden, dass eine Beziehung zwischen einem Benutzer oder einer Gruppe auf ein Objekt deiner Anwendung hergestellt wird (siehe Diskussion in den von dir verlinkten Threads).
          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!
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

          Kommentar


          • #6
            Interessant wär es vielleicht eine Usereigenschaft "Rechte" als Bitmuster zu haben.

            z.B.:
            Rechte: Lesen, Schreiben, Neu erstellen

            Alle gesetzt (User hat alle Rechte) wäre 111.

            So kann man z.B. eine Gruppe Besucher haben mit den Rechten 100, aber dennoch einzelnen Usern das Recht zum schreiben geben:

            ......100
            XOR 010
            ----------
            ergibt 110

            Mit AND, NOT und OR ergeben sich weitere interessante Möglichkeiten:
            so können einem User mit AND Rechte entzogen werden.
            Bei AND kann er aber nie mehr Rechte bekommen als die Gruppe hat
            der er angehört.
            Eine if-else-Abfrage nimmt, ordentlich geschrieben eine Menge Platz weg. Platzsparend geht es mit einem ternären Operator.

            Kommentar


            • #7
              Das Thema Bitmuster wurde, glaube ich, im oben verlinkten Thread auch schon ausgiebig diskutiert.
              --

              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
              Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


              --

              Kommentar


              • #8
                Ja ich habe eine komplette Klasse vorgestellt, die sich mit diesem Thema beschäftigt hat. Sie war sogar sehr performant, erlaubte aber keine Gruppen und zudem kann man maximal 64 Rechte vergeben, da der Integer in PHP nur bis 2^64 Bit geht.
                MfG, Andy

                Kommentar


                • #9
                  Baue gerade ein bisschen an einem RolllBasedAccessControl-System rum. Ist vielleicht auch eine Alternative. Wenn Interesse besteht kann ich auch ein bisschen meine Idee bzw. Implementierung posten.

                  Kommentar


                  • #10
                    Da wir uns im Softwaredesign-Forum befinden ist das genau der richtige Ort um Konzepte zu diskutieren. Hast du das von mir verlinkte UML mal angesehen? Geht das in deine Richtung?
                    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!
                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                    Kommentar


                    • #11
                      Hey,

                      ja hab ich mir angeschaut und es geht in meine Richtung. Aber ich habe zwei Klassen komplett weggelassen. Hier ist eine UML, leider nicht so ausführlich aber zur Veranschaulichung reicht es hoffentlich.

                      UML

                      Wofür brauchst du noch eine Permissions-Set? Ich geb der Rolle einfach unendlich viele Permissions ohne ein Set.

                      Wenn ich das richtig verstanden hab kannst du deiner Gruppen auch eine Permission oder ein PSet zuweisen. Aber im Endeffekt ist eine Gruppe dann doch sehr ähnlich einer Rolle, oder? Ich denke, dass ich die Idee hinter einer Gruppe noch nicht verstanden hab. Für mich vergibt sich dadurch irgendwie keine Erleichterung bzw. Verbesserung des Access Controlling.

                      Kommentar


                      • #12
                        Hallo Bumpy,

                        ich bin mir bei der Bedeutung der Beziehungen in deinem Diagramm noch nicht ganz schlüssig. Was bedeutet die gestrichelte Linie zwischen Applikation und Benutzer? Ist das eine Assoziation? Falls ja, ist das problematisch, denn wenn der Benutzer seine Applikationen kennen muss, ist dieser Design-technisch nicht unabhängig genug. Weiterhin fehlen mir Gruppen und weitere Ordnungscontainer, die eine Zugehörigkeit der Strukturelemente zeigen. Ein Benutzer sollte immer unter einer Organisationseinheit hängen - wie im richtigen Leben eben.

                        Wie ist die Beziehung zwischen dem Controller und der Rolle/dem Benutzer ausgeprägt? Sollte ein (MVC)-Controller nicht eine Business-Schicht konsumieren um die relevanten Tasks der Präsentationsschicht zu erledigen? Mir vermischt das Diagramm ein wenig das reine Domänen-Modell mit dem Klassendiagramm einer Anwendung.

                        Wofür brauchst du noch eine Permissions-Set? Ich geb der Rolle einfach unendlich viele Permissions ohne ein Set.
                        Es geht dabei einerseits um Klassifizierung von Permissions (z.B. Funktionsberechtigungen auf ein Modul "Gästebuch") und um die Wiederverwendbarkeit. Würde eine Rolle - wie vermutlich in deinem Fall - direkt einer Rolle zugewiesen dein (Komposition), kann die Funktionsberechtigung keiner anderen Rolle mehr zugewiesen werden. Im realen Anwendungsfall wirst du jedoch immer mit dem Problem zu kämpfen haben, dass eine Admin-Rolle eines Moduls auch Lesefunktionsrechte hat, bzw. Eigenschaften eines Objekts einsehen darf (ro).

                        Wenn ich das richtig verstanden hab kannst du deiner Gruppen auch eine Permission oder ein PSet zuweisen. Aber im Endeffekt ist eine Gruppe dann doch sehr ähnlich einer Rolle, oder?
                        Eben nicht. Gruppen sind Strukturelemente die zur Zugriffsberechtigung auf Objekte einer Anwendung eingesetzt werden und Rollen regeln den Zugriff auf Funktionen. In einfachen Anwendungen mag das sicher so reichen, nur die konsequente Trennung der beiden Bereiche ermöglicht es, z.B. einem Benutzer in einem CMS Rechte auf einen Inhalt zu geben, den er auch bearbeiten kann, nur online stellen ist ihm untersagt.
                        Nur so kannst du echte Rollen (=~ Sichten auf eine Anwendung) bereitstellen.

                        Ich denke, dass ich die Idee hinter einer Gruppe noch nicht verstanden hab. Für mich vergibt sich dadurch irgendwie keine Erleichterung bzw. Verbesserung des Access Controlling.
                        Wie bereits angesprochen muss du hier zwischen den Bedeutungen unterscheiden. Beide "Gebiete" verfolgen eine andere Zielsetzung in einer Anwendung / in einem Modul.

                        Ich hoffe, ich konnte soweit zum Verständnis des Konzeptes beitragen. Wichtig ist hier vor allem, dass du das Objekt- bzw. Domänen-Modell unabhängig der Anwendung skizzierst. So bist du von Beginn an gezwungen über ein allgemeingültiges Szenario nachzudenken.
                        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!
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                        Kommentar


                        • #13
                          Hey,

                          danke für deine ausführliche Antwort. Mein Uml, also das Klassendiagram war ein bisschen stürmisch heute nacht gemacht. Ich hab heute nochmal ein paar Klassendiagramm, UseCases und Systemklassenmodell entworfen (Da ich UML gerade sowieso lernen (vertiefen) muss, dachte ich mir dass ich noch ein bisschen weiter entwerfen kann). Ich setze das Systemklassenmodell ans Ende des Beitrags, erstmal wollte ich auf ein paar deiner Antworten eingehen.

                          Zitat von dr.e. Beitrag anzeigen
                          Es geht dabei einerseits um Klassifizierung von Permissions (z.B. Funktionsberechtigungen auf ein Modul "Gästebuch") und um die Wiederverwendbarkeit. Würde eine Rolle - wie vermutlich in deinem Fall - direkt einer Rolle zugewiesen dein (Komposition), kann die Funktionsberechtigung keiner anderen Rolle mehr zugewiesen werden. Im realen Anwendungsfall wirst du jedoch immer mit dem Problem zu kämpfen haben, dass eine Admin-Rolle eines Moduls auch Lesefunktionsrechte hat, bzw. Eigenschaften eines Objekts einsehen darf (ro).
                          Den markierten Teil kann ich nicht ganz verstehen, aber ich glaube du meinst, wenn ich einer Rolle direkt eine Permission zuweise. Nur ist mir nicht kann klar warum ich verschiedenen Rollen nicht die gleichen Permissions geben kann. Ich mach es so, dass manche Rollen nur Zugriffsrechte haben und andere wiederum auch Bearbeitungs- wie Hinzufügrechte besitzen. Ist da bei mir irgendein Denkfehler drin??


                          Zitat von dr.e. Beitrag anzeigen
                          Eben nicht. Gruppen sind Strukturelemente die zur Zugriffsberechtigung auf Objekte einer Anwendung eingesetzt werden und Rollen regeln den Zugriff auf Funktionen. In einfachen Anwendungen mag das sicher so reichen, nur die konsequente Trennung der beiden Bereiche ermöglicht es, z.B. einem Benutzer in einem CMS Rechte auf einen Inhalt zu geben, den er auch bearbeiten kann, nur online stellen ist ihm untersagt.
                          Nur so kannst du echte Rollen (=~ Sichten auf eine Anwendung) bereitstellen.


                          Wie bereits angesprochen muss du hier zwischen den Bedeutungen unterscheiden. Beide "Gebiete" verfolgen eine andere Zielsetzung in einer Anwendung / in einem Modul.
                          Das heißt du legst mit deinen Gruppen die "Sichtbarkeit" einer Seite/Objekt fest. Alles weiteres machen dann die Rollen. z.B.

                          Ein User ist in Gruppe "User" hat aber als Rolle "Moderator" und darf nicht nur Artikel anschauen sondern auch verändern bzw. neue hinzufügen. Richtig?

                          Ich regele das direkt über die Permissions. Entweder man hat die Permissions zum Bearbeiten oder nicht und so weiter.

                          Hier ist jetzt mein Systemklassenmodell:
                          Systemklassenmodell

                          Bitte nicht so viel Beachtung auf die Assoziationen, die Name sind teils nicht so optimal gewählt.

                          gruß b.j.

                          Kommentar


                          • #14
                            Hallo,

                            Den markierten Teil kann ich nicht ganz verstehen, aber ich glaube du meinst, wenn ich einer Rolle direkt eine Permission zuweise. Nur ist mir nicht kann klar warum ich verschiedenen Rollen nicht die gleichen Permissions geben kann. Ich mach es so, dass manche Rollen nur Zugriffsrechte haben und andere wiederum auch Bearbeitungs- wie Hinzufügrechte besitzen. Ist da bei mir irgendein Denkfehler drin?
                            Es geht um die Korrektheit des Datenmodells. Wenn du darin den Anspruch erhebst, dass eine Permission unterhalb einer Rolle komponiert ist, macht es keinen Sinn diese zu einer weiteren Rolle zu assoziieren. Das sprengt den Wirkungsbereich des Objekts. Das bedeutet im Umkehrschluss, dass eine Permission - sofern du diese in mehreren Rollen verwenden möchtest - nur zu dieser assoziiert sein darf. Sonst ist eine Permission zu abhängig von einer Rolle!

                            Das heißt du legst mit deinen Gruppen die "Sichtbarkeit" einer Seite/Objekt fest. Alles weiteres machen dann die Rollen. z.B.

                            Ein User ist in Gruppe "User" hat aber als Rolle "Moderator" und darf nicht nur Artikel anschauen sondern auch verändern bzw. neue hinzufügen. Richtig?
                            Die Trennung ist: Rechtezuweisung auf Objekte passiert über Gruppen (und natürlich direkt über eine Assoziation zu einem Benutzer direkt), Rechtezuweisung auf Funktionen einer Applikation steuern Rollen. In deinem Beispiel bedeutet das, dass ein Benutzer A Sichtbarkeitsrechte (über eine Gruppe oder eine direkte Beziehung zu den relevanten Objekten) auf bestimmte Objekte hat, mit diesen jedoch nur diejenigen Aktionen ausführen darf die auch in seiner Rolle definiert sind.

                            Ich regele das direkt über die Permissions. Entweder man hat die Permissions zum Bearbeiten oder nicht und so weiter.
                            Dann sind deine Aussagen und dein UML falsch. Dort steht, dass Permissions dem Benutzer über eine Rolle zuweist. Das ist auch gut so, sonst müsstest du jedem Benutzer erneut alle relevanten Permissions zuweisen. Das ist unbenutzbar.
                            Weiterhin solltest du das Domänen-Modell vom Klassenmodell der Anwendung trennen. Das System-Diagramm ist IHMO immernoch verwirrend.

                            Bitte nicht so viel Beachtung auf die Assoziationen, die Name sind teils nicht so optimal gewählt.
                            Ich will nicht pedantisch wirken, aber ein UML muss korrekt sein! Andernfalls bietet es Platz für zu viel Interpretationsspielraum und wird von unterschiedlichen Entwicklern unterschiedlich verstanden.
                            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!
                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                            Kommentar


                            • #15
                              So,

                              hab jetzt noch mal ein UML-Diagram überarbeitet. Hab jetzt noch ein zusätlichen Controller eingesetzt, der als WebController fungiert um halt anfragen eines Users abzuarbeiten. Ich glaube den Punkt hatteich noch nicht bedacht. Dazu hab ich jetzt Aggregation, Komposition und Multiplizitäten hinzugefügt. Desweiteren hab ich mir erlaubt die Benennung der Assoziation nach deiner Konfektion umzuändern, so ist das Diagram wohl leichter zu verstehen. Wäre aber immernoch super wenn du mich auf Fehler aufmerksam machst.

                              Nochmal zum Thema Gruppen. In meinem System sind kein Gruppen vorgesehen, da ich glaube, dass ich sie nicht brauche. Ich arbeite einfach nur mit Rollen. Wie du hoffentlich jetzt sehen kannst bekommt jeder Benutzer n Rollen zugewiesen und nur allein an den entscheide ich ob er genug Rechte hat um das Objekt zuberachten bzw. die Objektoperationen auszuführen.
                              Nichtsdestotrotz werde ich mir den (dein) Ansatz nochmal genau durch den Kopfgehen lassen und schauen ob es nicht vielleicht doch sinnvoll ist diese Methode zu verwenden.

                              UML

                              Kommentar

                              Lädt...
                              X