Отображение конечной точки пользовательского типа записи в REST API только при наличии прав у пользователя

20 февр. 2017 г., 19:31:08
Просмотры: 2.57K
Голосов: 4

Я создал пользовательский тип записи для WordPress, который должен быть доступен только пользователям с кастомной возможностью read_cpt. В шаблонах и через pre_get_posts я могу проверять права через current_user_can() для включения или исключения CPT.

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

Единственный способ, который я нашел для скрытия конечных точек в API — это использование следующего кода.

Регистрация типа записи для "классического" WordPress:

function add_post_type() {
    $args = array(
        [...]
        'public'                => false,
        'has_archive'           => false,
        'exclude_from_search'   => true,
        'publicly_queryable'    => false,
        'show_in_rest'          => false,
    );
    register_post_type( 'cpt', $args );
}
add_action( 'init', 'add_post_type', 0 );

и отдельное добавление в REST API:

add_action( 'init', 'cpt_rest_support', 25 );
function cpt_rest_support() {
    global $wp_post_types;

    if ( current_user_can( 'read_addresses' ) ) {
        // убедитесь, что установлено правильное имя вашего типа записи!
        $post_type_name = 'address';
        if( isset( $wp_post_types[ 'cpt' ] ) ) {
            $wp_post_types[ 'cpt' ]->show_in_rest = true;
        }
    }
}

При создании кастомного класса WP_REST_Posts_Controller я не нашел способа скрыть конечную точку путем модификации любых *_permissions_check методов.

Существует ли что-то вроде аргумента "show_in_rest_permition_check" для register_post_type() или описанный способ — единственный вариант?

0
Все ответы на вопрос 4
0

У REST API нет параметров или вариантов для решения этой проблемы — по моему мнению. Однако регистрацию следует выполнять только если у пользователя есть соответствующие права в его роли, как показано в следующем примере.

add_action( 'rest_api_init', function() {

    // Выход, если у текущего пользователя недостаточно прав.
    if ( ! current_user_can( 'edit_posts' ) ) {
        return;
    }

    // Регистрация метаданных.
    register_meta( 'post', 'foo', array(
        'show_in_rest' => true,
    ));
});

Это позволит передавать пользовательские данные в REST API только если у пользователя достаточно прав и возможностей в его роли. Мой пример с register_meta() — всего лишь иллюстрация, и он должен работать так же с вашим дополнительным параметром для register_post_type, например: $wp_post_types[ 'cpt' ]->show_in_rest = true;.

20 февр. 2017 г. 22:25:34
0

Старый вопрос, но это сработало для меня, следуя требованиям @Drivingralle. Вы можете использовать current_user_can() как булевый переключатель для изменения поведения параметра show_in_rest:

function add_post_type() {

    $show_in_rest = current_user_can( 'read_cpt' ); //это вернет true или false

    $args = array(
        [...]
        'public'                => false,
        'has_archive'           => false,
        'exclude_from_search'   => true,
        'publicly_queryable'    => false,
        'show_in_rest'          => $show_in_rest, //булевый переключатель из current_user_can()
    );
    register_post_type( 'cpt', $args );
}
add_action( 'init', 'add_post_type' );

Таким образом, пользовательский тип записи будет отображаться в REST только для пользователей с требуемыми правами.

22 сент. 2021 г. 15:23:53
0

Не полагайтесь только на скрытие.

Вместо этого возвращайте ошибку в обработчике:

if (!current_user_can('read_addresses')) {
    return new WP_REST_Response('restricted', 403);
}

Чтобы также скрыть это, фильтруйте содержимое хуков rest_index и rest_namespace_index.

12 нояб. 2019 г. 08:55:04
0

Используйте функцию register_rest_route().

if( current_user_can( 'read_addresses' ) ) {
    register_rest_route( 'namespace/v1', 'cpt', array(
        'methods' => array( 'GET' ),
        'callback' => 'callback_function',
        'permission_callback' => 'permission_callback_function'
    ) );
}

Ваша функция callback_function будет обрабатывать запрос и возвращать ответ. Функция permissions_callback_function проверит права пользователя и вернет ошибку, если у пользователя нет указанных возможностей. В данном случае проверка прав, вероятно, не обязательна, но наличие этой функции не помешает.

12 нояб. 2019 г. 19:01:35