web-dev-qa-db-fra.com

Avec Rest V2 (WP4.7), comment restreindre certains verbes RESTFUL?

Je vise à limiter certains verbes RESTUL par type de message personnalisé. Par exemple, étant donné le type de message personnalisé Vocabulary, je voudrais dire:

Matrice de permission 

+-------+---+----------+
|index  | X | GET      |
|show   | O | GET      |
|create | X | POST     |
|update | X | PATCH/PUT|
|delete | X | DELETE   |
+-------+---+----------+

La V2 ne semble pas fournir ce niveau de contrôle. J'ai parcouru la source et, d'après ce que je peux voir, il n'y a pas de crochets/filtres à exploiter pour modifier les autorisations.

Ma solution actuelle est la suivante. Cela compromet une classe où vous pouvez charger une matrice de types de publication personnalisés par rapport aux actions autorisées. Ceci peut ensuite être appelé dans le filtre rest_prepare_vocabulary, détruisant la réponse si les autorisations ne sont pas alignées.

Problème

Je ne pense pas que c'est une solution raisonnable. Cela signifie que les autorisations sont en cours de résolution à deux endroits (un, au cœur, car elles sont toujours appliquées) et dans mes filtres.

Idéalement, ce serait au niveau de la configuration, à savoir où les types de publication personnalisés sont définis.

En d'autres termes, je préférerais transmettre des règles (suivant les lignes exclude_from_search, publicly_queryable, etc.) plutôt que d'effectuer une requête de type "snip".

Solution actuelle (fonctionne mais pas souhaitable)

Access.php

class Access
{
    function __construct($permissions) {
        $this->permissions = $permissions;
    }

    protected function hasId($request) {
        return ! is_null($request->get_param('id'));
    }

    protected function resolveType($request) {
        $method = strtoupper($request->get_method());

        if($method === 'GET' && $this->hasId($request)) {
            return 'show';
        } else if($method === 'GET') {
            return 'index';
        } else if($method === 'DELETE') {
            return 'delete';
        } else if($method === 'POST') {
            return 'create';
        } else if($method === 'PATCH') {
            return 'update';
        }
    }

    function validate($type, $request) {
        return in_array($this->resolveType($request), $this->permissions[$type]);
    }
}

functions.php

// bootstrap the permissions for this particular 
// application
// 
$access = new Access([
    'vocabulary' => ['show'],
]);

add_filter('rest_prepare_vocabulary', 'validate_permissions', 30, 3);
function validate_permissions($response, $post, $request) {
    global $access;

    // Give access->validate the type + request data 
    // and it will figure out if this is allowed
    //
    if( ! $access->validate($post->post_type, $request)) {
        $response->set_data([]);
        $response->set_status(403);
    }

    return $response;
};
custom-post-typespermissionsuser-accessrest-apirestful
20
Chris

J'ai parcouru la source et, d'après ce que je peux voir, il n'y a pas de crochets/filtres à exploiter pour modifier les autorisations.

D'après ce que j'ai compris, il s'agissait d'une décision de conception intentionnelle.

Bien que l'API REST ait été conçue pour être extensible, il n'est pas recommandé de modifier les noeuds finaux principaux de la manière que vous demandez.

Il existe quelques informations limitées disponibles dans cette section du manuel de l'API REST , mais l'essentiel est qu'au fur et à mesure que l'API vieillit, plus de code (qu'il s'agisse d'un noyau ou d'un tiers) va commencer dépendre d'actions spécifiques disponibles et fournissant des réponses standard.

Au lieu de cela, vous devez créer un contrôleur personnalisé.

Il est possible d'attribuer un contrôleur personnalisé aux types de publication personnalisés en spécifiant un nom de classe dans l'argument rest_controller_class À register_post_type() .

Vous trouverez un aperçu du fonctionnement des contrôleurs personnalisés dans le manuel de l'API REST _ .

Il faut aussi garder à l'esprit que si vous créez un contrôleur personnalisé qui étend la classe abstraite WP_REST_Controller pour un type de publication prenant en charge les révisions, un certain nombre de points de terminaison de révision spécifiques à un type de publication seront automatiquement créés.

Si la classe WP_REST_Controller n'est pas étendue, la méthode register_routes() n'est pas appelée et vous devrez donc enregistrer manuellement vos itinéraires personnalisés.

1
ssnepenthe