web-dev-qa-db-fra.com

Les rôles d'utilisateur personnalisés ont-ils des fonctionnalités par défaut?

Lors de l'ajout d'un nouveau rôle d'utilisateur avec add_role() , existe-t-il des fonctionnalités attribuées au rôle (ou autorisées par le rôle) par défaut?

Il est possible de créer un rôle sans définir de capacités. Aucune fonctionnalité ne sera simplement définie pour ce rôle dans la base de données. Toutefois, vous pouvez refuser explicitement des fonctionnalités en leur attribuant la valeur false lors de la création du rôle.

$ capacités
(tableau) (Facultatif) Liste des capacités, par exemple. array ('edit_posts' => true, 'delete_posts' => false);

J'ai vu des exemples de cela, mais je me demande pourquoi cela serait nécessaire à moins que WordPress suppose qu'un rôle nouvellement créé dispose de certaines fonctionnalités jusqu'à ce que cela soit exclu.

Par exemple, tous les rôles sont-ils supposés avoir la capacité read à moins que la capacité ne soit explicitement exclue? Je peux utiliser get_role( $new_role )->capabilities; pour obtenir une liste de fonctionnalités explicitement définies, mais cela ne répond pas à ma question sur la manière dont WordPress gère les nouveaux rôles. Si aucune capacité n'est explicitement définie pour un nouveau rôle, cela retournera vide.

Dois-je exclure toutes les fonctionnalités pour lesquelles je ne souhaite pas qu'un rôle soit attribué ou WordPress présume-t-il que toutes les fonctionnalités sont fausses jusqu'à ce qu'elles soient définies comme étant vraies?

Edit: Cette question a été inspirée par un exemple sur le site du développeur, qui attribue la valeur false à une fonctionnalité lorsqu'un rôle est créé. Je ne vois pas pourquoi cela serait nécessaire.

$result = add_role(
    'guest_author',
    __( 'Guest Author', 'testdomain' ),
    array(
        'read'         => true,  // true allows this capability
        'edit_posts'   => true,
        'delete_posts' => false, // Use false to explicitly deny
    )
);
user-rolescapabilities
2
iyrin

J'ai constaté que la fonction WordPress has_cap(), qui est utilisée par des fonctions telles que user_can() et current_user_can, renvoie explicitement la valeur false pour les fonctionnalités vides.

Exemple: si une capacité est passée sous forme d'argument à l'aide de current_user_can() , cette fonction passera la capacité à has_cap() et renverra les résultats:

    return call_user_func_array( array( $current_user, 'has_cap' ), $args

has_cap() retournera false si la capacité demandée n'existe pas ou si la valeur est false:

foreach ( (array) $caps as $cap ) {
    if ( empty( $capabilities[ $cap ] ) )
        return false;
}

En effet, la fonction empty() renvoie true dans les deux cas.

Une variable est considérée comme vide si elle n’existe pas ou si sa valeur est égale à FALSE.

À moins que je ne me trompe sur le fonctionnement de ces fonctions, il semble alors prudent de dire que aucune fonctionnalité par défaut n'est attribuée à un nouveau rôle, sauf si explicitement défini sur true . Il n'est pas nécessaire de refuser explicitement une capacité lors de la création d'un nouveau rôle avec add_role() et je ne vois aucune raison de le faire. Si une capacité n'est pas répertoriée, l'utilisateur ne l'aura pas.

3
iyrin

Avec la valeur par défaut (tableau vide), aucune fonctionnalité n'a été ajoutée au rôle (pas même read) et ils ne peuvent pas accéder au tableau de bord.

alors, vous pouvez simplement créer le rôle avec ce code:

add_role("on_the_door", "User with no access");

vous pouvez utiliser ce plugin pour voir les capacités des rôles:
https://wordpress.org/plugins/user-role-editor/

1
mmm

C'est une façon trompeuse de voir comment fonctionnent les capacités de wordpress. En substance, aucune structure ne contient toutes les fonctionnalités, et tout se résume au développeur qui implémente des filtres pour la fonction has_cap. Il existe une structure de base pour les capacités de base, mais il s'agit vraiment d'un sous-ensemble de ce qui peut être fait.

Il existe un système par défaut pour le système de fonctionnalités: les administrateurs disposent de toutes les fonctionnalités et il n’existe aucune autre hypothèse concernant un autre utilisateur.

La discussion devrait donc porter sur des capacités spécifiques et non sur certains concepts généraux de capacités.

Désormais, lorsqu’on se concentre sur les capacités principales, la tradition veut que quelle que soit la valeur des capacités que le stockage évalue à false signifie que l’utilisateur n’a pas la capacité, le stockage vide devrait donc signifier qu’un utilisateur ne dispose les capacités pourraient ne pas dépendre de la structure de capacités de base).

Mais il est important de se rappeler que la fonctionnalité n'est qu'une API et que le code ne doit pas nécessairement être utilisé par l'API. Par conséquent, lorsque vous posez une question spécifique, "un utilisateur disposant de capacités vides aura-t-il une capacité de lecture", cela dépend de la caractéristique considèrent cette capacité. Par exemple, je peux voir que l'accès au tableau de bord peut être inconditionnel et que vous pouvez accéder à votre propre profil en étant activé par défaut. Plus extrême - presque aucun thème que je connaisse implémente une vérification de capacité avant d’accorder l’accès au contenu sur le front-end, c’est pourquoi il est tout simplement inutile de tripoter une capacité de style "lecture".

0
Mark Kaplun