Un agent capable de publier un article ne devrait pas nécessairement pouvoir modifier une page de mentions légales, même si les deux actions relèvent techniquement de la même capacité edit_posts côté WordPress. C’est exactement ce qui s’est produit sur un test que nous avons mené avec une version en développement de l’Abilities API : l’ability de publication, bornée par cette seule capacité, autorisait de fait bien plus que ce qui était prévu.
Ce constat pointe une limite structurelle du système de capacités hérité de WordPress, pensé à l’origine pour distinguer des rôles humains — auteur, éditeur, administrateur — plutôt que pour borner précisément ce qu’une action automatisée, exécutée par un agent, a le droit de faire.
Ce que couvre réellement une capacité classique
La capacité edit_posts autorise la modification de tout contenu de type article, quelle que soit sa catégorie, son statut de publication ou son auteur d’origine. Un utilisateur disposant de cette capacité peut, en théorie, modifier n’importe quel article du site, ce qui correspond à l’intention initiale du système de rôles WordPress : distinguer des niveaux d’accès larges, pas des permissions granulaires par action.
Ce niveau de granularité convenait très bien pour distinguer un contributeur d’un éditeur. Il devient insuffisant dès qu’on veut dire précisément : « cet agent peut créer un brouillon dans la catégorie actualités, mais ne peut ni publier directement, ni toucher à une autre catégorie ».
Le décalage observé sur notre test
Sur notre projet de test, l’ability de publication d’article s’appuyait sur une vérification de la capacité edit_posts avant d’exécuter l’action. Cette vérification, correcte du point de vue de WordPress, ne distinguait pas la catégorie ciblée ni le statut de publication demandé. L’agent, en théorie limité à la rédaction de brouillons dans une catégorie précise, aurait techniquement pu publier directement un article dans n’importe quelle autre catégorie, la vérification de capacité ne portant que sur le type d’action, pas sur son périmètre exact.
- Une capacité vérifie un type d’action, pas son périmètre précis
- La catégorie ou la taxonomie ciblée n’entre pas dans la vérification de capacité classique
- Le statut de publication demandé — brouillon ou publié directement — n’est pas non plus couvert
- Une ability mal bornée hérite silencieusement de toute la largeur de la capacité sous-jacente
Construire un périmètre plus fin au-dessus de la capacité
La correction a consisté à ajouter, dans le callback de l’ability elle-même, une vérification supplémentaire portant sur la catégorie ciblée et sur le statut demandé, en complément — et non en remplacement — de la vérification de capacité fournie par WordPress.
function wpm_ability_publier_brouillon( array $arguments ) {
if ( ! current_user_can( 'edit_posts' ) ) {
return new WP_Error( 'capacite_absente', 'Capacite edit_posts requise.' );
}
$categories_autorisees = array( 'actualites' );
if ( ! in_array( $arguments['categorie'], $categories_autorisees, true ) ) {
return new WP_Error( 'categorie_non_autorisee', 'Categorie hors perimetre autorise pour cet agent.' );
}
// La publication directe reste interdite : le statut est force a brouillon
$arguments['statut'] = 'draft';
return wpm_creer_article( $arguments );
}Cette double vérification — capacité WordPress d’un côté, périmètre métier explicite de l’autre — reste, à ce stade de développement de l’Abilities API, une responsabilité du code applicatif plutôt qu’une fonctionnalité fournie nativement par l’API elle-même.
Ce que l’Abilities API ne résout pas encore
Au moment où nous testons cette API encore en développement, aucun mécanisme natif ne permet de déclarer, au niveau de l’ability elle-même, un périmètre aussi fin qu’une catégorie précise ou un statut de publication autorisé. Cette granularité reste à construire dans le code du callback, comme nous l’avons fait, tant que l’API n’a pas évolué sur ce point avant sa version stable.
Sur nos tests, une ability ne devrait jamais faire confiance à la seule capacité WordPress sous-jacente : elle doit vérifier elle-même le périmètre exact de l’action demandée.
Une vigilance à maintenir avant la sortie stable
Cette API étant amenée à évoluer avant son intégration officielle dans une version stable de WordPress, la façon de déclarer un périmètre fin pourrait changer. Ce qui ne devrait pas changer, en revanche, c’est la nécessité de vérifier ce périmètre quelque part dans le code, que ce soit dans le callback ou dans une couche à venir de l’API elle-même.
En résumé
Une capacité WordPress classique reste trop large pour borner précisément ce qu’une ability autorise réellement. Tant que l’Abilities API ne propose pas nativement cette granularité, la vérification du périmètre exact — catégorie, statut, portée de l’action — reste à la charge du développeur qui écrit le callback.
