nicht angemeldet
Wohin mit zusätzlichen Attribute zur Rechteverwaltung?
Hallo liebe Experten,
in meiner Datenbank gibt es aktuell 3 Tabellen für "Users", "Lists" und eine Join-Tabelle "Users_Lists", um die n-zu-m Beziehungen zu speichern. Jetzt möchte ich festlegen, welcher User welche Rechte auf einer Liste hat, z.B. "editieren", "löschen" usw. Es gibt aus meiner Sicht zwei Möglichkeiten, das zu tun: einmal rollenbasiert, indem ich sage: User X hat auf der Liste die Rolle "Chef-Admin" und diese Rolle darf löschen und editieren. Die andere Möglichkeit wäre das attributsbasiert zu machen, also für jede Liste zu sagen, er darf löschen, editieren etc. In beiden Fällen brauche ich zusätzliche Attribute und meine Frage ist, ob das Vorgehen, die zusätzlichen Attribute an die Join-Tabelle zu hängen sinnvoll ist oder ob man da besser einen ganz anderen Ansatz nimmt?
Vielen Dank!
Günther
-
Nochmals hallo,
wenn Google manches Mal nicht weiterhilft, dann ein gutes altes Buch :) Habe gerade einen Artikel in einem Buch gefunden, der den Bezug zwischen "Zeitungen" und "Lesern" über "Abonnements" herstellt und Abonnements ist in diesem Fall eine erweiterte Join-Tabelle genau so wie ich mir das vorstelle.
Danke dennoch und Gruß,
Günther-
hi,
wenn Google manches Mal nicht weiterhilft, dann ein gutes altes Buch :)
Das kann ich bestätigen. Hab neulich sogar den Gang in die Badische Landesbibliothek nicht gescheut und auch nicht die 8 € Gebühr, weil ich zu einer bestimmten Frage im Internet auch nach Tagen keine befriedigende Antwort fand. In einem der beiden ausgeliehenden Bücher fand ich dann das Gesuchte...
Was natürlich nicht heißen soll, dass das Forum nicht helfen kann ;-)
Viele Grüße,
Horst Haselhuhn--
Auch mit den richtigen Suchbegriffen kann das Suchergebnis falsch sein.
-
Hehe, bei mir war es zwar nicht die BLB aber die UniBib in Karlsruhe ;)
Viele Grüße,
Günther
-
-
-
Hello,
die Verwaltung horizontaler Rechte pro User können die meisten Datenbank-Management-Systeme bestens alleine. Du kannst diesen Mechanismus nutzten.
Als Beispiel betrachten wir mal MySQL, das per PHP-Script bedient werden soll. Das bedeutet, das im ersten Schritt der User üblicherweise ein speziell festgelegter für alle Aktionen der Script ist.
Das kann an aber ändern. Wenn der User, der die PHP-Scripte nutzt (also der individuelle), bekannt ist, weil er sich anmelden musste, kann man auch die MySQL-Queries unter diesem User (oder einem ihm zugeordneten) ausführen lassen.
Die Funktion change_user() könnte Dir dabei helfen
http://dev.mysql.com/doc/refman/5.1/en/apis-php-class.mysqli.html#apis-php-mysqli.change-userWenn es jedoch um vertikale Rechte geht, also solche, die sich auf speziell gekennzeichnete Datensäteze auswirken sollen, so hat dies i.d.R. Auswirkung auf das Datenmodell und lässt sich dann am besten durch Festlegung von Stored Procedures für alle Query-Typen beaufsichtigen.
Die direkten Select-, Insert-, Update-, und Delete-Statemnets werden den Usern entzogen. Es werden ihnen nur die Stored Procedures bereitgestellt, die aber ihrerseits Rücksicht auf den angemeldeten User und die für ihn festgelegten Regeln nehmen. Die Regeln können nun wiederum in einer zusätzlichen Tabelle hinterlegt werden.
Bei vernünftigen DBMS kann man innerhalb einer solchen Stored Procedure auch ein eine Exception schmeißen lassen für den Fall, dass z.B. Rechte nicht ausreichen oder einer Procedure unerlaubte Parameter übergeben wurden.
Diese Vorgehensweis hat den Vorteil, dass alle Rechte auf die Daten auch im DBMS festgelegt werden und als API nebeneinander unterschiedliche (z.B. PHP-Scripte, PERL-Scripte, C++-Frontend fürs LAN) verwendet werden können.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
