Members vs. Kakapo Roles: rechten beheren die ook standhouden

Een rechtenplugin wordt aan één enkele vraag gemeten: houdt het recht ook stand als niemand door de backend klikt? Veel van wat ‘verbergen’ heet, verandert alleen de weergave — de gegevens liggen nog steeds open, één aanroep van de REST API verderop. Deze vergelijking zet Members en Kakapo Roles op dat punt op een rij.

Het korte antwoord

Members is een gevestigde, gratis rechtenplugin: rollen aanmaken en bewerken, rechten toewijzen, content per rol beschermen. Hij is slank, wijdverbreid en volstaat voor de meeste eenvoudige gevallen.

Kakapo Roles gaat een laag dieper. Het beheert niet alleen rollen en rechten, maar ook wat een gebruiker in de backend überhaupt ziet — beheermenu, mediabibliotheek, widgets, shortcodes —, en het dwingt de zichtbaarheidsregels uitdrukkelijk ook in de REST API af. Daarbij komen een wijzigingslogboek, een prullenbak voor verwijderde rollen en import/export.

Kort gezegd: wie rollen wil aanmaken en content wil beschermen, komt met Members ver en betaalt niets. Wie een klant een opgeruimde backend wil geven, rechten controleerbaar wil documenteren of wil voorkomen dat een regel alleen de interface raakt, zit beter bij Kakapo Roles.

Wat beide kunnen

• Eigen rollen aanmaken, hernoemen en verwijderen
• Rechten per rol instellen, ook die van eigen inhoudstypen
• Afzonderlijke gebruikers extra rechten geven of rechten ontnemen
• Content beperken tot bepaalde rollen
• Meerdere rollen per gebruiker

Tot hier is de keuze een kwestie van smaak. Daaronder wordt het interessant.

Waar de twee verschillen

Het verschil dat telt: verbergen is niet blokkeren

Als een bericht ‘alleen voor bepaalde rollen’ zichtbaar moet zijn, zijn er twee manieren om dat te doen. De ene verbergt het in lijsten en in de frontend. De andere weigert de toegang — overal, ook daar waar niemand klikt.

Het verschil is geen detail. De REST API van WordPress is standaard bereikbaar; een aanroep van /wp-json/wp/v2/posts levert berichten als JSON, zonder in te loggen. Een regel die alleen de weergave verandert, heeft daar geen effect — de content die ‘alleen voor leden’ bedoeld was, staat als platte tekst in het antwoord.

Kakapo Roles dwingt de zichtbaarheidsregel daarom ook in de REST API af. Dat ene punt is de reden waarom je een rechtenplugin überhaupt kunt toetsen: roep je beschermde adres één keer als JSON op, uitgelogd. Staat de content er, dan beschermt de regel niets.

Deze test kun je bij elke plugin doen, ook bij de plugin die je nu gebruikt: bericht beveiligen, uitloggen, /wp-json/wp/v2/posts?search=… aanroepen. Hij duurt een minuut en beantwoordt meer dan welke functielijst ook.

De tweede valkuil: wie mag rechten toekennen?

Een rechtenplugin die iedereen met toegang tot de interface toestaat zichzelf meer rechten te geven, heft zichzelf op. WordPress heeft daar een hook voor: get_editable_roles() bepaalt welke rollen iemand überhaupt mag bewerken. Een plugin die die hook omzeilt, opent precies de weg die hij moet afsluiten.

In een multisite-netwerk komt er een tweede vraag bij: rollen gelden daar deels netwerkbreed. Wie ze vanaf een subsite overschrijft, wijzigt ze voor alle sites. Kakapo Roles houdt met beide rekening — met de hook en met de grens tussen site en netwerk.

Wanneer Members de betere keuze is

• Je hebt rollen en rechten nodig, verder niets
• Het budget is nul
• Je werkt met één site en weinig gebruikers
• Je wilt een plugin die precies één ding doet

Wanneer Kakapo Roles de betere keuze is

• Je draagt een backend over aan een klant en wilt die opruimen — menu, mediabibliotheek, widgets
• Beschermde content moet ook via de REST API beschermd zijn
• Je moet kunnen aantonen wie wanneer welk recht heeft gekregen
• Je wilt een rechtenstructuur één keer opbouwen en naar andere sites overzetten
• Je gebruikt sowieso al andere Kakapo-plugins en wilt één factuur in plaats van vijf

Overstappen: wat je moet doen

1. Noteer welke eigen rollen er zijn en welke rechten daaraan hangen — een screenshot van de matrix is genoeg.
2. Maak een back-up. Rechten zitten in de database, en een misser raakt alle gebruikers tegelijk.
3. Installeer Kakapo Roles en voer de licentiesleutel in.
4. Bouw de rollen na en vergelijk de matrix regel voor regel met je notitie.
5. Log per rol in met een testgebruiker en kijk wat die echt ziet.
6. Doe de REST-test voor een stuk beschermde content.
7. Schakel pas daarna de oude plugin uit — niet verwijderen, voor twee weken.

Twee rechtenplugins tegelijk gebruiken is een slechte situatie: beide schrijven in dezelfde rollen, en wie het laatst opslaat, wint. Houd de overgangsperiode kort en wijzig in die tijd alleen in een van beide iets.

Veelgestelde vragen