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

WordPress ma pięć domyślnych ról dla pojedynczej witryny. Każda jest zestawem uprawnień dopasowanym do innego rodzaju pracy. Nie traktuj ich jednak jak ścisłej drabiny, na której każdy wyższy szczebel zawsze zawiera wszystkie możliwości niższego. Wtyczki, własny kod i ustawienia sieci mogą zmienić zakres dostępu.

Punktem odniesienia jest dokumentacja ról i capabilities WordPress. W instalacji wielowitrynowej Super Administrator zarządza siecią, więc Administrator pojedynczej witryny nie ma identycznego zakresu jak w zwykłej instalacji. Kontekst opisujemy w poradniku WordPress Multisite.

Przydział rozpocznij od listy czynności. Autor zewnętrzny może tylko oddawać szkice, a wewnętrzny redaktor zatwierdzać publikację. Dostęp do samych wpisów nie oznacza automatycznie dostępu do produktów czy innych własnych typów treści. Zapisz te różnice przed wybraniem roli z listy.

Capabilities to pojedyncze uprawnienia, na przykład publish_posts albo install_plugins. Rola przechowuje ich zestaw, a funkcja current_user_can sprawdza możliwość wykonania działania przez aktualnego użytkownika. Weryfikacja samej nazwy roli jest krucha: niestandardowa rola może otrzymać potrzebną capability bez etykiety Administratora.

Dla konkretnego wpisu użyj sprawdzenia obiektowego. W poniższym fragmencie $post_id oznacza wcześniej ustalony identyfikator wpisu; kod pokazuje jedynie decyzję o uprawnieniu, nie zapisuje treści:

if ( current_user_can( 'edit_post', $post_id ) ) {
    // Kontynuuj obsluge operacji na tym wpisie.
}

Dokumentacja current_user_can wyjaśnia przekazywanie dodatkowych argumentów dla uprawnień związanych z obiektem. W pełnym endpointcie sprawdź też poprawność danych wejściowych i właściwą ochronę żądania. Sam nonce pomaga chronić przed określonym nadużyciem żądania, ale nie nadaje użytkownikowi prawa do edycji obiektu.

Własna rola ma sens, gdy domyślne zestawy nie pasują do zadania. Przykładowo osoba od marketingu może publikować własne wpisy, aktualizować je po publikacji i przesyłać ilustracje, ale nie zarządzać wtyczkami. Do ustalenia pozostaje edycja cudzych materiałów, usuwanie wpisów i zmiana kategorii. Nie dopisuj tych uprawnień przez przyzwyczajenie.

Edytor ról, taki jak Members, pozwala pracować z capabilities w panelu. Przed zapisem porównaj planowane zmiany z listą zadań. Nie przyznawaj nieznanej capability tylko dlatego, że jej nazwa przypomina potrzebną funkcję; najpierw sprawdź, która wtyczka ją definiuje i gdzie egzekwuje.

Własny kod najlepiej umieścić we wtyczce odpowiedzialnej za funkcję, aby rola nie zależała od wyglądu strony. Poniższy fragment pokazuje utworzenie przykładowego zestawu. To kod zmieniający konfigurację ról, przeznaczony do kontrolowanego etapu instalacji na środowisku testowym:

add_role( 'kc_marketing', 'Marketing', array(
    'read'                 => true,
    'edit_posts'           => true,
    'edit_published_posts' => true,
    'publish_posts'        => true,
    'upload_files'         => true,
) );

Funkcja add_role dodaje rolę, jeśli ta jeszcze nie istnieje. Gdy istnieje, zwraca null i nie aktualizuje jej capabilities. Zmiana tablicy w powyższym kodzie nie zmieni zatem automatycznie dostępu osób już korzystających z roli. Potrzebna jest jawna migracja istniejącej konfiguracji, na przykład przez metody add_cap i remove_cap obiektu roli.

Zapisz wersję schematu uprawnień, wykonaj migrację w kontrolowanym kroku i sprawdź jej wynik. Nie usuwaj i nie odtwarzaj roli przy każdym wejściu na stronę. Dla aktualizacji określ również sposób wycofania zmiany, zwłaszcza jeśli z danej roli korzystuje aktywny zespół.

Zasada najmniejszych uprawnień oznacza przyznanie dostępu wystarczającego do zadania. Administrator potrzebny do instalacji integracji nie musi pozostać Administratorem po zakończeniu wdrożenia. Jednocześnie konto Autora także wymaga ochrony: jego przejęcie może służyć publikacji szkodliwej treści, podmianie materiałów lub nadużyciu dostępu do plików. Mniejszy zakres nie oznacza braku ryzyka.

Praktyczny porządek dostępów obejmuje indywidualne konta, silne uwierzytelnianie i 2FA, rozdzielenie codziennej redakcji od administracji oraz termin przeglądu uprawnień. Nie współdziel konta z wykonawcą, bo utrudnisz odebranie dostępu i ustalenie autora zmian. Przy szerszym przeglądzie zobacz zasady bezpieczeństwa sklepu internetowego.

Ukrycie pozycji menu albo przekierowanie z wp-admin porządkuje interfejs, lecz nie zastępuje autoryzacji. Operację trzeba zabezpieczyć w miejscu, które ją wykonuje, również w REST API i AJAX. Użytkownik nie powinien uzyskać zabronionych danych po bezpośrednim otwarciu adresu pominiętego w menu.

Testuj uprawnienia na osobnym koncie z docelową rolą. Sprawdź edycję własnego szkicu, własnego opublikowanego wpisu i cudzego wpisu. Zapisz oczekiwane odmowy, nie tylko czynności dozwolone. Powtórz istotne testy po zmianach wtyczek zgodnie z procedurą aktualizacji WordPressa.

WooCommerce dodaje role Customer i Shop Manager. Pierwsza służy kupującemu, druga obsłudze sklepu. Ich rzeczywisty zakres trzeba sprawdzić w działającej instalacji, ponieważ rozszerzenia mogą wprowadzać dodatkowe capabilities oraz własne formularze.

Zgodnie z dokumentacją WooCommerce Shop Manager nie jest wyłącznie operatorem pakowania zamówień. Dostęp do ustawień sklepu ma znaczenie dla bezpieczeństwa konfiguracji. Nie utożsamiaj go również z Administratorem WordPressa, który zarządza warstwą techniczną witryny.

Jeśli magazynier ma widzieć tylko informacje potrzebne do realizacji, samo schowanie cen lub menu nie wystarczy. Trzeba ustalić zestaw udostępnianych danych, sprawdzić obsługujące je endpointy i potwierdzić, że rola nie otwiera szerszego widoku zamówienia. Test powinien objąć również eksport oraz używane integracje. Projektowanie takiego dostępu warto uwzględnić już podczas budowy strony internetowej z funkcjami sprzedażowymi.

Po zakończeniu współpracy odbierz uprawnienia, sprawdź aktywne sesje i powiązane metody dostępu. Klucze integracji czy hasła aplikacji wymagają osobnego przeglądu; nie zakładaj, że zmiana widocznej roli zamyka każdą drogę. Zapisz osobę odpowiedzialną za odbiór oraz datę zakończenia dostępu.

Zmiana roli sama w sobie nie kasuje wpisów użytkownika. Usunięcie konta jest inną operacją i może wymagać decyzji o przypisaniu treści. Przed usunięciem ustal, które materiały mają pozostać i kto przejmuje ich redakcję. W Multisite odróżnij usunięcie z jednej witryny od operacji dotyczącej konta w sieci.

Jeśli chcesz uporządkować uprawnienia, opisz zakres pracy zespołu. W ramach obsługi WordPressa możemy przygotować role, test dostępu i instrukcję przekazania. Późniejsze korekty oraz przeglądy da się objąć małym pakietem godzinowym; zakres opieki i SLA ustalamy indywidualnie, zależnie od funkcji strony.