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 dla każdej strony i dla dowolnej liczby użytkowników i grup regulują, kto może tam co widzieć, edytować lub usuwać.

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. Uprawnienia na poziomie pól pochodzą przy tym z rdzenia TYPO3: dzięki dozwolonym polom swojej grupy backendowej użytkownik widzi pole tekstowe, ale nie ustawienia układu ani konfigurację wtyczki. be_acl uzupełnia to o odpowiednie uprawnienia do stron, na przykład edycję treści bez możliwości tworzenia lub usuwania stron.

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 pięciu uprawnieniach stron TYPO3: wyświetlanie strony (show), edycja strony, usuwanie strony, tworzenie podstron i edycja treści. Te uprawnienia są przyznawane per strona lub rekurencyjnie dla drzewa stron. Konfiguracja odbywa się w module backendu Web > Access: tam administrator zakłada dla strony ACL dla użytkownika lub grupy 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ń podlega dwóm regułom. Po pierwsze, dla użytkownika i dla każdej z jego grup obowiązuje ta ACL, która leży najbliżej strony: ACL na samej stronie albo najbliższa rekurencyjna ACL powyżej niej. Po drugie, be_acl sumuje uprawnienia z ACL użytkownika i grup (połączenie przez OR), a przy aktywnym starym systemie uprawnień dodaje je również do klasycznych uprawnień stron; jedna grupa nie może więc odebrać uprawnień innej.

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. Według dokumentacji obliczanie ACL staje się odczuwalne od około 1000 stron, przede wszystkim przy tworzeniu elementów treści i edycji właściwości strony; obciążenie rośnie wraz z liczbą podstron, dla których obowiązuje ACL. Obliczenia te be_acl już buforuje, na życzenie w Redis. Rozwiązanie: nie zakładać ACL na stronie głównej (root), uprawnienia globalne nadawać przez klasyczny system uprawnień, a ACL stosować tylko dla poddrzew.

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

Od stycznia 2021 nie ukazała się żadna nowa wersja be_acl. Ostatnia wersja 2.0.1 obsługuje tylko TYPO3 v10, dla v11, v12 i v13 nie ma wydania.

Kto przechodzi z TYPO3 v10 na nowszą wersję, musi więc samodzielnie przenieść be_acl albo przestawić uprawnienia na narzędzia rdzenia. Podstawą są istniejące reguły w tabeli tx_beacl_acl; przy przenoszeniu na v12 lub nowszą dochodzi zmieniona rejestracja modułów backendowych.

Dla przedsiębiorstw migrujących na TYPO3 v13 zaleca się eksport istniejących reguł ACL przed aktualizacją. TYPO3 v13 przebudowuje wprawdzie zarządzanie uprawnieniami w backendzie, ale nie przejmuje żadnej funkcji be_acl: także rdzeń v13 nie pozwala, by kilka grup miało własne uprawnienia na tej samej stronie. Czy koncepcję uprawnień da się odwzorować uprawnieniami rdzenia, zależy od jej złożoności. Gosign analizuje przy aktualizacjach TYPO3 istniejącą konfigurację ACL i rekomenduje optymalne rozwiązanie - czy to be_acl, natywne uprawnienia rdzenia czy kombinacja obu.