Alternative à User Role Editor : cinq questions avant de changer

Qui cherche une alternative à un plugin de gestion des droits n'a généralement pas rencontré d'erreur, mais remarqué une faille : un client voit des entrées de menu qui ne le concernent pas. Un article protégé apparaît malgré tout quelque part. Ou bien on ne sait plus dire qui a reçu quel droit et quand. Cinq questions permettent d'y voir clair.

Question 1 : la règle tient-elle aussi sans l'administration ?

C'est la plus importante, et vous pouvez y répondre vous-même en une minute. Protégez un article de sorte que seul un rôle précis puisse le voir. Déconnectez-vous. Appelez /wp-json/wp/v2/posts?search= avec un mot tiré de cet article.

Si le contenu figure dans la réponse, votre règle ne modifie que l'affichage. L'API REST de WordPress est accessible par défaut, et elle interroge d'autres endroits du code qu'une liste d'articles dans l'administration. Kakapo Roles y applique explicitement la règle de visibilité aussi — c'est précisément pour cela que ce test est le moyen le plus rapide d'évaluer un plugin de gestion des droits.

Faites aussi ce test avec le plugin que vous utilisez actuellement, avant de changer. Parfois, la faille est ailleurs — par exemple dans un constructeur de pages qui diffuse des contenus via son propre endpoint.

Question 2 : quelqu'un peut-il s'attribuer lui-même plus de droits ?

Un plugin de gestion des droits qui permet à quiconque a accès à son interface d'élever son propre rôle perd sa raison d'être. WordPress prévoit pour cela un garde-fou — get_editable_roles() —, qui détermine quels rôles une personne a le droit de modifier. Question à poser à l'alternative : est-il respecté, partout ?

En mode réseau, une seconde limite s'ajoute : les rôles y sont en partie définis à l'échelle du réseau. Qui les écrase depuis un sous-site les modifie pour tous les sites du réseau — y compris ceux qui ne lui appartiennent pas.

Question 3 : peut-on épurer l'administration ?

Les droits disent ce que quelqu'un PEUT faire. Pour un client, ce qu'il VOIT est tout aussi important. Un éditeur face à douze entrées de menu dont dix sont verrouillées n'a pas une administration sûre, mais confuse.

Vérifiez donc si l'alternative va au-delà des rôles et des droits : menu d'administration par rôle, médiathèque limitée aux fichiers de chacun, widgets et menus de navigation, shortcodes autorisés, redirection après la connexion. Kakapo Roles intègre tout cela — pour de nombreux plugins de ce type, ce sont des extensions séparées ou des extraits de code.

Question 4 : peut-on retrouver ce qui a été modifié ?

On modifie rarement les droits, et le plus souvent dans l'urgence. Six mois plus tard, la question se pose de savoir pourquoi un rôle a le droit de faire quelque chose. Sans journal, la réponse n'est qu'une supposition.

Question à poser à l'alternative : existe-t-il un journal des modifications, et indique-t-il QUI a reçu ou perdu QUEL droit, et QUAND ? Kakapo Roles en tient un et y consigne aussi les modifications qui passent par l'attribution et la migration.

Question 5 : dois-je tout reconstruire sur chaque site ?

Qui gère plusieurs installations construit plusieurs fois la même structure de droits — en s'écartant un peu du modèle à chaque fois. Au bout d'un an, cinq sites font cinq cas particuliers. Vérifiez donc si la structure peut être exportée et importée, et ce qu'il advient des rôles existants lors de l'import : compléter ou remplacer ?

Kakapo Roles sait faire les deux et indique avant l'import laquelle des deux voies est choisie. « Remplacer » est la plus risquée — c'est pourquoi elle doit être explicitement confirmée.

La liste de contrôle en bref

Ce qu'il faut faire avant de changer

1. Consignez l'état actuel — quels rôles personnalisés existent et quels droits leur sont associés.
2. Créez une sauvegarde. Les droits sont stockés dans la base de données, une fausse manœuvre touche tous les utilisateurs à la fois.
3. Recréez la structure dans le nouveau plugin et comparez-la ligne par ligne.
4. Connectez-vous avec un utilisateur de test par rôle et vérifiez ce qu'il voit réellement.
5. Faites le test REST de la question 1.
6. Désactivez l'ancien plugin au lieu de le supprimer — pendant deux semaines.

Deux plugins de gestion des droits actifs en même temps écrivent dans les mêmes rôles, et c'est le dernier à enregistrer qui l'emporte. Pendant la période de transition, ne modifiez quelque chose que dans l'un des deux.

Questions fréquentes