WP REST API requiere contraseña para GET Endpoint

8

Tengo un tipo de publicación personalizada card, que expongo a través de la API WP REST. ¿Hay alguna forma de requerir autenticación, con cookie o encabezado de autenticación básica? Veo un argumento debajo del bloque de método POST para la contraseña, pero no estoy seguro de cómo usarlo.

rest-api

— YarGnawh
fuente

9

Cuando registramos una ruta de descanso con register_rest_route(), podemos usar el permission_callbackparámetro con el tipo de permiso que queramos.

Compruebe, por ejemplo, cómo WP_REST_Posts_Controller::register_routes()e WP_REST_Users_Controller::register_routes()implementar la devolución de llamada de permiso.

El argumento de la contraseña al que te refieres es la contraseña del contenido, que puedes configurar para cada publicación y eso no es lo mismo.

Pero como desea orientar las rutas existentes, como:

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

podría intentar, por ejemplo, el rest_dispatch_requestfiltro para configurar su verificación de permisos adicionales para ese tipo de rutas.

Aquí hay un complemento de demostración:

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

donde apuntamos a las rutas /wp/v2/cardsy /wp/v2/cards/*GET, con verificaciones de permisos de usuario adicionales.

Al depurarlo con la autenticación de cookies de WordPress, por ejemplo, podemos probarlo directamente con:

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

donde se ha generado la parte nonce wp_create_nonce( 'wp_rest' );

¡Espero que esto ayude!

— Birgire
fuente

Traté de hacerlo general para una base objetivo determinada, pero ¿tal vez hay una manera más fácil de evitar esto? Agregué un ejemplo de capacidad como un comentario en línea @ MarkKaplun

— birgire

Tal vez sea aún más simple eliminar el punto final para un tipo de publicación personalizado determinado, con el register_post_type_argsfiltro y e, g, establecido $args['show_in_rest'] = is_user_logged_in();para un tipo de publicación determinado o basado en $args['rest_base']. No estoy seguro si eso es querido o recomendado ;-)

— birgire

3

El campo de "contraseña" que está viendo en realidad no es para la API REST, sino para la entrada Post. Las publicaciones individuales en WordPress pueden protegerse con contraseña, de modo que necesita la contraseña para ver su contenido.

Esta forma de contraseña posterior individual no es un mecanismo de contraseña seguro, es una contraseña compartida. La contraseña es la misma para todos los usuarios, y se almacena en la base de datos sin cifrar ni mostrar. Nunca fue pensado como un mecanismo seguro de ninguna manera, es un mecanismo simple para ocultar contenido de una manera simple.

Si desea utilizar este mecanismo con la API REST, entonces es posible. Por ejemplo, si el ID de la publicación individual es 123, se puede recuperar una publicación de esta manera:

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

Si esa publicación está protegida con contraseña, esta URL la recuperará:

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

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

Si necesita una autenticación más sólida basada en el usuario, WordPress ofrece una forma de hacer que las publicaciones sean "privadas". Esta configuración hace que las publicaciones solo sean visibles para las cuentas de usuario que tienen la capacidad "read_private_posts", que está limitada a las funciones de administrador y editor de forma predeterminada. (Nota: Privado solo hace que el contenido de la publicación sea privado, sus Títulos aún pueden estar expuestos).

Cuando crea un tipo de publicación personalizado, esta misma capacidad se asigna al plural de su tipo (usando plural_base). Por lo tanto, para un tipo de tarjetas de publicación, habría un permiso similar de "read_private_cards" disponible para que usted lo asigne a los roles de usuario si lo desea.

Ahora, la autenticación a nivel de usuario no está realmente integrada en la API REST. La autenticación estándar basada en cookies de WordPress funciona bien, sin embargo, la API no ofrece ninguna forma de obtener esa cookie. Lo aceptará si está presente, pero debe realizar el flujo de inicio de sesión normal para obtener dicha cookie. Si desea algún otro enfoque de autenticación, necesita un complemento para ello.

Existen cuatro de estos complementos. Estos son OAuth 1.0, Contraseñas de aplicación, JSON Web Tokens y un complemento de autenticación básica. Tenga en cuenta que la autenticación básica es más fácil, sin embargo, también es insegura y, por lo tanto, solo se recomienda para fines de prueba y desarrollo. No debe usarse en un servidor de producción en vivo.

Puede encontrar más información sobre estos complementos aquí:

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

— Otón
fuente