Die erste - und in v1.0 bereits teilweise integrierte - Überlegung war, ein bitbasiertes Rechtesystem zu implementieren. Doch auch hier ergeben sich sehr schnell ungewollte Einschränkungen. So ist ein bitbasiertes System zwar grundsätzlich erweiterbar, ein Modul kann aber nie 'wissen', welches Bit oder welche Bits noch frei sind. Zudem wird ein bitbasiertes System schnell unübersichtlich und damit nicht mehr wartbar.
Rollenbasierte Rechte (role based access control (RBAC))
Einführung: https://de.wikipedia.org/wiki/RBAC
Bei einem rollenbasierten Rechtesystem werden Rollen definiert, die sich an die jeweiligen Aufgaben eines Benutzers orientieren. Eine Rolle könnte z.B. "Redakteur" heißen und Rechte zum Anlegen von Seiten und Ändern von Inhalten beinhalten. Einem Benutzer können nun beliebig viele Rollen zugewiesen werden, aus denen sich die effektiven Rechte ergeben.
Nachteil eines solchen Systems ist, dass es sehr komplex werden kann und der Administrator genau überlegen muss, welche Rollen er definieren möchte und welche Rechte damit verbunden sind. Auf der anderen Seite hat er aber alle Freiheiten, beliebige Rollen zu definieren.
Datenbankschema
Für die Umsetzung eines rollenbasierten Rechtesystems sind vier Tabellen notwendig:
- Definition der verfügbaren Berechtigungen (permissions) mit ID und Beschreibung
- Definition der verfügbaren Rollen (roles) mit ID und Rollenname
- Zuordnung der Berechtigungen zu den Rollen
- Zuordnung der Rollen zu den einzelnen Benutzern
Beispielhaftes Schema:
Code: Alles auswählen
CREATE TABLE roles (
role_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
role_name VARCHAR(50) NOT NULL,
PRIMARY KEY (role_id)
);
CREATE TABLE permissions (
perm_id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
perm_desc VARCHAR(50) NOT NULL,
PRIMARY KEY (perm_id)
);
CREATE TABLE role_perm (
role_id INTEGER UNSIGNED NOT NULL,
perm_id INTEGER UNSIGNED NOT NULL,
FOREIGN KEY (role_id) REFERENCES roles(role_id),
FOREIGN KEY (perm_id) REFERENCES permissions(perm_id)
);
CREATE TABLE user_role (
user_id INTEGER UNSIGNED NOT NULL,
role_id INTEGER UNSIGNED NOT NULL,
FOREIGN KEY (user_id) REFERENCES users(user_id),
FOREIGN KEY (role_id) REFERENCES roles(role_id)
);
Basierend auf den Vorläufern WebsiteBaker und LEPTON ergeben sich eine Reihe möglicher Berechtigungen. Hier eine unvollständige Liste (Ausarbeitung später):
Frontend
Bestimmte Seiten sehen (Sichtbarkeit "privat")
Backend
Betreten (Dashboard sehen)
Medien
Sehen (auflisten), Verwenden (z.B. in WYSIWYG-Editor), Hochladen, Löschen; Verzeichnisse anlegen, Verzeichnisse löschen
Seiten
Sehen, Neu anlegen, Ändern, Löschen
Einstellungen
Sehen, Ändern
Addons
Sehen (auflisten), Verwenden (zu Seite hinzufügen), Installieren, Deinstallieren
Admin-Tools
Sehen (auflisten), Verwenden
Benutzer
Sehen (auflisten), Neu anlegen, Ändern, Löschen
Gruppen
entfällt
Entwurf: Rechte auf Seiten
Derzeit ist es möglich, Benutzern Rechte auf Seiten zu geben, mit denen sie nichts anfangen können - etwa indem ein Benutzer (über die Gruppe) das Rechte erhält, eine Seite anzulegen, aber nicht, sie dann auch zu bearbeiten. Das mag im Einzelfall so gewollt sein, in der Regel jedoch eher nicht.
Ansatz:
- Wer eine Seite anlegt (=das Recht dazu hat), wird Eigentümer der Seite.
- Der Eigentümer einer Seite hat IMMER folgende Rechte: Inhalte bearbeiten, Seite löschen, Eigentümer ändern
- Diese Rechte besitzt er auch dann, wenn er über keine seine Rollen entsprechende Berechtigungen erhält
- Es ist nicht möglich, einem Eigentümer das Recht zu entziehen, seine eigenen Seiten zu bearbeiten und zu löschen (ein "Superadmin" könnte aber das Recht besitzen, den Eigentümer zu ändern)