Con Rest V2 (WP4.7) come si restringono alcuni verbi RESTFUL?


20

Sto mirando a limitare alcuni verbi RESTUL per tipo di post personalizzato. Ad esempio, dato un tipo di post personalizzato Vocabolario, vorrei dire:

Matrice di autorizzazione

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

Il V2 non sembra fornire quel livello di controllo. Ho esaminato la fonte e, da quello che posso vedere, non ci sono hook / filtri da utilizzare per modificare le autorizzazioni.

La mia attuale soluzione è la seguente. Compromette una classe in cui è possibile caricare una matrice di tipi di post personalizzati rispetto alle azioni consentite. Questo può quindi essere chiamato nel rest_prepare_vocabularyfiltro, distruggendo la risposta se le autorizzazioni non si allineano.

Problema

Non mi sembra che questa sia una soluzione ragionevole. Significa che le autorizzazioni sono state risolte in due punti (uno, nel nucleo, poiché sono ancora applicati) e nei miei filtri.

Idealmente, sarebbe a livello di configurazione, ovvero dove sono definiti i tipi di posta personalizzati.

In altre parole, io preferirei passare nelle regole (lungo le linee di exclude_from_search, publicly_queryableecc) piuttosto che l'esecuzione di una query post "snip".

Soluzione attuale (funziona ma non desiderabile)

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;
};

1
Perché hai creato un'istanza Accessnell'ambito globale? Ne hai bisogno altrove? Nel caso in cui tu risponda con , potresti invece collegarlo a un filtro.
Kaiser

3
Domanda giusta - Quanto sopra è solo uno snippet, sto usando il compositore e il caricamento automatico PSR4 per disegnare i moduli di classe in una classe App principale, di cui lo snippet sopra sarebbe inserito - quindi non è in realtà globale globale, sarebbe spaziato in \Appe l'accesso è in realtà\App\Services\Access
Chris

1
Non ho esaminato questo problema da solo, ma hai controllato Trac per un biglietto o ne hai creato uno se non esiste? Sembra una caratteristica ragionevole avere ...
Kraftner,

1
Non capisco davvero il problema. "Significa che i permessi vengono risolti in due punti (uno, nel nocciolo, poiché sono ancora applicati) e nei miei filtri. Idealmente, sarebbe a livello di configurazione, in particolare dove vengono definiti i tipi di post personalizzati." Puoi forse chiarire cosa intendi qui? Scusa se sono stupido!
Jim Maguire,

2
Sto sottovalutando questa domanda. Non capisco perché 18 persone lo abbiano votato. È incomprensibile.
Jim Maguire,

Risposte:


1

Ho esaminato la fonte e, da quello che posso vedere, non ci sono hook / filtri da utilizzare per modificare le autorizzazioni.

La mia comprensione è che questa è stata una decisione di progettazione intenzionale.

Mentre l'API REST è stata creata per essere estensibile, non è consigliabile modificare gli endpoint di base nel modo richiesto.

Ci sono alcune informazioni limitate disponibili in questa sezione del manuale dell'API REST , ma l'essenziale è che con il passare dell'API, più codice (sia esso core o di terze parti) inizierà a dipendere da azioni specifiche disponibili e che forniscono standard risposte.

Invece dovresti creare un controller personalizzato.

Ai tipi di posta personalizzati può essere assegnato un controller personalizzato specificando un nome di classe rest_controller_classnell'argomentoregister_post_type() .

Una panoramica del funzionamento dei controller personalizzati può essere trovata nel manuale dell'API REST .

Un'altra cosa da tenere a mente è che se si crea un controller personalizzato che estende la WP_REST_Controllerclasse astratta per un tipo di post che supporta le revisioni, verranno automaticamente creati numerosi endpoint di revisione specifici del tipo di post.

Se non estende la WP_REST_Controllerclasse, il register_routes()metodo non viene chiamato, quindi dovrai registrare manualmente i tuoi percorsi personalizzati.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.