Members vs. Kakapo Roles: zarządzanie uprawnieniami, które naprawdę działają
Wtyczkę do uprawnień ocenia się według jednego pytania: czy uprawnienie działa także wtedy, gdy nikt nie klika po panelu administracyjnym? Wiele z tego, co nazywa się „ukrywaniem”, zmienia tylko widok — dane nadal leżą na wierzchu, jedno wywołanie REST API dalej. To porównanie zestawia Members i Kakapo Roles właśnie pod tym kątem.
Krótka odpowiedź
Members to uznana, bezpłatna wtyczka do uprawnień: tworzenie i edycja ról, przypisywanie uprawnień, ochrona treści według roli. Jest lekka, popularna i wystarczająca w większości prostych przypadków.
Kakapo Roles sięga o poziom głębiej. Zarządza nie tylko rolami i uprawnieniami, lecz także tym, co użytkownik w ogóle widzi w panelu administracyjnym — menu administracyjnym, biblioteką mediów, widgetami, shortcode’ami — i wyraźnie egzekwuje reguły widoczności także w REST API. Do tego dochodzą dziennik zmian, kosz na usunięte role oraz import/eksport.
W skrócie: kto chce tworzyć role i chronić treści, z Members zajdzie daleko i nic nie zapłaci. Kto chce dać klientowi uporządkowany panel, dokumentować uprawnienia w sposób możliwy do prześledzenia albo nie dopuścić do tego, by reguła dotyczyła tylko interfejsu, lepiej trafi z Kakapo Roles.
Co potrafią obie
- Tworzenie, zmiana nazwy i usuwanie własnych ról
- Ustawianie uprawnień dla każdej roli, także dla własnych typów treści
- Dodatkowe nadawanie lub odbieranie uprawnień pojedynczym użytkownikom
- Ograniczanie treści do określonych ról
- Wiele ról na użytkownika
Do tego miejsca wybór jest kwestią gustu. Dalej robi się ciekawie.
Czym się różnią
| Pytanie | Members | Kakapo Roles |
|---|---|---|
| Cena | bezpłatnie | wtyczka płatna, jedna licencja na dziewięć |
| Uprawnienia do treści także przez REST API | do sprawdzenia | tak, wyraźnie egzekwowane |
| Ukrywanie menu administracyjnego według roli | przez rozszerzenia | wbudowane |
| Ograniczenie biblioteki mediów do własnych plików | przez rozszerzenia | wbudowane |
| Widgety i menu nawigacji według roli | — | wbudowane |
| Zezwalanie na shortcode’y według roli | — | wbudowane |
| Przekierowanie po zalogowaniu według roli | — | wbudowane |
| Kosz na usunięte role | — | tak, z przywracaniem |
| Dziennik zmian | — | tak, kto kiedy jakie uprawnienie zmienił |
| Import i eksport uprawnień | — | tak, jako plik |
| Ochrona przed eskalacją uprawnień | do sprawdzenia | get_editable_roles jest respektowane, także w sieci witryn |
| Wiele stron | osobno dla każdej strony | zdalny status i jedna licencja na wszystkie strony |
Różnica, która się liczy: ukrycie to nie blokada
Jeśli wpis ma być widoczny „tylko dla określonych ról”, można to zrealizować na dwa sposoby. Pierwszy ukrywa go na listach i w publicznej części witryny. Drugi odrzuca dostęp — wszędzie, także tam, gdzie nikt nie klika.
Ta różnica to nie drobiazg. REST API WordPressa jest domyślnie dostępne; wywołanie /wp-json/wp/v2/posts zwraca wpisy jako JSON, bez logowania. Reguła, która zmienia tylko widok, jest tam bezskuteczna — treść przeznaczona „tylko dla członków” widnieje w odpowiedzi otwartym tekstem.
Dlatego Kakapo Roles egzekwuje regułę widoczności także w REST API. Ten jeden wiersz jest powodem, dla którego wtyczkę do uprawnień w ogóle da się sprawdzić: otwórz raz swój chroniony adres jako JSON, po wylogowaniu. Jeśli treść tam jest, reguła niczego nie chroni.
Ten test możesz wykonać z każdą wtyczką, także z tą, której właśnie używasz: zabezpiecz wpis, wyloguj się, otwórz /wp-json/wp/v2/posts?search=…. Trwa minutę i mówi więcej niż jakakolwiek lista funkcji.Druga pułapka: kto może nadawać uprawnienia?
Wtyczka do uprawnień, która pozwala każdemu z dostępem do interfejsu nadać sobie więcej uprawnień, sama się znosi. WordPress ma na to zabezpieczenie: get_editable_roles() określa, które role ktoś w ogóle może edytować. Wtyczka, która je pomija, otwiera dokładnie tę drogę, którą ma zamykać.
W sieci witryn dochodzi drugie pytanie: role są tam częściowo wspólne dla całej sieci. Kto nadpisuje je z poziomu jednej z witryn, zmienia je dla wszystkich witryn. Kakapo Roles uwzględnia jedno i drugie — zabezpieczenie i granicę między witryną a siecią.
Kiedy Members jest lepszym wyborem
- Potrzebujesz ról i uprawnień, niczego więcej
- Budżet wynosi zero
- Pracujesz z pojedynczą stroną i niewielką liczbą użytkowników
- Chcesz wtyczki, która robi dokładnie jedną rzecz
Kiedy Kakapo Roles jest lepszym wyborem
- Przekazujesz panel administracyjny klientowi i chcesz go uporządkować — menu, biblioteka mediów, widgety
- Chronione treści mają być chronione także w REST API
- Musisz móc wykazać, kto kiedy jakie uprawnienie otrzymał
- Chcesz raz zbudować strukturę uprawnień i przenosić ją na kolejne strony
- I tak korzystasz z innych wtyczek Kakapo i chcesz jednej faktury zamiast pięciu
Przejście: co trzeba zrobić
- Zapisz, jakie masz własne role i jakie uprawnienia są do nich przypisane — wystarczy zrzut ekranu macierzy.
- Utwórz kopię zapasową. Uprawnienia są zapisane w bazie danych, a jeden błąd dotyka wszystkich użytkowników jednocześnie.
- Zainstaluj Kakapo Roles i wpisz klucz licencyjny.
- Odtwórz role i porównaj macierz wiersz po wierszu ze swoją notatką.
- Zaloguj się jako użytkownik testowy każdej roli i sprawdź, co ten użytkownik naprawdę widzi.
- Wykonaj test REST dla chronionej treści.
- Dopiero potem wyłącz starą wtyczkę — nie usuwaj jej, przez dwa tygodnie.
Dwie wtyczki do uprawnień jednocześnie to zły stan: obie zapisują do tych samych ról, a wygrywa ta, która zapisze ostatnia. Niech okres przejściowy będzie krótki, a w tym czasie zmieniaj coś tylko w jednej z nich.
Najczęściej zadawane pytania
Czy Kakapo Roles przejmie moje istniejące role?
Co stanie się z moimi rolami, gdy usunę wtyczkę?
Czy mogę przywrócić usuniętą rolę?
Czy ograniczenie działa też w publicznej części witryny?
Co się dzieje bez ważnej licencji?
Kakapo Roles — zapłać raz, korzystaj zawsze.
Wszystkie dziewięć wtyczek za 149 € jednorazowo zamiast 13 € miesięcznie. Bezpieczna płatność przez Stripe. Przez pierwsze 14 dni: problem rozwiązany albo zwrot pieniędzy.
Wybierz Lifetime Wszystkie funkcje