Panel administracyjny widzi całe dane firmy — dlatego uprawnienia nie są w nim dodatkiem, a fundamentem. W praktyce projektujemy je w trzech warstwach: kto w ogóle wchodzi do panelu, co widzi po zalogowaniu i co może zmienić w konkretnym rekordzie. Ten artykuł pokazuje, jak te warstwy wdrożyć w Filament 5 krok po kroku — na bazie rozwiązań, które stosujemy w każdym wdrożeniu.
- Punkty wyjścia: użytkownik „obsługa" nie powinien widzieć modułu finansów, manager tylko swój zespół, a administrator — wszystko, ale z pełnym logiem zmian. Jeśli budujesz panel od zera, kontekst znajdziesz w artykule panel administracyjny w Laravel krok po kroku.
Warstwa 1 — kto wchodzi do panelu
Dostęp do panelu to nie to samo co konto w aplikacji. W Filament decyduje o tym metoda canAccessPanel() na modelu użytkownika — do panelu wpuszczasz tylko role administracyjne, a nie wszystkich zarejestrowanych. Do tego, standardowo:
- dwuskładnikowe uwierzytelnianie (2FA) dla każdego konta z dostępem do panelu,
- osobna ścieżka panelu (np.
/zarzadzaniezamiast/admin), utrudniająca automatyczne skany, - limitowanie prób logowania i blokada konta po serii nieudanych prób,
- sesje wygasające po bezczynności — panel nie może „wisieć" zalogowany na współdzielonym komputerze.
Warstwa 2 — role i uprawnienia (Spatie Permission)
Do zarządzania rolami używamy pakietu spatie/laravel-permission — standardu w ekosystemie Laravel, z którym Filament integruje się bezpośrednio. Role definiujesz raz (administrator, manager, obsługa, księgowość, partner), a uprawnienia przypisujesz do ról, nie do osób — dzięki temu zmiana w jednym miejscu działa dla całego zespołu.
W panelu wystarczy, że użytkownik ma rolę: $user->hasRole('manager'). Widoczność modułów ustawiasz przez shouldRegisterNavigation() na zasobach, a dostęp do stron i akcji — przez polityki (warstwa 3). Jeśli chcesz wygenerować uprawnienia dla wszystkich zasobów automatycznie, wtyczka Filament Shield robi to jedną komendą — ale w mniejszych panelach ręczne polityki są czytelniejsze i łatwiejsze w testach.
Warstwa 3 — co dokładnie może zmienić (Policies + pola)
Same role to za mało — potrzebna jest kontrola na poziomie rekordu i pola
- Policies — metody
viewAny,view,create,update,deletedecydują o dostępności akcji per rekord; Filament respektuje je automatycznie w zasobach, akcjach i tabelach. - Scope zapytań — lista zamówień dla managera musi być filtrowana po jego zespole na poziomie zapytania (
modifyQueryUsing), nie w widoku. To najczęstsze miejsce błędów klasy IDOR: uprawnienie do akcji jest, ale rekord wciąż można odczytać po ID. - Pola — pole finansowe dla roli „obsługa" ustaw jako
disabled()albo całkiem ukryte (hidden()); uprawnienia na poziomie pól to w Filament kwestia kilku linii, a realnie chroni dane wrażliwe.
Uwaga: Ukrycie przycisku w interfejsie nie jest zabezpieczeniem. Każdą akcję trzeba zabezpieczyć po stronie serwera (polityka albo autoryzacja w metodzie) — ukrycie w UI to tylko UX, nie kontrola dostępu.
Log zmian i audyt
Kto, co i kiedy zmienił — w panelach obsługujących dane osobowe i finansowe to wymóg, nie opcja. Pakiet spatie/laravel-activitylog zapisuje zmiany modeli (wraz z wartościami przed i po), a historię pokazujesz w panelu jako zakładkę na rekordzie. Uzupełnienie stanowią logi logowań i eksportów: eksport danych klientów to zdarzenie, które powinno zostawiać ślad.
Jak testować uprawnienia
Uprawnienia testujemy jak każdą logikę biznesową — testami, nie klikaniem po panelu
- test, że użytkownik bez roli nie dostaje się do panelu (
canAccessPanel), - test, że obsługa nie widzi modułu finansów (brak w nawigacji i 403 na URL),
- test, że manager widzi tylko zamówienia swojego zespołu (scope zapytania),
- test, że akcja masowa nie omija polityk.
To zestaw, który powtarzamy w każdym projekcie; szerszy kontekst testowania opisuje artykuł o testach automatycznych w Laravel.
Najczęściej zadawane pytania
Jak ograniczyć widoczność pól w panelu Filament?
- Na poziomie pola:
->hidden(fn () => ! auth()->user()->can('viewFinancials'))albo->disabled()dla podglądu bez edycji. Uprawnienie warto zdefiniować w polityce, a nie inline — wtedy działa spójnie w formularzach, tabelach i API.
Czy Filament Shield jest potrzebny?
Przy kilku zasobach i rolach nie — ręczne polityki są czytelniejsze. Shield przydaje się w dużych panelach, gdzie generowanie uprawnień dla dziesiątek zasobów ręcznie byłoby żmudne. W obu przypadkach zasada jest ta sama: uprawnienia testujemy automatycznie.
Czy Spatie Permission wystarczy do zabezpieczenia panelu?
Spatie Permission odpowiada za role i uprawnienia, ale bezpieczeństwo panelu to także: polityki per rekord, scope zapytań, 2FA, limitowanie logowania i log audytu. Role bez tych warstw dają złudzenie kontroli — pełny obraz zasad opisuje artykuł o bezpieczeństwie aplikacji Laravel.
Jak testować uprawnienia w panelu administracyjnym?
- Testami feature: utwórz użytkowników z różnymi rolami i sprawdzaj dostęp do zasobów, widoczność rekordów (scope) i reakcje na akcje masowe. Testy uprawnień uruchamiamy w CI razem z resztą testów — regresja w politykach to zbyt kosztowny błąd, żeby wychwytywać ją ręcznie.
👉 Budujesz panel z rolami i nie chcesz dziur w uprawnieniach? Projektujemy i audytujemy uprawnienia w panelach Filament — zobacz Laravel Development lub opiekę techniczną.
📖 Zobacz również: panel administracyjny w Laravel krok po kroku, Filament i Livewire — panele administracyjne w Laravel oraz bezpieczeństwo aplikacji Laravel — OWASP Top 10.