be_acl for TYPO3

Sobald mehr als drei Redakteure arbeiten, reichen TYPO3s Standard-Rechte nicht mehr aus

TYPO3 bringt ein Berechtigungssystem mit: Backend-Gruppen, Seitenzugriffe, Tabellen-Rechte. Für kleine Teams mit einer Handvoll Redakteuren funktioniert das. Aber wenn eine Unternehmenswebsite von 15 Redakteuren aus 4 Abteilungen gepflegt wird, stößt das Standard-System an Grenzen. be_acl erweitert TYPO3 um granulare Access Control Lists, die regeln, wer auf welcher Seite welche Inhalte sehen, bearbeiten oder löschen darf - bis auf Feldebene.

Die Extension ist kein Nice-to-have, sondern Voraussetzung für jedes Multi-Redaktions-Setup mit mehr als einer Verantwortungszone. Ohne be_acl enden Berechtigungskonzepte in TYPO3 regelmäßig in einem Geflecht aus dutzenden Gruppen, die niemand mehr überblickt.

Typical use cases

Konzern-Websites mit Abteilungs-Verantwortung. Marketing pflegt die Startseite und Kampagnenseiten, HR die Karriereseite, die Fachabteilungen ihre Produktseiten. Jede Abteilung soll nur ihre eigenen Seiten sehen und bearbeiten. Das Standard-TYPO3-System erlaubt Seitenzugriffe über Mount Points und Gruppenrechte, aber die Konfiguration wird bei 10+ Abteilungen unübersichtlich. be_acl vereinfacht das durch seitenbasierte ACLs: Auf jeder Seite im Seitenbaum lässt sich direkt definieren, welche Gruppe welche Rechte hat.

Mandantenfähige TYPO3-Installationen. Agenturen und Konzerne betreiben mehrere Websites in einer TYPO3-Instanz. Mandant A darf Mandant B nicht sehen, nicht einmal im Seitenbaum. be_acl setzt diese Trennung durch, ohne für jeden Mandanten eine eigene TYPO3-Installation zu betreiben. Bei einer Agentur mit 12 Mandanten in einer TYPO3-Instanz reduzierte be_acl die Administrationszeit für Berechtigungen um circa 60%.

Freigabe-Workflows mit eingeschränkter Bearbeitungstiefe. Externe Dienstleister oder Praktikanten sollen Content-Texte bearbeiten, aber keine Bilder hochladen, keine Seiten verschieben und keine Plugins konfigurieren. be_acl erlaubt Rechte auf Feldebene: Der Benutzer sieht das Textfeld, aber nicht die Layout-Einstellungen oder die Plugin-Konfiguration.

Technical architecture

be_acl erweitert TYPO3s Backend-Berechtigungssystem um ein ACL-Layer, das zwischen dem Core-Rechtesystem und der Benutzerinteraktion sitzt. Die Extension speichert Berechtigungsregeln in der Tabelle tx_beacl_acl, die pro Seite und pro Gruppe definiert, welche Operationen erlaubt sind.

Das System arbeitet mit drei Rechteebenen: Lesen (show), Bearbeiten (edit) und Löschen (delete). Diese Rechte werden pro Seite oder rekursiv für einen Seitenbaum vergeben. Die Konfiguration erfolgt über ein eigenes Tab im Seiteneigenschaften-Dialog: Dort wählt der Administrator eine Benutzergruppe und setzt die gewünschten Rechte per Checkbox.

Intern greift be_acl in TYPO3s BackendUserAuthentication ein und erweitert die doesUserHaveAccess-Prüfung. Bei jedem Seitenzugriff im Backend prüft TYPO3 zuerst die Standard-Rechte und anschließend die ACL-Regeln. Die ACL-Regeln können Standard-Rechte erweitern, aber nicht einschränken. Das ist ein wichtiges Architekturdetail: Wenn eine Gruppe über die Standard-Rechte bereits Zugriff hat, kann be_acl diesen nicht entziehen.

Die Rechte-Auflösung folgt einer Kaskade: Benutzer-Rechte schlagen Gruppen-Rechte, Gruppen-Rechte schlagen Untergruppen-Rechte, und seitenspezifische ACLs schlagen rekursiv vererbte ACLs. Diese Kaskade funktioniert zuverlässig, solange die Gruppenstruktur flach bleibt. Ab 4 verschachtelten Gruppenebenen wird das Verhalten schwer vorhersagbar.

Common problems and solutions

Berechtigungen greifen nicht wie erwartet. Häufigste Ursache: Der Benutzer ist Mitglied in mehreren Gruppen, und die Rechte einer Gruppe überschreiben die ACL-Einschränkung einer anderen. TYPO3s Rechtesystem arbeitet additiv, das heißt, der Benutzer erhält die Summe aller Rechte seiner Gruppen. Lösung: Berechtigungsmatrix erstellen, alle Gruppen eines Benutzers dokumentieren und Überschneidungen eliminieren.

Performance-Probleme bei großen Seitenbäumen. Bei TYPO3-Installationen mit mehr als 5.000 Seiten und 20+ Benutzergruppen kann die ACL-Prüfung den Seitenbaum im Backend spürbar verlangsamen. Die Extension prüft bei jedem Seitenaufruf die ACL-Tabelle. Lösung: Caching der ACL-Prüfungen aktivieren und den Seitenbaum über options.pageTree.excludeDoktypes auf relevante Seitentypen einschränken.

Rechte-Debugging ist schwierig. TYPO3 bietet kein eingebautes Tool, das anzeigt, warum ein Benutzer auf eine bestimmte Seite zugreifen kann oder nicht. Der Admin-Bereich “Backend User” zeigt die simulierte Ansicht, aber nicht die Rechte-Kaskade. Lösung: Das TYPO3 System Log analysieren (bei aktiviertem Debug-Modus loggt TYPO3 Zugriffsversuche) oder die SQL-Tabelle tx_beacl_acl direkt abfragen.

Migration and version compatibility

be_acl ist eine der am längsten gepflegten TYPO3-Extensions. Die aktuelle Version unterstützt TYPO3 v11 und v12. Für TYPO3 v13 existiert eine Beta-Version, die auf dem neuen Backend-Modul-System basiert. Die Extension wird aktiv auf GitHub entwickelt, die Maintainer reagieren auf Issues.

Bei der Migration von TYPO3 v11 auf v12 müssen die ACL-Regeln nicht manuell migriert werden, die Datenbanktabelle bleibt kompatibel. Allerdings hat sich die Backend-Modul-Registrierung in v12 geändert, weshalb das be_acl-Konfigurationsmodul ein Update der Extension-Version erfordert.

Für Unternehmen, die auf TYPO3 v13 migrieren, empfiehlt sich vor dem Upgrade ein Export der bestehenden ACL-Regeln. TYPO3 v13 bringt ein überarbeitetes Berechtigungssystem mit, das einige Funktionen von be_acl in den Core übernimmt. Ob die Extension langfristig noch nötig ist, hängt von der Komplexität des Berechtigungskonzepts ab. Gosign analysiert bei TYPO3-Upgrades das bestehende ACL-Setup und empfiehlt die optimale Lösung, ob be_acl, Core-native Rechte oder eine Kombination.