Nascondere gli endpoint API REST WordPress v2 dalla visualizzazione pubblica


14

Vorrei iniziare a utilizzare l' API REST WordPress v2 per richiedere informazioni dal mio sito. Ho notato che quando visito direttamente un URL endpoint, posso vedere tutti i dati pubblicamente. Ho anche visto che molti tutorial menzionano l'uso di server di prova o locali piuttosto che di siti live.

Le mie domande sono:

  • Questo è pensato per essere utilizzato su siti in produzione?
  • Esiste un rischio per la sicurezza che consente agli utenti di visualizzare gli endpoint, ad esempio /wp-json/wp/v2/users/che mostra tutti gli utenti registrati al sito?
  • È possibile consentire solo agli utenti autorizzati di accedere a un endpoint?

Voglio assicurarmi di seguire le migliori pratiche in materia di sicurezza, quindi eventuali suggerimenti sarebbero utili. I documenti api menzionano l'autenticazione, ma non sono sicuro su come impedire l'accesso diretto all'URL. In che modo altri utenti configurano normalmente questi dati a cui possono accedere le applicazioni esterne senza esporre troppe informazioni?


1
La vera domanda è: stai usando il lato client degli endpoint (cioè nelle chiamate AJAX) o lato server (forse da un'altra applicazione)?
TheDeadMedic il

1
Nota: la versione più recente del plugin WordFence ha un'opzione per "Impedisci il rilevamento di nomi utente tramite scansioni '/? Author = N', l'API oEmbed e l'API REST WordPress"
squarecandy

Risposte:


18

Questo è pensato per essere utilizzato su siti in produzione?

Sì. Molti siti lo hanno già utilizzato .

Esiste un rischio per la sicurezza che consente agli endpoint di essere visualizzati da chiunque, come / wp-json / wp / v2 / users / che mostra tutti gli utenti registrati al sito?

No. Le risposte del server non hanno nulla a che fare con la sicurezza, cosa puoi fare con uno schermo vuoto / accesso in sola lettura? Niente!

Tuttavia, se i tuoi siti consentono password deboli, ci sono alcuni problemi . Ma è la politica dei tuoi siti, l'API REST non ne sa nulla.

È possibile consentire solo agli utenti autorizzati di accedere a un endpoint?

Sì. Puoi farlo utilizzando il callback delle autorizzazioni .

Per esempio:

if ( 'edit' === $request['context'] && ! current_user_can( 'list_users' ) ) {
    return new WP_Error( 'rest_forbidden_context', __( 'Sorry, you cannot view this resource with edit context.' ), array( 'status' => rest_authorization_required_code() ) );
}

In che modo altri utenti configurano normalmente l'accesso a questi dati da parte di applicazioni esterne senza esporre troppe informazioni?

È difficile rispondere a questa domanda perché non sappiamo cosa / quando siano troppe informazioni . Ma stiamo tutti usando riferimenti e cheatheet .


1
Importante notare: "L'esposizione si limita agli utenti che hanno creato tipi di post che sono impostati per essere esposti tramite l'API REST". - quindi, se hai detto, un negozio online in cui ogni cliente ha un utente, questi utenti non sono esposti tramite /wp-json/wp/v2/users/. (Riferimento wordpress.stackexchange.com/q/252328/41488 @JHoffmann comment)
squarecandy

Va notato che è necessario disporre di un nonce basato su REST wp_create_nonce ('wp_rest') nell'intestazione 'X-WP-Nonce', altrimenti nessuna di queste cose funzionerà affatto e restituirà sempre un 403.
Andrew Killen

5

È possibile consentire solo agli utenti autorizzati di accedere a un endpoint?

È possibile aggiungere un callback di autorizzazione personalizzato all'endpoint API che richiede l'autenticazione per visualizzare il contenuto. Gli utenti non autorizzati riceveranno una risposta di errore"code": "rest_forbidden"

Il modo più semplice per farlo è estendere WP_REST_Posts_Controller. Ecco un esempio molto semplice di ciò:

class My_Private_Posts_Controller extends WP_REST_Posts_Controller {

   /**
   * The namespace.
   *
   * @var string
   */
   protected $namespace;

   /**
   * The post type for the current object.
   *
   * @var string
   */
   protected $post_type;

   /**
   * Rest base for the current object.
   *
   * @var string
   */
   protected $rest_base;

  /**
   * Register the routes for the objects of the controller.
   * Nearly the same as WP_REST_Posts_Controller::register_routes(), but with a 
   * custom permission callback.
   */
  public function register_routes() {
    register_rest_route( $this->namespace, '/' . $this->rest_base, array(
        array(
            'methods'             => WP_REST_Server::READABLE,
            'callback'            => array( $this, 'get_items' ),
            'permission_callback' => array( $this, 'get_items_permissions_check' ),
            'args'                => $this->get_collection_params(),
            'show_in_index'       => true,
        ),
        array(
            'methods'             => WP_REST_Server::CREATABLE,
            'callback'            => array( $this, 'create_item' ),
            'permission_callback' => array( $this, 'create_item_permissions_check' ),
            'args'                => $this->get_endpoint_args_for_item_schema( WP_REST_Server::CREATABLE ),
            'show_in_index'       => true,
        ),
        'schema' => array( $this, 'get_public_item_schema' ),
    ) );

    register_rest_route( $this->namespace, '/' . $this->rest_base . '/(?P<id>[\d]+)', array(
        array(
            'methods'             => WP_REST_Server::READABLE,
            'callback'            => array( $this, 'get_item' ),
            'permission_callback' => array( $this, 'get_item_permissions_check' ),
            'args'                => array(
                'context' => $this->get_context_param( array( 'default' => 'view' ) ),
            ),
            'show_in_index'       => true,
        ),
        array(
            'methods'             => WP_REST_Server::EDITABLE,
            'callback'            => array( $this, 'update_item' ),
            'permission_callback' => array( $this, 'update_item_permissions_check' ),
            'args'                => $this->get_endpoint_args_for_item_schema( WP_REST_Server::EDITABLE ),
            'show_in_index'       => true,
        ),
        array(
            'methods'             => WP_REST_Server::DELETABLE,
            'callback'            => array( $this, 'delete_item' ),
            'permission_callback' => array( $this, 'delete_item_permissions_check' ),
            'args'                => array(
                'force' => array(
                    'default'     => true,
                    'description' => __( 'Whether to bypass trash and force deletion.' ),
                ),
            ),
            'show_in_index'       => false,
        ),
        'schema' => array( $this, 'get_public_item_schema' ),
    ) );     
  }

  /**
   * Check if a given request has access to get items
   *
   * @param WP_REST_Request $request Full data about the request.
   * @return WP_Error|bool
   */
  public function get_items_permissions_check( $request ) {
    return current_user_can( 'edit_posts' );
  }

}

Noterai che il callback delle autorizzazioni function get_items_permissions_checkutilizza current_user_canper determinare se consentire l'accesso. A seconda di come stai usando l'API, potrebbe essere necessario saperne di più sull'autenticazione client.

È quindi possibile registrare il tipo di post personalizzato con il supporto API REST aggiungendo i seguenti argomenti in register_post_type

  /**
   * Register a book post type, with REST API support
   *
   * Based on example at: http://codex.wordpress.org/Function_Reference/register_post_type
   */
  add_action( 'init', 'my_book_cpt' );
  function my_book_cpt() {
    $labels = array(
        'name'               => _x( 'Books', 'post type general name', 'your-plugin-textdomain' ),
        'singular_name'      => _x( 'Book', 'post type singular name', 'your-plugin-textdomain' ),
        'menu_name'          => _x( 'Books', 'admin menu', 'your-plugin-textdomain' ),
        'name_admin_bar'     => _x( 'Book', 'add new on admin bar', 'your-plugin-textdomain' ),
        'add_new'            => _x( 'Add New', 'book', 'your-plugin-textdomain' ),
        'add_new_item'       => __( 'Add New Book', 'your-plugin-textdomain' ),
        'new_item'           => __( 'New Book', 'your-plugin-textdomain' ),
        'edit_item'          => __( 'Edit Book', 'your-plugin-textdomain' ),
        'view_item'          => __( 'View Book', 'your-plugin-textdomain' ),
        'all_items'          => __( 'All Books', 'your-plugin-textdomain' ),
        'search_items'       => __( 'Search Books', 'your-plugin-textdomain' ),
        'parent_item_colon'  => __( 'Parent Books:', 'your-plugin-textdomain' ),
        'not_found'          => __( 'No books found.', 'your-plugin-textdomain' ),
        'not_found_in_trash' => __( 'No books found in Trash.', 'your-plugin-textdomain' )
    );

    $args = array(
        'labels'             => $labels,
        'description'        => __( 'Description.', 'your-plugin-textdomain' ),
        'public'             => true,
        'publicly_queryable' => true,
        'show_ui'            => true,
        'show_in_menu'       => true,
        'query_var'          => true,
        'rewrite'            => array( 'slug' => 'book' ),
        'capability_type'    => 'post',
        'has_archive'        => true,
        'hierarchical'       => false,
        'menu_position'      => null,
        'show_in_rest'       => true,
        'rest_base'          => 'books-api',
        'rest_controller_class' => 'My_Private_Posts_Controller',
        'supports'           => array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
    );

    register_post_type( 'book', $args );
}

Vedrai gli rest_controller_classusi My_Private_Posts_Controllerinvece del controller predefinito.

Ho avuto difficoltà a trovare buoni esempi e spiegazioni per l'utilizzo dell'API REST al di fuori della documentazione . Ho trovato questa grande spiegazione dell'estensione del controller predefinito ed ecco una guida molto completa per l'aggiunta di endpoint .


2

Ecco cosa ho usato per impedire a tutti gli utenti non registrati di utilizzare l'API REST:

add_filter( 'rest_api_init', 'rest_only_for_authorized_users', 99 );
function rest_only_for_authorized_users($wp_rest_server){
    if ( !is_user_logged_in() ) {
        wp_die('sorry you are not allowed to access this data','cheatin eh?',403);
    }
}

Man mano che l'uso dell'end point resterà in espansione, questo tipo di strategia diventerà problematica. Alla fine l'endpoint wp-json sostituirà quello admin-ajax, il che significa che ci saranno anche tutti i tipi di richieste legittime di front-end. Comunque, meglio morire con un 403 di qualcosa che potrebbe essere interpretato come contenuto.
Mark Kaplun il

@MarkKaplun - sì, hai ragione. Sto usando questo nel contesto di un sito che non offre praticamente alcun dato pubblico e i dati che stiamo memorizzando tra cui utenti, meta utente, dati di tipo post personalizzati, ecc. Sono dati proprietari a cui il pubblico non dovrebbe mai accedere . Fa schifo quando fai un sacco di lavoro all'interno della classica struttura del modello WP per assicurarti che alcuni dati siano privati ​​e poi ti rendi conto all'improvviso che sono tutti accessibili pubblicamente tramite l'API REST. Comunque, buon punto per servire un 403 ...
squarecandy il

0
add_filter( 'rest_api_init', 'rest_only_for_authorized_users', 99 );
function rest_only_for_authorized_users($wp_rest_server)
{
if( !is_user_logged_in() ) 

    wp_die('sorry you are not allowed to access this data','Require Authentication',403);
} } 
function json_authenticate_handler( $user ) {

global $wp_json_basic_auth_error;

$wp_json_basic_auth_error = null;

// Don't authenticate twice
if ( ! empty( $user ) ) {
    return $user;
}

if ( !isset( $_SERVER['PHP_AUTH_USER'] ) ) {
    return $user;
}

$username = $_SERVER['PHP_AUTH_USER'];
$password = $_SERVER['PHP_AUTH_PW'];


remove_filter( 'determine_current_user', 'json_authenticate_handler', 20 );

$user = wp_authenticate( $username, $password );

add_filter( 'determine_current_user', 'json_authenticate_handler', 20 );

if ( is_wp_error( $user ) ) {
    $wp_json_basic_auth_error = $user;
    return null;
}

$wp_json_basic_auth_error = true;

return $user->ID;}add_filter( 'determine_current_user', 'json_authenticate_handler', 20 );

1
Potresti elaborare nel testo perché e come questo risponde alle domande del PO?
Kero,

Questa non è la risposta di op e ho dato solo il codice per mostrare come lavorare praticamente e ho cercato di farti capire facilmente in modo programmatico Se lo capissi
dipen patel
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.