Wofür überhaupt Berechtigungen?

TYPO3 ist ein mächtiges und sehr stark konfigurierbares CMS. Die Möglichkeiten, die man als Backend Administrator hat, sind schier endlos. Jedoch sollte nicht jeder BE-Benutzer Administrator sein. Zu viele Möglichkeiten bringen zu viele Gefahren, wie zum Beispiel das Löschen von Seiten die eigentlich gar nicht bearbeitet werden sollten oder wenn sensible Daten im Backend jedem Redakteur zugänglich sind. Dies sind Gründe, die für eine Begrenzung von Berechtigungen sprechen. Aber natürlich kann eine Begrenzung auch sinnvoll sein, um den täglichen Umgang mit TYPO3 zu vereinfachen. Je weniger Module, Einstellungen und Funktionalitäten man sieht, desto übersichtlicher gestaltet sich das Backend. Ich will euch in diesem Beitrag eine kurze Übersicht über die Backend-Berechtigungen geben und einen Weg zeigen, mit dem ihr auch bei komplexeren Berechtigungsstrukturen nicht den Überblick verliert. Ich werde mich dabei an der TYPO3 Version 6.2 orientieren, da eine Auflistung aller TYPO3 Versionen mit allen Unterschieden den Rahmen des Beitrags sprengen würde.

Recht und Ordnung in TYPO3

Wie bereits gesagt, gibt es eine Unmenge an Berechtigungsoptionen für die BE-Benutzer. Aufgrund der Vielzahl an unterschiedlichen Funktionalitäten folgt hier nur eine grobe Auflistung der Einstellungsmöglichkeiten der BE-Berechtigungen für TYPO3:

• Verfügbare Module (Seite, Liste, Vorschau, Dateiliste, etc.)

• Zugriff auf Tabellen (Datensätze sehen/bearbeiten)

• Verfügbare Seitentypen (Seiten, Verweise, Ordner, etc)

• Sichtbare Felder aus Seiteninhalten (tt_content, Tabellen von Extensions, etc.)

• Einschränkung der verfügbaren Plugins (TYPO3, Extensions, etc.)

• Einschränkung auf die verfügbare Sprache

• Workspaces

• Datenbankfreigaben (Seitenbaum)

• Verzeichnisfreigaben (Fileadmin)

• Rechte für Dateioperationen (lesen, schreiben, verschieben, löschen, etc.)

• verfügbare Kategorien

• Einschränkung auf Domäne

• TSConfig (z.B. Reiter ausblenden, Default-Werte setzen, etc.)

Und weil natürlich auch die Sichtbarkeit des Seitenbaums eingeschränkt werden kann, existiert noch das Zugriffs-Modul mit dem man folgende Berechtigungen setzen kann:

• Seite anzeigen

• Inhalte bearbeiten

• Seite bearbeiten

• Seite löschen

• Neue Seiten anlegen

• (+ alles auf allen Unterseiten)

Diese Berechtigungen werden an BE-Gruppen gesetzt. Dazu später mehr.

Klasse statt Masse

Das sind bei vielen verschiedenen BE-Benutzer-Profilen eine ganze Menge Einstellungsmöglichkeiten. Um hier nicht den Überblick zu verlieren oder für jeden Benutzer eine eigene Gruppe anlegen zu müssen, empfiehlt es sich die Gruppen logisch zu trennen und wiederum zu gruppieren. Wir unterscheiden hierbei nach folgenden Typen:

Namens-            Verwendete Konfiguration          Verwendungszweck
Schema

Das Benennungsschema ist hierbei immer "[KÜRZEL_DER_BERECHTIGUNGSART] sprechender Gruppenname".

Vorteile

• Die jeweiligen Gruppen beinhalten nur die entsprechenden Berechtigungen

• Die Gruppen sind "sprechend" benannt

• Filtern nach den Berechtigungen ist anhand des Namens einfach möglich (z.B. über die Datenbank oder die TYPO3 Backend-Suche nach allen Sprach-Gruppen → "[L]")

• Ein Benutzer erhält immer nur eine META-Gruppe

• Zuordnen einer Gruppe zu einem Benutzer im Backend ist übersichtlich, da die Liste der verfügbaren Gruppen alphabetisch (und damit kategorisierte) erfolgt

Nachteil

• Bei komplexen Projekten können so sehr viele Gruppen entstehen

Ein (etwas größeres) Praxisbeispiel

Gehen wir davon aus, wir haben eine neue TYPO3-Seite und der Kunde hat folgende Anforderung in Bezug auf BE-Benutzer gestellt:

Aus dieser Anforderung heraus würde ich die Gruppen wie folgt definieren:

Es werden im Grunde drei Hauptgruppen benötigt und zwar eine Gruppe für die Seitengestaltung ("Redaktion"), eine für die Nachrichtengestaltung ("News") und eine für den Newsletter ("Newsletter"). Die Seiten und Nachrichtengestaltung unterteilt sich noch in Admins und Redaktion. Da die Admins hier etwas mehr Berechtigungen erhalten als die Redaktion, benötigen wir einige unterschiedliche Gruppen. Wenn wir nun die Redaktionsgruppen "[META] Redaktion-Admin" und "[META] Redaktion" miteinander vergleichen, fällt auf, dass die Admin-Gruppe die gleiche DBM und FM-Gruppe wie die Redaktion-Gruppe hat. Da beide auf die gleichen Datensätze (DBM) und Dateien (FM) zugreifen müssen, ist es hier nicht sinnvoll, unterschiedliche DBM/FM-Gruppen anzulegen. Die ACL und P-Gruppen unterscheiden sich, da wir der normalen Redaktion-Gruppe keine Berechtigung zum anlegen von Seiten (P-Gruppe) und Plugins (ACL-Gruppe) gewähren. Dies ist der "Redaktion-Admin"-Gruppe vorbehalten. Das Gleiche trifft beim Vergleich der News-Gruppen "News-Admin" und "News-Redaktion" zu. Die Gruppe "[TS] Admin" ist eine generische Gruppe die über TSConfig das rekursive Löschen von Seiten erlaubt. Eine nützliche Einstellung, die in diesem Beispiel nur den Admin-Gruppen erlaubt wird.

Die "[META] Newsletter-Admin"-Gruppe könnte natürlich die "[DBM] News" und "[FM] News"-Gruppe erhalten. Jedoch habe ich mich bei dem Beispiel dafür entschieden hier explizit neue Gruppen zu verwenden, da es sich um eine andere Art von Benutzer handelt. Für den Fall, dass weitere Redaktions-Gruppen hinzukommen, könnte dies zu weiteren Anpassungen des Newsletter-Admins führen. Hier ist eine klare Trennung nach Funktionalität meiner Meinung sinnvoll. Zusätzlich kommt eine EXT-Gruppe für DirectMail zum Einsatz für die Freigabe der Backend-Module der Extension. Da ein begrenzter Zugriff auf DirektMail Module eher weniger sinnvoll ist, sind unterschiedliche Zugriffsberechtigungen für die Extension vermutlich nicht notwendig. Zudem bietet die EXT-Gruppe den Vorteil, dass die Berechtigungen zu DirectMail eher in dieser Gruppe gesucht werden als unter der ACL-Gruppe, die unter Umständen weit mehr unterschiedliche Konfigurationen aktiviert/deaktiviert hat. Es ist somit übersichtlicher und einfacher zu handhaben.

Wenn wir nun wissen wollen, welche Berechtigungen der Benutzer XYZ hat, können wir dies grob über die zugeordnete META-Gruppe herausfinden. Je sprechender die Gruppen benannt sind, desto praktischer. Andererseits kann eine zu genaue Bezeichnung wie z.B. "[ACL] News Kategorien (PHP, JS, HTML, CSS)" direkt nach einer Änderung falsche Informationen liefern, wenn z.B. eine neue News Kategorie hinzugefügt aber der Name der Gruppe nicht angepasst wurde.

Nehmen wir an, es sind nun schon einige Monate vergangen und es kommen die ersten Anpassungen an die BE-Berechtigungen:

Da wir dem Newsletter-Admin eigene Gruppen für die Zugriffsberechtigung von News gegeben haben, bleiben alle anderen Gruppen von diesen Anpassungen unberührt. Angepasst werden die Gruppen "[P] Newsletter-Admin" und "[ACL] Newsletter-Admin" um nur noch lesenden Zugriff auf die News zu gewähren.

Wir benötigen also eine neue Gruppe für die Verwaltung der internen News mit Zugriff auf die bestehenden regulären News. Die Gruppe könnte wie folgt aufgebaut sein:

• [META] News-Intern-Admin

  • [ACL] News-Admin

  • [DBM] News-Intern

  • [DBM] News

  • [FM] News

  • [P] News-Admin

  • [P] News-Intern-Admin

  • [TS] Admin

Wir verwenden die gleichen Gruppen wie die "News-Admin" Gruppe und erweitern diese um eigene DBM- und P-Gruppen, da ein Zugriff auf den Filemount und Seitenbaum für die internen News benötigt wird. Natürlich könnte man auch die "[META] News-Admin" Gruppe als Untergruppe hinterlegen. Aber das hat den Nachteil, dass man bei Anpassungen dann die Untergruppe einer Untergruppe überprüfen muss. Des Weiteren könnte die "[META] News-Admin" Gruppe durch eine andere Anforderung geänderte Rechte bekommen, die dann diese Gruppe ebenfalls betreffen. Man sollte davon ausgehen können, dass Änderungen an einer META-Gruppe keine Auswirkungen auf andere META-Gruppen hat. Man könnte es als eine Art Konvention betrachten.

Die bisherigen Berechtigungen hatten nur "erlaubende" Einstellungen. Aus diesem Grund kommt nun eine zusätzliche "ACL-DISALLOW"-Gruppe zum Einsatz, die die Berechtigungen auf Inhaltselemente verbietet: die "[ACL][DISALLOW] Alle Plugins und spezielle Seiteninhalte"-Gruppe. Diese Gruppe wird nun den META-Gruppen "[META] Redaktion" und "[META] News-Redaktion" gegeben. Dadurch erhalten die entsprechenden Benutzer nur noch Zugriff auf die nicht verbotenen Inhaltselemente/Plugins.

Wenn wir nun dieses Plugin in der ACL-DISALLOW-Gruppe freigeben, würde auch die "News-Redaktion"-Gruppe Zugriff erhalten. Da dies nicht gewünscht ist, benötigen wir nun doch mehr "ACL-DISALLOW"-Gruppen:

• [META] Redaktion
  

  • [ACL][DISALLOW] Alles außer Text, Bilder und ExtList Plugin

  • ...

• [META] News-Redaktion

  • [ACL][DISALLOW] Alles außer Text und Bilder

  • ...

Natürlich unterscheiden sich die Gruppen nur durch ein Haken bei dem ExtList Plugin aber dadurch, dass das Prinzip "einmal verboten immer verboten" hier wirkt, würde ich zuvor genannten Weg gehen. Gerade wenn es um Blöcke wie Inhaltselemente oder Plugins geht, kann es durchaus sinnvoll sein, diese in verschiedenen Gruppen auszulagern, um zum einen die Gruppe sprechend benennen zu können und zum Anderen eine Übersicht zu erhalten, was durch die Gruppe verboten wird ohne die Gruppe direkt bearbeiten zu müssen. Je nach Projektgröße und installierten Extensions kann die Liste an Inhaltselementen und Plugins sehr schnell sehr unübersichtlich werden.

Die Anforderung hat größere Auswirkungen auf unsere BE-Berechtigung. Und es gibt mehrere Möglichkeiten diese Anforderung umzusetzen:

1. Möglichkeit:
Wir erstellen die Sprach-Gruppen "[L] Deutsch" und "[L] Englisch". Anschließend nennen wir die META-Gruppen um und ergänzen den Namen um ein "(DE)" also z.B. "[META] News-Admin (DE)". Danach kopieren wir die META-Gruppen und ändern das DE in EN um. Nun müssen die jeweiligen META-Gruppen abhängig davon ob DE oder EN um die jeweilige L-Gruppe erweitert werden.

2. Möglichkeit:
Die META-Gruppen bleiben unverändert und die jeweiligen BE-Benutzer erhalten die L-Gruppe für Ihre Sprache. 

Die zweite Möglichkeit hat den Vorteil, dass sich die Anzahl der Gruppen nicht zu sehr erhöht und in einem noch überschaubaren Rahmen bleibt. Jedoch widerspricht dies der Lesbarkeit der META-Gruppen. Die Information welche Sprache der BE-Benutzer bearbeiten darf, steckt damit im Benutzer selbst und nicht in der Gruppe. Meine Entscheidung würde ich hier sehr stark davon abhängig machen, ob geplant ist noch mehr Sprachen anbieten zu wollen. Die perfekte Lösung wird es nie geben, da es immer auf den IST und SOLL Zustand des Projekts ankommt.

Fazit

Durch eine gute und sinnvolle Strukturierung der BE-Berechtigungen in TYPO3 lassen sich diese gut überblicken und erweitern. Die Administration von BE-Berechtigungen ist bei größeren Projekten keine einfache Aufgabe, aber mit der nötigen Disziplin und Strukturierung muss daraus kein unbändiger Moloch werden.

Ein Blick in die Zukunft

Wer eine CI/CD Infrastruktur betreibt und immer wieder Anpassungen an BE-Berechtigungen durchführt, wird schnell genervt sein. Unterschiedliche Datenbank-Bestände verhindern das Exportieren der Gruppen in das Zielsystem und so müssen die Änderungen dokumentiert und händisch auf das jeweilige Zielsystem übertragen werden. Auch Entwickler und Integratoren sind nur Menschen und können Fehler machen. Vor allem wenn man sich durch hunderte von Checkbox-Listen wühlt, um den einen Haken zu setzen, der die Anforderung des Kunden erfüllt. Damit wird bald Schluss sein! Die Entwickler von TYPO3 arbeiten daran, dass Benutzerberechtigungen in Dateien ausgelagert werden können. Der Vorteil, der sich daraus bietet, liegt auf der Hand: versionierbare BE-Berechtigungen. Das ist perfekt für eine CI/CD Infrastruktur und sofern die Konfigurationsdateien für die Benutzerberechtigungen auch einfach lesbar sind (vielleicht eine übersichtliche YAML Datei?), entfällt auch die Dokumentation für die Berechtigungen (die spätestens nach dem Schreiben wieder veraltet ist).

P.S.: Und danke Daniela Grammlich für das Sketchen des Titelbildes. Wer mehr Sketchnotes sehen möchte, hier entlang: https://grammheimlich.de/