Willkommen im Dschungel: TYPO3 Backend-Berechtigungen

TYPO3 bietet viele Möglichkeiten Berechtigungen zu setzen. Dies wird besonders für ein komplexes System mit sehr unterschiedlichen Benutzer-Profilen schnell unüberschaubar. Um nicht im Konfigurations- und Gruppen-Dschungel unterzugehen, kann eine geordnete und klar strukturierte Vorgehensweise bei der Verwaltung der Backend-Berechtigungen helfen. Ich werde meine Erfahrungen, die ich im Laufe der letzten Jahre gesammelt habe, mit euch teilen und hoffe, dass dieser Beitrag dem ein oder anderen nützlich sein wird.

Lesedauer: ca. 9 Minuten

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.)

Screenshot des TYPO3 Backendes mit Benutzergruppen

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.

TYPO3 Backend-Ansicht der Redakteursrechte

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

[ACL] RedakteurAccess Control ListIn diesen Gruppen werden die ACL Einstellungen vorgenommen. Also welche Module, Tabellen, Felder und Plugins erlaubt sind.
[ACL][DISALLOW] RedakteurAccess Control List Disallowed PluginsDa nicht nur Berechtigungen existieren, die Zugriffe erlauben, sondern auch Berechtigungen zum Verbieten, ist es sinnvoll eine extra ACL-Gruppe für die verbotenen Plugins zu erstellen. Sobald der BE-Benutzer in seinen Berechtigungen ein Plugin als verboten gesetzt hat, kann diese Einstellung nicht durch eine andere Gruppe überschrieben werden.  
[TS] RedakteurTSConfigDiese Gruppe enthält alle TSConfig-Konfigurationen.
[DBM] RedakteurDataBaseMountDurch diese Gruppe werden die Datenbank-Mounts definiert und somit die Sichtbarkeit von z.B. Sysfoldern mit Datensätzen festgelegt.
[FM] RedakteurFileMountDie Filemount-Gruppe dient zur Freigabe von Fileadmin-Ordnern, die die Gruppe erhalten soll.
[L] RedakteurLanguageEine Begrenzung auf Sprache befindet sich zwar unter dem Punkt ACL aber ist zwecks der Übersichtlichkeit besser in einer eigenen Gruppe aufgehoben. Somit sieht man in einer META-Gruppe direkt welche Sprach-Berechtigung der Gruppe zugeordnet ist und muss nicht zuerst in der ACL-Gruppe darin suchen.
[EXT] tt_newsExtensionDie Verwendung von solchen Gruppen dient zur Freigabe von Extension-spezifischen Einstellungen. Ein Beispiel wäre hierfür die "tt_news"-Extension. In dieser Gruppe kann es durchaus sinnvoll sein, alle Einstellungen wie ACL, TS usw. zu setzen, da hier explizit die Berechtigung für eine Extension vergeben wird.
[P] RedakteurKeine (Pages im Access-Modul)Diese Gruppe enthält keine Berechtigungen innerhalb der BE-Gruppe. Sie wird für das Zugriffs-Modul verwendet um die Freigaben des Seitenbaums im Backend für Benutzer mit dieser Gruppe zu steuern.
[META] RedakteurKeineDie Meta-Gruppe ist die Gruppe, die alle vorher genannten Gruppen in einer vereint und selbst keinerlei Berechtigungen gesetzt hat, d.h. sie besteht nur aus Untergruppen (ACL, TS, DBM, P, L, etc.). Der Vorteil hierbei ist, dass z.B. eine "[META] Redakteur" Gruppe den jeweiligen Redakteuren im Backend gegeben werden kann und nicht jedem BE-Benutzer alle benötigten Gruppen zugeordnet werden müssen (ACL, TS, DBM, FM, etc.).

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:

Anforderung

Wir benötigen für das neue TYPO3 System ein Berechtigungskonzept für:

  • Administratoren der Redaktion, die Seiten und Inhalte anlegen können

  • Redaktion, die nur Inhalte anlegen können

  • Administratoren von Nachrichten, die Seiten und Nachrichten anlegen können

  • Redaktion von Nachrichten, die nur Nachrichten anlegen können

  • Ein Benutzer, der sich um die Erstellung und den Versand des Newsletters kümmert

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

  • [META] Redaktion-Admin

    • [ACL] Redaktion-Admin

    • [DBM] Redaktion

    • [FM] Redaktion

    • [P] Redaktion-Admin

    • [TS] Admin

  • [META] Redaktion

    • [ACL] Redaktion

    • [DBM] Redaktion

    • [FM] Redaktion

    • [P] Redaktion

  • [META] News-Admin

    • [ACL] News-Admin

    • [DBM] News

    • [FM] News

    • [P] News-Admin

    • [TS] Admin

  • [META] News-Redaktion

    • [ACL] News-Redaktion

    • [DBM] News

    • [FM] News

    • [P] News-Redaktion

  • [META] Newsletter-Admin

    • [ACL] Newsletter-Admin

    • [DBM] Newsletter-Admin

    • [FM] Newsletter-Admin

    • [P] Newsletter-Admin

    • [TS] Admin

    • [EXT] DirectMail

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:

1. Anforderung

Um sicher zustellen, dass der Newsletter-Admin keine News unbeabsichtigt löscht, darf er nur die Berechtigung besitzen aus den vorhandenen News einen Newsletter zu erzeugen und diesen versenden zu können.

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.

2. Anforderung

Es wird ein Bereich für interne News benötigt (hinter FE Login versteckt) und hierfür eine Gruppe, die entsprechend Zugriff für die Verwaltung dieser News hat. Aufgrund der Unternehmensstruktur dürfen die normalen News-Autoren nicht auf diese News zugreifen dürfen - weder lesend noch bearbeitend. Zusätzlich soll diese Gruppe auch die regulären News pflegen können.

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.

3. Anforderung

Wir benötigen eine Einschränkung für die redaktionellen Benutzer. Diese dürfen nur die Inhaltselemente "Text", "Text und Bild" und "Bilder" verwenden. Die Admins sollen weiterhin Zugriff auf alle Inhaltselemente erhalten.

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.

TIPP

Die Trennung von "erlaubt" und "verboten" in separate Gruppen ist wirklich empfehlenswert. Sobald zum Beispiel ein bestimmtes Plugin innerhalb einer ACL-Gruppe als "verboten" gesetzt wurde, kann dies über keine weitere Gruppe wieder freigeschaltet werden. Das "einmal verboten immer verboten" Prinzip nötigt uns dann zu einer neuen Gruppe für den Benutzer, die eine neue - fast identische - ACL-Gruppe enthält, in der das Plugin als nicht "verboten" eingestellt ist. Dies würde doppelte Pflege der ACL-Gruppen bedeuten und ist fehleranfälliger, aufwändiger und unübersichtlicher.

4. Anforderung

Die Redaktion-Gruppe benötigt Zugriff auf das ExtList Plugin.

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.

5. Anforderung

Aufgrund der neuen Niederlassung in England, benötigen wir eine mehrsprachige Webseite. Die Berechtigung muss dahingehend geändert werden, dass Benutzer aus Deutschland nur Zugriff auf deutsche Seiten und Inhalte besitzen. Benutzer aus England müssen die Möglichkeit haben, deutsche Seiten zu übersetzen und eigenen Inhalt in englisch anlegen zu können. Der Newsletter steht nur in Deutschland zur Verfügung.

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/

Habt ihr Fragen, Anregungen oder Fehler gefunden? 

Ziemlich wahrscheinlich ist nun noch die ein oder andere Frage offen geblieben, da das Theme recht komplex ist. Zögert bitte nicht in einem Kommentar nachzufragen oder uns direkt per Telefon zu kontaktieren: 0721 - 91090.

Wir freuen uns, wenn wir helfen können.

Teilen:

Weitere Beiträge

Ich liebe es wenn ein Plan funktioniert!
Daniel Lienert, Geschäftsführer / CTO bei punkt.de
Arbeiten bei punkt.de