Ukrywanie punktów końcowych interfejsu API REST WordPress v2 przed publicznym wyświetlaniem

15

Chciałbym zacząć korzystać z WordPress REST API v2 do wyszukiwania informacji z mojej witryny. Zauważyłem, że kiedy odwiedzam bezpośrednio punkt końcowy, widzę wszystkie dane publicznie. Widziałem również, że wiele samouczków wspomina o użyciu serwerów testowych lub lokalnych zamiast o witrynach na żywo.

Moje pytania to:

  • Czy to ma być stosowane na stronach w produkcji?
  • Czy istnieje ryzyko związane z bezpieczeństwem zezwalające na wyświetlanie punktów końcowych przez kogokolwiek, na przykład przez /wp-json/wp/v2/users/które wyświetlają się wszyscy użytkownicy zarejestrowani w witrynie?
  • Czy można zezwolić tylko autoryzowanym użytkownikom na dostęp do punktu końcowego?

Chcę się upewnić, że przestrzegam najlepszych praktyk dotyczących bezpieczeństwa, więc wszelkie wskazówki byłyby pomocne. Dokumenty API wspominają o uwierzytelnianiu, ale nie jestem pewien, jak uniemożliwić bezpośredni dostęp do adresu URL. W jaki sposób inni zazwyczaj konfigurują dostęp do tych danych przez aplikacje zewnętrzne bez ujawniania zbyt dużej ilości informacji?

Morgan
źródło
1
Prawdziwe pytanie brzmi: czy używasz punktów końcowych po stronie klienta (tj. W wywołaniach AJAX), czy po stronie serwera (być może z innej aplikacji)?
TheDeadMedic
1
Uwaga: najnowsza wersja wtyczki WordFence ma opcję „Zapobiegaj wykrywaniu nazw użytkowników poprzez skanowanie„ /? Autor = N ”, oEmbed API i WordPress REST API”
squarecandy 11.01.2018

Odpowiedzi:

18

Czy to ma być stosowane na stronach w produkcji?

Tak. Wiele stron już z niego korzysta .

Czy istnieje zagrożenie bezpieczeństwa zezwalające na przeglądanie punktów końcowych przez kogokolwiek, na przykład / wp-json / wp / v2 / users /, który pokazuje wszystkich użytkowników zarejestrowanych w serwisie?

Nie. Odpowiedzi serwera nie mają nic wspólnego z bezpieczeństwem. Co możesz zrobić z pustym ekranem / dostępem tylko do odczytu? Nic!

Jeśli jednak witryny dopuszczają słabe hasła, występują pewne problemy . Ale to polityka twoich witryn, API REST nic o tym nie wie.

Czy można zezwolić tylko autoryzowanym użytkownikom na dostęp do punktu końcowego?

Tak. Możesz to zrobić za pomocą wywołania zwrotnego uprawnień .

Na przykład:

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

W jaki sposób inni zazwyczaj konfigurują dostęp do tych danych przez aplikacje zewnętrzne bez ujawniania zbyt dużej ilości informacji?

Trudno odpowiedzieć na to pytanie, ponieważ nie wiemy, co / kiedy jest za dużo informacji . Ale wszyscy używamy referencji i ściągów .

MinhTri
źródło
1
Ważne, aby pamiętać: „Narażenie ogranicza się do użytkowników, którzy są autorami typów postów, które mają być udostępniane za pośrednictwem interfejsu API REST”. - więc jeśli powiesz, sklep internetowy, w którym każdy klient ma użytkownika, użytkownicy ci nie są narażeni za pośrednictwem /wp-json/wp/v2/users/. (Odnośnik wordpress.stackexchange.com/q/252328/41488 @JHoffmann komentarz)
squarecandy
Należy zauważyć, że w nagłówku „X-WP-Nonce” musisz mieć nonce opartą na REST wp_create_nonce („wp_rest”), w przeciwnym razie żadna z tych rzeczy w ogóle nie będzie działać i zawsze zwróci 403.
Andrew Killen
5

Czy można zezwolić tylko autoryzowanym użytkownikom na dostęp do punktu końcowego?

Możliwe jest dodanie niestandardowego wywołania zwrotnego uprawnień do punktu końcowego interfejsu API, który wymaga uwierzytelnienia w celu wyświetlenia zawartości. Nieautoryzowani użytkownicy otrzymają odpowiedź na błąd"code": "rest_forbidden"

Najprostszym sposobem na to jest rozszerzenie WP_REST_Posts_Controller. Oto bardzo prosty przykład:

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

}

Zauważysz, że funkcja zwrotna uprawnień function get_items_permissions_checkużywa current_user_cando ustalenia, czy zezwolić na dostęp. W zależności od sposobu korzystania z interfejsu API może być konieczne uzyskanie dodatkowych informacji na temat uwierzytelniania klienta.

Następnie możesz zarejestrować swój niestandardowy typ postu za pomocą interfejsu API REST, dodając następujące argumenty 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 );
}

Zobaczysz rest_controller_classzastosowania My_Private_Posts_Controllerzamiast domyślnego kontrolera.

Trudno mi znaleźć dobre przykłady i wyjaśnienia dotyczące używania interfejsu API REST poza dokumentacją . Znalazłem to świetne wyjaśnienie rozszerzenia domyślnego kontrolera , a oto bardzo dokładny przewodnik po dodawaniu punktów końcowych .

Dalton
źródło
2

Oto, czego użyłem, aby w ogóle zablokować wszystkim niezalogowanym użytkownikom korzystanie z interfejsu 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);
    }
}
Squarecandy
źródło
W miarę rozszerzania się wykorzystania końcowego punktu końcowego, tego rodzaju strategia stanie się problematyczna. W końcu punkt końcowy wp-json zastąpi punkt admin-ajax jeden, co oznacza, że ​​pojawią się również wszelkiego rodzaju uzasadnione żądania frontonu. W każdym razie lepiej umrzeć z 403 niż czymś, co można interpretować jako treść.
Mark Kaplun,
@MarkKaplun - tak, masz rację. Używam tego w kontekście witryny, która zasadniczo nie oferuje żadnych danych publicznych, a dane, które przechowujemy, w tym dane użytkowników, meta użytkowników, niestandardowe dane typu postu itp. Są zastrzeżonymi danymi, do których publicznie nie powinni mieć dostępu . Jest to do bani, gdy wykonujesz wiele pracy w klasycznej strukturze szablonów WP, aby upewnić się, że pewne dane są prywatne, a następnie nagle uświadomić sobie, że wszystkie są publicznie dostępne za pośrednictwem interfejsu API REST. W każdym razie, dobry punkt na temat serwowania 403 ...
squarecandy
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 );
dipen patel
źródło
1
Czy mógłbyś wyjaśnić w tekście, dlaczego i jak to odpowiada na pytania PO?
kero
To nie jest odpowiedź op. Dałem tylko kod, aby pokazać, jak praktycznie pracować, i starałem się, abyś zrozumiał programowo. Jeśli to rozumiesz
dipen patel