be_acl dla TYPO3

Gdy pracuje więcej niż trzech redaktorów, standardowe uprawnienia TYPO3 nie wystarczają

TYPO3 posiada wbudowany system uprawnień: grupy backendowe, dostęp do stron, uprawnienia do tabel. Dla małych zespołów z garstką redaktorów to wystarcza. Ale gdy witrynę korporacyjną utrzymuje 15 redaktorów z 4 działów, standardowy system osiąga swoje granice. be_acl rozszerza TYPO3 o granularne Access Control Lists, które regulują kto na jakiej stronie może widzieć, edytować lub usuwać jakie treści - aż do poziomu pól.

Rozszerzenie nie jest miłym dodatkiem, lecz warunkiem koniecznym dla każdej konfiguracji z wieloma redakcjami i więcej niż jedną strefą odpowiedzialności. Bez be_acl koncepcje uprawnień w TYPO3 regularnie kończą się siecią dziesiątek grup, nad którymi nikt nie panuje.

Typowe scenariusze zastosowania

Witryny korporacyjne z odpowiedzialnością działową. Marketing zarządza stroną główną i stronami kampanii, HR stroną kariery, działy fachowe swoimi stronami produktowymi. Każdy dział powinien widzieć i edytować tylko swoje strony. Standardowy system TYPO3 pozwala na dostęp do stron przez Mount Points i uprawnienia grup, ale konfiguracja przy 10+ działach staje się nieprzejrzysta. be_acl upraszcza to przez ACL oparte na stronach: na każdej stronie w drzewie stron można bezpośrednio zdefiniować, która grupa ma jakie uprawnienia.

Wielomandatowe instalacje TYPO3. Agencje i korporacje prowadzą wiele stron w jednej instancji TYPO3. Mandant A nie powinien widzieć Mandanta B, nawet w drzewie stron. be_acl wymusza tę separację bez konieczności prowadzenia osobnej instalacji TYPO3 dla każdego mandanta. W agencji z 12 mandantami w jednej instancji TYPO3 be_acl zredukował czas administracji uprawnieniami o około 60%.

Przepływy zatwierdzania z ograniczoną głębokością edycji. Zewnętrzni usługodawcy lub stażyści powinni edytować teksty, ale nie przesyłać obrazów, nie przesuwać stron i nie konfigurować wtyczek. be_acl pozwala na uprawnienia na poziomie pól: użytkownik widzi pole tekstowe, ale nie ustawienia układu ani konfigurację wtyczki.

Architektura techniczna

be_acl rozszerza system uprawnień backendu TYPO3 o warstwę ACL, która siedzi między podstawowym systemem uprawnień a interakcją użytkownika. Rozszerzenie przechowuje reguły uprawnień w tabeli tx_beacl_acl, która definiuje per strona i per grupa, jakie operacje są dozwolone.

System operuje na trzech poziomach uprawnień: odczyt (show), edycja (edit) i usuwanie (delete). Te uprawnienia są przyznawane per strona lub rekurencyjnie dla drzewa stron. Konfiguracja odbywa się przez osobną zakładkę w dialogu właściwości strony: tam administrator wybiera grupę użytkowników i ustawia żądane uprawnienia checkboxami.

Wewnętrznie be_acl ingeruje w BackendUserAuthentication TYPO3 i rozszerza sprawdzanie doesUserHaveAccess. Przy każdym dostępie do strony w backendzie TYPO3 najpierw sprawdza standardowe uprawnienia, a następnie reguły ACL. Reguły ACL mogą rozszerzać standardowe uprawnienia, ale nie mogą ich ograniczać. To ważny szczegół architektoniczny: jeśli grupa ma już dostęp przez standardowe uprawnienia, be_acl nie może go odebrać.

Rozstrzyganie uprawnień następuje kaskadowo: uprawnienia użytkownika przeważają nad uprawnieniami grup, uprawnienia grup nad uprawnieniami podgrup, a ACL specyficzne dla strony nad rekurencyjnie dziedziczonymi ACL. Ta kaskada działa niezawodnie, dopóki struktura grup pozostaje płaska. Od 4 zagnieżdżonych poziomów grup zachowanie staje się trudne do przewidzenia.

Częste problemy i rozwiązania

Uprawnienia nie działają zgodnie z oczekiwaniami. Najczęstsza przyczyna: użytkownik jest członkiem wielu grup, a uprawnienia jednej grupy nadpisują ograniczenie ACL innej. System uprawnień TYPO3 działa addytywnie, co oznacza, że użytkownik otrzymuje sumę wszystkich uprawnień swoich grup. Rozwiązanie: stworzenie macierzy uprawnień, udokumentowanie wszystkich grup użytkownika i wyeliminowanie nakładających się uprawnień.

Problemy wydajnościowe przy dużych drzewach stron. W instalacjach TYPO3 z ponad 5000 stronami i 20+ grupami użytkowników sprawdzanie ACL może zauważalnie spowolnić drzewo stron w backendzie. Rozszerzenie sprawdza tabelę ACL przy każdym wyświetleniu strony. Rozwiązanie: aktywacja cachowania sprawdzeń ACL i ograniczenie drzewa stron przez options.pageTree.excludeDoktypes do odpowiednich typów stron.

Debugowanie uprawnień jest trudne. TYPO3 nie oferuje wbudowanego narzędzia pokazującego, dlaczego użytkownik ma lub nie ma dostępu do danej strony. Obszar administracyjny “Backend User” pokazuje symulowany widok, ale nie kaskadę uprawnień. Rozwiązanie: analiza TYPO3 System Log (przy aktywnym trybie debugowania TYPO3 loguje próby dostępu) lub bezpośrednie zapytanie do tabeli SQL tx_beacl_acl.

Migracja i kompatybilność wersji

be_acl jest jednym z najdłużej utrzymywanych rozszerzeń TYPO3. Aktualna wersja obsługuje TYPO3 v11 i v12. Dla TYPO3 v13 istnieje wersja beta oparta na nowym systemie modułów backendowych. Rozszerzenie jest aktywnie rozwijane na GitHubie, maintainerzy reagują na zgłoszenia.

Przy migracji z TYPO3 v11 na v12 reguły ACL nie muszą być ręcznie migrowane - tabela bazy danych pozostaje kompatybilna. Jednak rejestracja modułów backendowych zmieniła się w v12, dlatego moduł konfiguracji be_acl wymaga aktualizacji wersji rozszerzenia.

Dla przedsiębiorstw migrujących na TYPO3 v13 zaleca się eksport istniejących reguł ACL przed aktualizacją. TYPO3 v13 wprowadza przebudowany system uprawnień, który przejmuje część funkcji be_acl do rdzenia. Czy rozszerzenie będzie długoterminowo potrzebne, zależy od złożoności koncepcji uprawnień. Gosign analizuje przy aktualizacjach TYPO3 istniejącą konfigurację ACL i rekomenduje optymalne rozwiązanie - czy to be_acl, natywne uprawnienia rdzenia czy kombinacja obu.