Die Administration von Benutzer-Rechten im Backend ist „eine Kunst für sich“. Ich habe schon viele Instanzen gesehen, da gibt es nur eine Gruppe „Redakteure“ und alles ist in dieser eingestellt. Wenn dann ein Benutzer „ähnliche“ Rechte bekommen soll, wird die Gruppe kopiert und ein wenig angepasst. Das ist super praktisch: NICHT! Das das Bullshit ist, brauch ich hoffentlich keinem erklären!! Ähnliche Rechtestrukturen werden immer wieder kopiert und ein wenig angepasst und es gibt somit keine einheitliche Struktur/Basis. Somit hat sich in den letzten Jahren eine Struktur entwickelt, welche zwar komplexer, aber sehr flexibel ist, wenn es darum geht Benutzer-Rechte individuell zusammen zu stellen. Würde mich über Feedback freuen…

Im Moment wird dabei mit drei verschiedenen „Gruppen“-Arten gearbeitet, welche unterschiedliche Funktionen erfüllen um möglichst flexibel zu sein. Damit die Gruppen nicht durcheinander kommen, werden diese mit unterschiedlichen Präfixen ausgestattet. Bevor ich auf die verschiedenen Gruppen eingehe, kurz noch ein paar Regeln. JEDER Benutzer sollte in einer Gruppe liegen. Selbst CLI Benutzer und Admins sollten in einer Gruppe zugewiesen werden, falls auf dieser Abstraktionsschicht z.B. UserTsConfig ergänzt werden muss. Die Benutzer selbst haben KEINE individuellen Berechtigungen, sondern es werden alle Berechtigungen über die unten genannten Gruppen abgebildet. Ein Benutzer (Ausnahme Admins/CLI) sollte immer mindestens eine „+ Editor“- und eine „+ Workspace“ Gruppe haben.

Die Benutzernamen sollten ebenfalls immer in der gleichen Struktur vorliegen. Hier ist etwas wie „vorname.nachname“ empfehlenswert. Die einzige Ausnahme ist hier ein CLI Benutzer, da dieser einen anderen Prefix tragen muss.

Seitenbaum-Gruppen

Die Gruppen für Seitenbaum Rechte beginnen alle mit einer Tilde „~“. Die Gruppen selbst haben keine Einstellungen bzgl. Zugriffe auf Tabellen, Felder oder Dateien. Diese Gruppen sind ausschließlich Eigentümer der jeweiligen Seiten im Seitenbaum (Access Modul). Es gibt eine „logische“ Gruppen welche „~ All“ heißt. Diese besitzt alle anderen „Seitenbaum-Gruppen“ als Untergruppen. Gibt es keine speziellen Rechte für eine Seite, wird diese mit der „~ Default“ Gruppe verknüpft. Diese Art von Gruppen gibt es um das **Wo** (Seitenbaum-Gruppen) von dem „Was“(Rechte-Gruppen) zu trennen. Für Sysfolder verschiedener Extensions macht es z.B. Sinn eine eigene Tildegruppe anzulegen.

Rechte-Gruppen

Die Gruppen für die Rechte auf die einzelnen Felder und Tabellen beginnen mit einem Minus „-„. Die Gruppen sind normalerweise anhand der Funktionalitäten der Webseite angelegt. D.h. das üblicherweise jede Extension eine Gruppe bekommt und des weiteren Kernfunktionen wie Datei-Management, Standard-Felder, Hilfe-Funktionen etc. einzelne Gruppen haben, sodass diese möglichst fein zusammengestellt werden können. Dabei ist zu beachten, dass Sprach-Funktionen bzw. die Pflege von Sprachen in Gruppen gekapselt ist welche mit einem „- Language“ beginnen, Extension Rechte mit einem „- Extension“ beginnen, Workspace Funktionen mit einem „- Workspace“ beginnen und die TYPO3 Kern Rechte mit einem „- Core“ beginnen.

Zusätzlich gibt die zentralen Gruppen „- Core Pages Read“ und „- Core Pages Write“ und „- Core Content Read“ und „- Core Content Write“. In diesen 4 Gruppen
werden die Rechte auf Seiten und Seiteninhalte beschrieben, welche am häufigsten angepasst werden müssen. WICHTIG: Die „Write“ Gruppen sind vollständig leer und haben ausschließlich die Option gesetzt auf die jeweilige Tabelle (Content, Pages) schreibend zuzugreifen. In den „Read“ Gruppen ist der Zugriff auf die Tabelle ausschließlich lesend gestattet, hier werden jedoch ALLE Felder gesetzt, welche sowohl lesend als auch schreibend für den Redakteur relevant sind. Diese Trennung regelt das **Was** (Welche Felder) und das **Wie** (Lesen/Schreiben).

Hinweis: Jede dieser Gruppen sollte „autonom“ Nutzbar sein. Damit sind die nötigen Module im BE gemeint. Wird in einer Rechte-Gruppe das Bearbeiten von Seiten erlaubt, so sollte hier auch das Seitenmodul enthalten sein. Geht es um das Bearbeiten von News, ist entsprechend das News Modul oder die Liste ebenfalls auszuwählen.

Benutzer-Gruppen

Die letzte Gruppen Art sind die Benutzer-Gruppen, welche immer mit einem Plus „+“ beginnen. Diese Gruppen kombinieren und die Seitenbaum-Gruppen („Wo“) mit den Rechte-Gruppen („Was“ und „Wie“) um individuelle Redakteurs-Gruppen zu kreieren. In diesen Gruppen werden im „Normalfall“ keine weiteren Rechte mehr gesetzt. Neben den Redakteurs Gruppen (welche mit „+ Editor“ beginnen) sind auch Workspace Gruppen („+ Workspace“) zu finden. Die Workspace Gruppen haben keine weitere Konfiguration in der Gruppe, sondern werden im Workspacedatensatz verknüpft und wirken sich so auf die Steuerung aus.

Ebenfalls gibt es eine Gruppe für alle CLI User und eine Gruppe für alle Administratoren. Die beiden Gruppen haben keinerlei Backend-Rechte, können jedoch mit PageTsConfig Konfigurationen ausgestattet werden.

Übersicht der Gruppen (klick vergrößert)

Beispiele

• Alle Redakteure brauchen Zugriff auf ein weiteres Standard-Inhaltselement: Das Inhaltselement liegt in tt_content, weshalb die „- Core Content“-Gruppen richtig sein müssen. Egal ob der Zugriff lesend oder schreiben ist, muss die Information immer in der „Read“ Gruppe untergebracht werden. Somit ist die „- Core Content (Read)“ die richtige Gruppe um die Rechte zu setzen.
• Eine neue Extension hat Tabellen, welche der Redakteur bearbeiten soll: Es wird eine neue „Low-Level“ Rechte-Gruppe angelegt, welche den Namen „- Extension XXX“ erhält. In dieser Gruppe werden ausschließlich die Zugriffe auf die Extension verwaltet. Hat die Extension ebenfalls einen eigenen Storage-Folder so wird ebenfalls ein „~ Extension XXX“ angelegt und die Gruppen-Rechte der Storage-Folder auf diese Gruppe umgestellt. Im Anschluss wird jede Benutzer-Gruppe, welche Zugriff auf die Extension bekommen soll, mit der „- Extension XXX“ (Was) und „~ Extension XXX“ (Wo) verknüpft.

Fazit

Was haltet Ihr von der Struktur? Wie geht ihr vor, wenn ihr die Rechte im Backend einstellt und dabei flexible sein wollt? Alles in eine Gruppe oder habt ihr ebenfalls ein Regelwerk um Rechte sauber zu strukturieren?