Role użytkowników WordPress - zarządzanie uprawnieniami

WordPress ma piec wbudowanych ról i kazda z nich to gotowy zestaw uprawnień dopasowany do innego zadania w zespole. Im wyżej w hierarchii, tym więcej może użytkownik – i tym większe ryzyko, gdy konto wpadnie w niepowolane ręce.

Hierarchia wygląda tak: Administrator > Redaktor (Editor) > Autor (Author) > Współpracownik (Contributor) > Subskrybent (Subscriber). W instalacji wielowitrynowej (Multisite) nad wszystkim stoi jeszcze Super Administrator zarzadzajacy cala siecią stron.

Najważniejszy wniosek praktyczny: granica między Autorem a Wspolpracownikiem to prawo do publikacji, a granica między Redaktorem a Administratorem to dostęp do warstwy technicznej (wtyczki, motywy, kod). To właśnie te dwie granice decydują o bezpieczeństwie witryny.

Rola to tylko etykieta – realne uprawnienia siedzą w capabilities, czyli pojedynczych pozwoleniach typu edit_posts czy install_plugins. Kazda rola to po prostu zapisany w bazie zestaw włączonych capabilities, dlatego można je dodawać i odbierać niezależnie od nazwy roli.

Dzięki temu da się zbudować role na miarę: wziąć Redaktora i odebrać mu manage_categories albo dać Autorowi prawo do edycji cudzych wpisów bez wpuszczania go do ustawień. To granularne podejście jest sercem każdej poważnej kontroli dostępu.

W kodzie sprawdzasz uprawnienie funkcja current_user_can, nie nazwa roli – bo nazwa może być niestandardowa, a capability jest konkretem:

if ( current_user_can( 'edit_posts' ) ) {
    // uzytkownik moze edytowac wpisy
}

To wazna roznica wobec większości poradników, które kończą na opisie piec ról. Capabilities to poziom, na którym faktycznie projektuje się dostęp – role sa tylko skrótem myslowym.

Własne role tworzy się wtedy, gdy żaden z piec domyślnych zestawów nie pasuje do realnego zadania. Klasyczny przykład to specjalista od marketingu, który ma publikować wpisy i zarządzać kategoriami, ale nie ma dotykać wtyczek ani ustawień.

Najprostsza droga to wtyczka. Dwie sprawdzone opcje:

• Members (od StellarWP/Justin Tadlock) – czytelny edytor ról, uprawnienia do treści, shortcode do ukrywania fragmentów przed wybranymi rolami.
• User Role Editor – wtyczka z setkami tysięcy aktywnych instalacji, działa też w Multisite, pozwala zaznaczyć dowolne capabilities checkboxami.

Proces w Members wygląda tak: w menu Members > Add New Role nadajesz nazwę (np. Marketing Manager), zaznaczasz potrzebne capabilities i zapisujesz. Od tej chwili nowa rola pojawia się na liście przy dodawaniu użytkownika.

Dla developera czystszym rozwiązaniem jest kod w motywie potomnym lub wtyczce, bo role zapisują się w bazie raz i nie zależą od aktywnej wtyczki:

add_role( 'marketing_manager', 'Marketing Manager', array(
    'read'          => true,
    'edit_posts'    => true,
    'publish_posts' => true,
    'upload_files'  => true,
    'manage_categories' => true,
) );

Funkcje add_role wystarczy uruchomić jeden raz (np. przy aktywacji wtyczki), a nie przy każdym ładowaniu strony – inaczej niepotrzebnie obciazasz bazę.

Największym ryzykiem w WordPressie nie jest brak roli, tylko jej nadmiar – konto Administratora rozdawane każdemu, kto cokolwiek robi przy stronie. Zasada najmniejszych uprawnień (least privilege) mówi prosto: każdy dostaje dokładnie tyle, ile potrzebuje do swojego zadania, i ani jednej capability więcej.

Dlaczego to ma znaczenie? Przejete konto Administratora oznacza pelna kontrolę nad witryna – instalacje złośliwego kodu, podmianę treści, dostęp do danych użytkowników. Przejete konto Autora to w najgorszym razie kilka wpisów do usunięcia. Roznica w skutkach jest ogromna.

Praktyczna checklista higieny ról:

• Jedno konto Administratora na właściciela – nie współdzielone, nie nazwane admin.
• Do codziennej pracy używaj konta o niższych uprawnieniach (Redaktor/Autor), nawet jeśli jesteś właścicielem.
• Agencji lub freelancerowi dawaj Redaktora do treści, Administratora tylko na czas konkretnej pracy technicznej.
• Regularnie przeglądaj listę w Użytkownicy i usuwaj nieaktywne konta.
• Włącz uwierzytelnianie dwuskładnikowe (2FA) przynajmniej dla ról z dostępem do wp-admin.

Po instalacji WooCommerce WordPress zyskuje dwie dodatkowe role dopasowane do sklepu: Customer (Klient) i Shop Manager (Kierownik sklepu). To rozszerzenie standardowego systemu o uprawnienia związane z zamówieniami i produktami.

Shop Manager to w praktyce odpowiednik Redaktora dla sklepu – może prowadzić cały biznes operacyjnie (dodawać produkty, realizować zamówienia, wystawiać kupony), ale nie ma uprawnień do instalacji wtyczek czy zmiany ustawień WordPressa. Customer dostaje minimalny dostęp wystarczający do obsługi własnego konta.

Gdy sklep rośnie, często trzeba dołożyć role pośrednie – np. magazyniera, który widzi i zmienia status zamówień, ale nie dotyka cen ani danych klientów. Wtedy wracamy do capabilities i wtyczki typu User Role Editor, ktora pozwala wyciąć Shop Managerowi część uprawnień albo zbudować role od zera. Przy bardziej rozbudowanych sklepach taka kontrola dostępu to element, który planujemy już na etapie budowy strony internetowej, a nie dorabiamy po fakcie.

Wdrożenie tego, o czym piszemy w artykule, wymaga doświadczenia i czasu. Jeśli wolisz, by zajęli się tym specjaliści, sprawdź naszą ofertę WordPress lub ofertę sklepów internetowych.

Możesz też napisać do nas bezpośrednio – umów bezplatna konsultację, a my przeanalizujemy Twoja sytuację i zaproponujemy najlepsze rozwiązanie.