L'API REST WP richiede la password per GET Endpoint

8

Ho un tipo di post personalizzato card, che sto esponendo tramite l'API REST WP. Esiste un modo per richiedere l'autenticazione, con cookie o intestazione Auth di base? Vedo un argomento nel blocco del metodo POST per la password, ma non sono sicuro di come usarlo.

rest-api

— YarGnawh
fonte

9

Quando registriamo una rotta di riposo con register_rest_route(), allora possiamo usare il permission_callbackparametro con il tipo di autorizzazione che vogliamo.

Controllare ad esempio come WP_REST_Posts_Controller::register_routes()e WP_REST_Users_Controller::register_routes()implementare il callback delle autorizzazioni.

L'argomento password a cui ti riferisci è la password del contenuto, che puoi impostare per ogni post e non è la stessa.

Ma dal momento che vuoi scegliere come target percorsi esistenti, come:

/wp/v2/cards
/wp/v2/cards/(?P<id>[\d]+)
/wp/v2/cards/...possibly some other patterns...

potresti provare ad esempio il rest_dispatch_requestfiltro per impostare il controllo delle autorizzazioni aggiuntive per quel tipo di percorsi.

Ecco un plugin demo:

add_filter( 'rest_dispatch_request', function( $dispatch_result, $request, $route, $hndlr )
{
    $target_base = '/wp/v2/cards';    // Edit to your needs

    $pattern1 = untrailingslashit( $target_base ); // e.g. /wp/v2/cards
    $pattern2 = trailingslashit( $target_base );   // e.g. /wp/v2/cards/

    // Target only /wp/v2/cards and /wp/v2/cards/*
    if( $pattern1 !== $route && $pattern2 !== substr( $route, 0, strlen( $pattern2 ) ) )
        return $dispatch_result;

    // Additional permission check
    if( is_user_logged_in() )  // or e.g. current_user_can( 'manage_options' )
        return $dispatch_result;

    // Target GET method
    if( WP_REST_Server::READABLE !== $request->get_method() ) 
        return $dispatch_result;

    return new \WP_Error( 
        'rest_forbidden', 
        esc_html__( 'Sorry, you are not allowed to do that.', 'wpse' ), 
        [ 'status' => 403 ] 
    );

}, 10, 4 );

dove targetizziamo i percorsi /wp/v2/cardse /wp/v2/cards/*GET, con ulteriori controlli di autorizzazione dell'utente.

Quando eseguiamo il debug con l'autenticazione dei cookie di WordPress, possiamo ad esempio testarlo direttamente con:

https://example.tld/wp-json/wp/v2/cards?_wpnonce=9467a0bf9c

da dove è stata generata la parte nonce wp_create_nonce( 'wp_rest' );

Spero che sia di aiuto!

— birgire
fonte

Ho provato a renderlo generale per una data base target, ma forse c'è un modo più semplice per aggirare questo? Ho aggiunto un esempio di funzionalità come commento in linea @MarkKaplun

— birgire

Forse è ancora più semplice rimuovere l'endpoint per un determinato tipo di post personalizzato, con il register_post_type_argsfiltro ed e, g, impostato $args['show_in_rest'] = is_user_logged_in();per un determinato tipo di post o basato su $args['rest_base']. Non sono sicuro che sia voluto o raccomandato ;-)

— birgire

3

Il campo "password" che stai vedendo non è in realtà per l'API REST, ma per la voce Posta stessa. I singoli post in WordPress possono essere protetti con password in modo tale che sia necessaria la password per vederne il contenuto.

Questa forma di post-password individuale non è un meccanismo di password sicuro, è una password condivisa. La password è uguale per tutti gli utenti ed è memorizzata nel database senza crittografia e senza hash. Non è mai stato inteso come un meccanismo sicuro in alcun modo, è un semplice meccanismo per nascondere i contenuti in modo semplice.

Se si desidera utilizzare questo meccanismo con l'API REST, è possibile. Ad esempio, se l'ID del singolo post è 123, è possibile recuperare un post in questo modo:

http://example.com/wp-json/wp/v2/posts/123

Se quel post è protetto da password, questo URL lo recupererà:

http://example.com/wp-json/wp/v2/posts/123?password=example-pass

Riferimento: https://developer.wordpress.org/rest-api/reference/posts/#retrieve-a-post

Se hai bisogno di un'autenticazione più forte, basata sull'utente, WordPress offre invece un modo per rendere i post "privati". Questa impostazione rende i post visibili solo agli account utente che dispongono della funzionalità "read_private_posts", che per impostazione predefinita è limitata ai ruoli di amministratore ed editor. (Nota: Private rende solo i contenuti dei post privati, i loro Titoli possono ancora essere esposti.)

Quando crei un tipo di post personalizzato, questa stessa funzionalità viene mappata al plurale del tuo tipo (usando plural_base). Quindi, per un tipo di post di carte, ci sarebbe un'autorizzazione simile "read_private_cards" disponibile da assegnare ai ruoli utente se lo si desidera.

Ora, l'autenticazione a livello di utente non è effettivamente integrata nell'API REST. L'autorizzazione standard basata su cookie di WordPress funziona correttamente, tuttavia l'API non offre alcun modo per ottenere quel cookie. Lo accetterà se è presente, ma devi ottenere il normale flusso di accesso per ottenere un tale cookie. Se si desidera un altro approccio di autenticazione, è necessario un plug-in per questo.

Esistono quattro plug-in di questo tipo. Questi sono OAuth 1.0, password delle applicazioni, token Web JSON e un plug-in di autenticazione di base. Si noti che l'autenticazione di base è la più semplice, tuttavia è anche insicura e pertanto consigliata solo a scopo di test e sviluppo. Non deve essere utilizzato su un server di produzione live.

Puoi trovare maggiori informazioni su questi plugin qui:

https://developer.wordpress.org/rest-api/using-the-rest-api/authentication/#authentication-plugins

— Otto
fonte