Скрытие конечных точек WordPress REST API v2 от публичного просмотра

14

Я хотел бы начать использовать WordPress REST API v2 для запроса информации с моего сайта. Я заметил, что когда я посещаю URL-адрес конечной точки напрямую, я могу видеть все данные публично. Я также видел, что во многих руководствах упоминается использование тестовых или локальных серверов, а не живых сайтов.

Мои вопросы:

  • Это предназначено для использования на сайтах в производстве?
  • Существует ли угроза безопасности для разрешения просмотра конечных точек кем-либо, например, когда /wp-json/wp/v2/users/отображаются все пользователи, зарегистрированные на сайте?
  • Можно ли разрешить только авторизованным пользователям доступ к конечной точке?

Я хочу убедиться, что я следую рекомендациям по безопасности, поэтому любые советы будут полезны. В документации API упоминается аутентификация, но я не уверен, как предотвратить прямой доступ к URL. Как другие обычно настраивают доступ к этим данным для внешних приложений, не раскрывая слишком много информации?

Морган
источник
1
Реальный вопрос в том, используете ли вы конечную точку на стороне клиента (т.е. в вызовах AJAX) или на стороне сервера (возможно, из другого приложения)?
TheDeadMedic
1
Примечание. В самой последней версии плагина WordFence есть опция «Запретить обнаружение имен пользователей с помощью сканирования / / author = N», API oEmbed и API REST WordPress »
squarecandy

Ответы:

18

Это предназначено для использования на сайтах в производстве?

Да. Многие сайты уже используют его .

Существует ли угроза безопасности, позволяющая кому-либо просматривать конечные точки, например / wp-json / wp / v2 / users /, где отображаются все пользователи, зарегистрированные на сайте?

Нет. Ответы сервера не имеют ничего общего с безопасностью, что вы можете сделать с пустым экраном / доступом только для чтения? Ничего!

Однако, если на ваших сайтах разрешены слабые пароли, возникают некоторые проблемы . Но это политика ваших сайтов, REST API ничего об этом не знает.

Можно ли разрешить только авторизованным пользователям доступ к конечной точке?

Да. Вы можете сделать это с помощью разрешения обратного вызова .

Например:

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

Как другие обычно настраивают доступ к этим данным для внешних приложений, не раскрывая слишком много информации?

На этот вопрос сложно ответить, потому что мы не знаем, что / когда слишком много информации . Но мы все используем ссылки и читы .

MinhTri
источник
1
Важно отметить: «Экспозиция ограничивается пользователями, у которых есть авторские типы постов, которые выставляются для показа через REST API». - так что, если вы говорите, интернет-магазин, где у каждого покупателя есть пользователь, эти пользователи не открываются через /wp-json/wp/v2/users/. (Ссылка wordpress.stackexchange.com/q/252328/41488 @JHoffmann comment)
squarecandy
Следует отметить, что в заголовке «X-WP-Nonce» вам нужно иметь nonce wp_create_nonce ('wp_rest') на основе REST, иначе ни один из этих компонентов не будет работать вообще и всегда будет возвращать 403.
Эндрю Киллен
5

Можно ли разрешить только авторизованным пользователям доступ к конечной точке?

Можно добавить настраиваемый обратный вызов разрешений для вашей конечной точки API, который требует проверки подлинности для просмотра содержимого. Неавторизованные пользователи получат ответ об ошибке"code": "rest_forbidden"

Самый простой способ сделать это - расширить WP_REST_Posts_Controller. Вот очень простой пример этого:

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

}

Вы заметите, что обратный вызов разрешений function get_items_permissions_checkиспользует, current_user_canчтобы определить, разрешить ли доступ. В зависимости от того, как вы используете API, вам может потребоваться больше узнать об аутентификации клиента.

Затем вы можете зарегистрировать свой собственный тип записи с поддержкой REST API, добавив следующие аргументы в 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 );
}

Вы увидите rest_controller_classиспользование My_Private_Posts_Controllerвместо контроллера по умолчанию.

Мне было трудно найти хорошие примеры и объяснения для использования REST API вне документации . Я нашел это отличное объяснение расширения контроллера по умолчанию , и вот очень подробное руководство по добавлению конечных точек .

Dalton
источник
2

Вот то, что я использовал, чтобы заблокировать всех незарегистрированных пользователей от использования REST API:

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
источник
Поскольку использование конечной точки отдыха будет расширяться, такая стратегия станет проблематичной. В конце конечная точка wp-json заменит точку admin-ajax, что означает, что будут также все виды законных запросов переднего плана. Во всяком случае, лучше умереть с 403, чем то, что может быть истолковано как содержание.
Марк Каплун
@MarkKaplun - да, вы правы в этом. Я использую это в контексте сайта, который вообще не предлагает общедоступных данных, и данные, которые мы храним, включая пользователей, метаданные пользователей, данные пользовательских типов записей и т. Д., Являются частными данными, доступ к которым никогда не должен быть открыт для публики. , Это ужасно, когда вы выполняете кучу работы в классической структуре шаблона WP, чтобы убедиться, что определенные данные являются частными, а затем внезапно понимаете, что все это доступно публично через API REST. В любом случае, хорошая
идея
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
Не могли бы вы уточнить в тексте, почему и как это отвечает на вопросы ОП?
Kero
Это не ответ опа, и я дал только код, чтобы показать, как работать на практике, и я постарался, чтобы вы были легко поняты программно. Если вы это поняли
dipen patel