Eure Meinung: Query zum Rollen- / Rechte-Management

[cortex]

Ich habe einen sehr interessanten Artikel gefunden: Umfassendes Rollen- und Rechte-Management für eigene Anwendungen.

Was haltet Ihr von der Vorgehensweise? Ist das Ganze brauchbar / der Query gut gestrickt?

Ich persönlich kann mir keine eigene Meinung bilden - ich verstehe den dargebotenen Code schlicht + ergreifend nicht. Vielleicht sieht einer von Euch ein absolutes NoGo oder hat Bedenken hinsichtlich Performance / Skalierbarkeit bei grösseren Datenbeständen.

Meine Tests sind übrigens positiv verlaufen; alles funktioniert wie beschrieben.

cx

p.s. möglicherweise kann mir jemand einen Tip für ein gutes (MY)SQL Tutorial geben; kein Einsteiger-Teil (was ist eigentlich eine Datenbank?), nicht das MYSQL-Handbuch (Mangel an weiterführenden Erklärungen / Beispielen), Sprache en / de.

cx

[DokuLeseHemmung]

Rechte Systeme sind wohl immer "teuer" ....

An sich, sieht das schon ganz gut aus. Fehlen würde mir nur Hierarchie der Rollen.
Z.B.: Moderator erbt alle Rechte eines angemeldeten Users, plus weitere Rechte
Ähnlich, wie es in "Sensei ACL" gemacht wird. Leider scheint das Projekt tot zu sein. Aber nichtsdestotrotz könnte man sich da was abschauen.

Ach ja, ein paar Links..
http://reeg.junetz.de/DSP
A Visual Explanation of SQL Joins
Ka, ob sie dir helfen....

[cortex]

Zitat von DokuLeseHemmung

Rechte Systeme sind wohl immer "teuer"

ich glaub auch. hatte mir gedanken gemacht, wie man 1, 2 tabellen einsparen könnte... no way. wenn's flexibel sein soll, geht's wohl nicht "kleiner".

Zitat von DokuLeseHemmung

Fehlen würde mir nur Hierarchie der Rollen.

mir nicht - bin kein grosser freund von vererbungen. abgesehen davon, dass sowas schnell unübersichtlich werden kann (vor allem im zusammmenspiel mit individuellen rechten) kann vererbung unerwünscht sein. ein normaler user hat bspw. zwei rechte:

1. benutzerkonto registrieren
2. benutzerkonto löschen

konto registrieren zu vererben, ist ok, aber löschen....? ein mod, schon gar nicht ein admin sollte sein konto (versehentlich) löschen dürfen / können.

Zitat von DokuLeseHemmung

Sensei ACL [...] könnte man sich da was abschauen

dank dir für dein feedback + die links,

cx

[Xor]

Hi,

Nunja, hier hat man ja eben die Möglichkeit Rechte zu "vererben", da es vorgesehn ist, dass ein User mehrere Rollen inne haben kann (also Benutzer & Administrator, siehe Tabelle "account_roles"). Halte ich nicht für besonders sinnvoll, da man die Rechte für eine einzelne Rolle doch umfassend angeben kann.

Wenn man nun animmt, dass ein User nur eine Rolle annehmen kann könnten wir uns die Tabelle "account_roles" sparen und die "roleID" direkt in die Usertabelle (wie auch immer die ausschaut) schreiben.

bsp. 0-->Standard
1-->Mod
2-->Admin

Also eine roleID.

Weiters würde ich das System des -1 und 1 und der Methode der Summe im Konzept absehen und die individuelle Rechtevergabe-Tabelle prioritär machen (also was individuell vergeben wurde wird zuerst berücksichtigt). Macht für mich mehr Sinn. Also gibt es für die Tabelle "account_rights_adjust" die Einträge 1 und 0, je nach aktiv bzw. inaktiv.

Unter berücksichtigung dieser 2 Änderungen am System könnte man folgende Query einfacher machen: (als user-tabelle wurde "user" mit einer Zelle "roleID" angenommen)

SELECT rightID, access
FROM (

SELECT rights.rightID AS rightID, account_rights_adjust.adjustment AS access
FROM rights
LEFT JOIN account_rights_adjust ON account_rights_adjust.rightID = rights.rightID
WHERE account_rights_adjust.userID = 1

UNION 

SELECT role_rights.rightID as sameID, 1
FROM role_rights
LEFT JOIN user ON role_rights.roleID = user.roleID
WHERE user.userID =1
) AS tbl
GROUP BY rightID

Das gibt alle Rechte des Users mit einer Rolle aus (Recht-Id und 1 bzw. 0).

Angenommen wird die Tabellenstruktur aus dem oben angegebenen Link.

Ich denke ist praxisbezogener und Performance-freundlicher (eine verschachtelte SELECT weniger, auch kein SUM oder IF).

Was meint Ihr?

Mfg

PS: Tutorials gibt es doch eh schon sehr viel gute, oder? Oder willst du das mehr auf Praxis aufbauen, also mit vielen Beispielen?

Mfg

[cortex]

Zitat von Xor

Halte ich nicht für besonders sinnvoll, da man die Rechte für eine einzelne Rolle doch umfassend angeben kann.

naja... viele dinge sind + bleiben wohl geschmackssache .-

Zitat von Xor

Wenn man nun animmt, dass ein User nur eine Rolle annehmen kann könnten wir uns die Tabelle "account_roles" sparen

stimmt... ging mir auch schon durch den kopf. allerdings finde ich gerade die möglichkeit, einem user mehrere rollen zuzuteilen, sehr reizvoll.

Zitat von Xor

Unter berücksichtigung dieser 2 Änderungen am System könnte man folgende Query einfacher [...]

ist das tatsächlich so viel einfacher...? wie du schon sagst, lediglich eine verschachtelte SELECT weniger.

Zitat von Xor

Tutorials gibt es doch eh schon sehr viel gute, oder? Oder willst du das mehr auf Praxis aufbauen, also mit vielen Beispielen?

ich persönlich kenne kein anständiges SQL-Tutorial. die, die ich bisher gesehen habe, beschäftigen sich überwiegend mit grundlagen - sowohl theoretischer, als auch praktischer natur. mein problem: ich kann komplexe statements einigermaszen lesen, aber 100%-ig nachvollziehen, geschweige denn selber bauen...

cx

[Xor]

Zitat von cortex;

bin kein grosser freund von vererbungen

Zitat von cortex

[...]
allerdings finde ich gerade die möglichkeit, einem user mehrere rollen zuzuteilen, sehr reizvoll.

Nunja, man muss sich entscheiden was einem lieber ist.
Vielleicht ist in diesem Sinne das Wort "vererben" etwas gedehnt, aber gibt man einem User z.B. User & Moderator-Rollen, so hat er Rechte von beiden (also auch wie z.B in deinem vorher genannten Bsp. benutzerkonto löschen)

Zitat von cortex

ist das tatsächlich so viel einfacher...? wie du schon sagst, lediglich eine verschachtelte SELECT weniger.

Ich finde es Übersichtlicher, da es nicht nur das Select sondern auch eine Tabelle, 2x IF und 2x SUM (In der Query) erspart. Natürlich, von der Performance, vor allem bei kleineren Datenmengen, wird nicht viel Unterschied sein.

Zitat von cortex

ich kann komplexe statements einigermaszen lesen, aber 100%-ig nachvollziehen, geschweige denn selber bauen...

Ist bei mir genauso. Aber wenn ich mir Statement für Statement durchlese/neu nachschlage steig ich langsam. Und beim bauen brauch ich auch immer mehrere Versuche... Aber ich glaub da machts auch die Übung aus. Wobei, so'n Tut mit Onlineübungen....

Mfg

[cortex]

Zitat von Xor

Nunja, man muss sich entscheiden was einem lieber ist.

wieso...? ich kann einem user mehrere rollen zuteilen, wobei einzelne rechte ggfs. mehrfach zugewiesen werden. dennoch muss eine hierarchisch niedere rolle nicht von einer anderen rolle erben.

Zitat von Xor

gibt man einem User z.B. User & Moderator-Rollen, so hat er Rechte von beiden (also auch wie z.B in deinem vorher genannten Bsp. benutzerkonto löschen)

richtig, das hat allerdings - wie du schon andeutest - nichts mit vererbung zu tun, sondern eher mit "komposition" .-

Zitat von Xor

wenn ich mir Statement für Statement durchlese/neu nachschlage steig ich langsam [...]

das debuggen ist halt dermaszen ätzend, dass ausprobieren und autodidaktisches lernen keinen richtigen spass machen. und dann noch dieses grottige handbuch...

cx

[feuervogel]

Zitat von cortex

ich persönlich kenne kein anständiges SQL-Tutorial. die, die ich bisher gesehen habe, beschäftigen sich überwiegend mit grundlagen - sowohl theoretischer, als auch praktischer natur. mein problem: ich kann komplexe statements einigermaszen lesen, aber 100%-ig nachvollziehen, geschweige denn selber bauen...

cx

hm, manche dinge werden vielleicht erst in dicken büchern gut erklärt. ich habe z.b. hier "datenbanksysteme" von a. kemper/a. eickler. mein prof in datenbanken war herr rahm, der hat auch einige bücher zu dem thema veröffentlicht.

aber die sache ist, dass man sowas nur mit sehr viel üben hinbekommt, denke ich. und eigentlich braucht man solchen komplexen statements eher selten, weil 1. werden die dann auch irgendwann recht langsam und 2. verlagert man immer mehr komplexität der anwendung in die datenbank. heutzutage nutzt man ja für sowas sowieso ein orm, und da sind die möglichkeiten sowieso eher eingeschränkt. und reichen dennoch für 99.9 % der fälle aus.

[cortex]

Zitat von feuervogel

und 2. verlagert man immer mehr komplexität der anwendung in die datenbank.

genau das sehe ich kritisch; ich fühle mich nicht besonders wohl dabei, zuviel logik in die db zu verlagern. ich schätze datenbanken als strukturierte datenspeicher - mehr aber auch nicht. um das db-backend weitestgehend austauschbar zu halten verzichte ich bspw. auch (ungern) auf ein paar nette features:

REPLACE ist eine MySQL-Erweiterung zum SQL-Standard

schade drum...

cx

[feuervogel]

Zitat von cortex

genau das sehe ich kritisch; ich fühle mich nicht besonders wohl dabei, zuviel logik in die db zu verlagern. ich schätze datenbanken als strukturierte datenspeicher - mehr aber auch nicht. um das db-backend weitestgehend austauschbar zu halten verzichte ich bspw. auch (ungern) auf ein paar nette features:

genau das meinte ich ja. ich finde das ja auch nicht gut.