Accès client à l'administration : les droits vraiment nécessaires

Un client doit pouvoir mettre à jour des textes. La voie la plus rapide est un accès administrateur — et la plus coûteuse. Non pas parce que quelqu'un ferait quelque chose de malveillant, mais parce qu'un mauvais clic dans la section des plugins coûte plus cher que les dix minutes qu'aurait demandées un rôle propre.

Ce que WordPress fournit d'origine

Dans la plupart des cas, Éditeur est la bonne réponse. Ce rôle couvre entièrement les contenus et laisse la technique de côté.

Là où le rôle Éditeur ne suffit pas

Trois choses manquent régulièrement à un éditeur, et pour chacune il existe une meilleure réponse que « alors administrateur, tant pis » :

• Modifier les menus — nécessite un droit habituellement réservé à l'administrateur, qui peut être attribué de manière ciblée
• Utiliser un constructeur de pages — beaucoup apportent leurs propres droits, attribuables un par un
• Gérer des formulaires ou une boutique — les plugins concernés définissent eux-mêmes leurs propres droits pour cela

La démarche est toujours la même : ajouter le droit qui manque, au lieu de changer de rôle. C'est précisément à cela que sert une matrice des droits.

Épurer compte plus que verrouiller

Une administration avec douze entrées de menu dont dix sont verrouillées n'est pas sûre, mais confuse. Le client cherche, clique à côté et appelle. Les droits disent ce que quelqu'un peut faire ; ce qu'il voit tout court est tout aussi important.

• Réduire le menu d'administration à ce qui est utile
• Limiter la médiathèque aux fichiers de chacun lorsque plusieurs clients utilisent la même installation
• Masquer les widgets et menus de navigation qui ne concernent personne
• Après la connexion, rediriger là où le travail commence — pas vers le tableau de bord et ses cinq encadrés de notification

Le test qui prend une minute

On ne peut pas juger des droits depuis l'écran où on les définit. Créez un utilisateur de test par rôle et connectez-vous avec cet utilisateur — dans un second navigateur, pour que votre propre session reste ouverte.

Et pour les contenus protégés, il existe un second test : déconnectez-vous et appelez /wp-json/wp/v2/posts?search= avec un mot tiré de l'article protégé. Si le contenu figure dans la réponse, votre règle ne modifie que l'affichage — les données sont exposées.

Ce test vaut pour tout plugin de gestion des droits. « Masquer » et « verrouiller » sont deux choses différentes, et une seule des deux tient.

Deux pièges quand plusieurs personnes gèrent le site

Le premier : qui peut attribuer des droits peut s'en donner davantage. WordPress prévoit pour cela un garde-fou — get_editable_roles() —, et un plugin qui le contourne ouvre précisément la voie qu'il est censé fermer.

Le second concerne les réseaux multisite : 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 — y compris ceux qui ne lui appartiennent pas.

Au départ d'un client

1. Désactiver l'accès, sans le supprimer tout de suite — sinon les articles perdent leur auteur.
2. Attribuer les articles à un autre compte avant la suppression.
3. Révoquer les mots de passe d'application de ce compte ; ils survivent à un changement de mot de passe.
4. Mettre fin aux sessions en cours.
5. Consigner dans le journal des modifications quand et pourquoi.

Questions fréquentes