Share
En la parte anterior de la serie, configuramos la autenticación HTTP básica en el servidor instalando el complemento disponible en GitHub por el equipo de API REST de WP. El método de autenticación básica nos permite enviar solicitudes autenticadas mediante el envío de credenciales de inicio de sesión en el encabezado de la solicitud. Si bien es rápido y práctico, también existe la posibilidad de que estas credenciales caigan en las manos equivocadas. Por lo tanto, este método solo debe utilizarse en redes seguras con fines de desarrollo y prueba únicamente.
Para utilizar la autenticación en servidores de producción, debe haber una forma más segura de enviar solicitudes autenticadas sin correr el riesgo de exponer las credenciales de inicio de sesión. Gracias al método de autenticación OAuth, esas solicitudes pueden enviarse sin exponer el nombre de usuario y la contraseña de forma insegura.
En la parte actual de la serie, aprenderemos a configurar y utilizar el método de autenticación OAuth para usar con el complemento WP REST API. Para ser específicos, vamos a:
Comencemos por presentarnos al método de autenticación OAuth..
¿Qué hace cuando necesita iniciar sesión en su administrador de WordPress? Simplemente vaya a la página de inicio de sesión e ingrese sus credenciales de inicio de sesión, ¿verdad? ¡Así de simple! ¿Pero qué sucede si está utilizando un servicio de terceros que requiere acceso a sus recursos de WordPress (publicaciones, páginas, medios o cualquier otra cosa)? ¿Simplemente entregaría sus credenciales de inicio de sesión a ese servicio, sabiendo que podrían terminar en manos equivocadas cada vez que se comprometa la integridad de ese servicio? La respuesta probablemente sería "No"..
En el modelo tradicional de autenticación, hay dos roles:
Si un cliente desea acceder a los recursos protegidos, se autenticará al proporcionar las credenciales adecuadas al servidor y se le otorgará el acceso..
El problema surge cuando un servicio de terceros necesita acceso a estos recursos protegidos en el servidor. Este servicio no puede ser (y debería no ser) dadas credenciales por el usuario para acceder a los recursos. Proporcionar credenciales a un tercero significa otorgar el control completo sobre el recurso ubicado en el servidor.
Ahí es donde la metodología de autenticación OAuth viene al rescate. Introduce un nuevo rol en el proceso de autenticación, y es el propietario del recurso. Ahora hay tres roles en el proceso de autenticación:
Los tres roles anteriores juntos hacen lo que se denomina autenticación OAuth de tres patas. El número de patas define los roles involucrados en un proceso de autenticación. Cuando el propietario del recurso también es el cliente, el flujo se conoce como autenticación de dos patas.
Según Webopedia:
OAuth es un estándar de autorización abierto que se utiliza para proporcionar acceso seguro a las aplicaciones del cliente a los recursos del servidor. El marco de autorización de OAuth permite que una aplicación de terceros obtenga acceso limitado a un servicio HTTP, ya sea en nombre de un propietario del recurso o permitiendo que la aplicación de terceros obtenga acceso en su propio nombre.
OAuth permite a los propietarios de servidores autorizar el acceso a los recursos del servidor sin compartir credenciales. Esto significa que el usuario puede otorgar acceso a recursos privados de un servidor a otro recurso del servidor sin compartir su identidad.
Por lo tanto, en el flujo de autenticación de OAuth, el usuario no necesita exponer las credenciales, pero puede autorizar al cliente a actuar en su nombre, decidiendo a qué recursos puede acceder el cliente. En otras palabras, si bien no proporciona credenciales de inicio de sesión, el usuario también puede decidir el alcance del acceso que se le otorga al cliente.
Esto permite que no solo los sitios web, sino también las aplicaciones móviles y de escritorio obtengan acceso limitado a un recurso en un servidor.
En términos de WordPress, OAuth informa al proveedor de recursos (la instalación de WordPress) que el propietario del recurso (el usuario de WordPress) ha otorgado permiso para acceder a una aplicación de terceros para acceder a sus recursos. Estos recursos pueden ser publicaciones, páginas, taxonomía y medios, etc. Este permiso puede ser de acceso limitado o completo, como veremos más adelante en este tutorial..
La API de autenticación de OAuth para WordPress se basa en las especificaciones de OAuth 1.0a, por lo que analizaremos cómo funciona OAuth 1.0a.
OAuth funciona mediante el uso de credenciales de token emitidas por el proveedor de recursos (el servidor), a petición del propietario del recurso después de que se haya autenticado utilizando sus credenciales. Estos tokens, asociados con el propietario del recurso, son utilizados por el cliente (una aplicación o servicio de terceros) para obtener acceso a los recursos protegidos.
Estas credenciales de token tienen una duración limitada y el servidor puede revocarlas a petición del propietario del recurso..
El flujo de OAuth es el siguiente:
Accentsconagua
oauth_consumer_key: proporcionado por el servidoroauth_timestampoauth_nonceouth_signatureouth_signature_methodjuramentooauth_version (Opcional)oauth_tokenoauth_token_secretoauth_callback_confirmedoauth_token obtenido en el paso anterior al URI de punto final de Autorización del propietario del recurso.oauth_callback La URI se proporcionó en el primer paso, el servidor redirige al cliente a esa URI y agrega la siguiente cadena de consulta: oauth_token: obtenido en el segundo pasooauth_verifier: se utiliza para garantizar que el propietario del recurso que otorgó el acceso es el mismo que el clienteoauth_callback URI no se proporcionó en el primer paso, luego el servidor muestra el valor del oauth_verifier Para que el propietario del recurso pueda informar al cliente manualmente..oauth_verfier, el cliente solicita al servidor las credenciales del token enviando una solicitud al URI de punto final de solicitud de token. Esta solicitud contiene lo siguiente: oauth_token: obtenido en el segundo pasooauth_verfier: obtenido en el paso anterioroauth_consumer_key: proporcionado por el proveedor de recursos (el servidor), antes de iniciar el protocolo de intercambioouth_signatureouth_signature_methodoauth_nonceoauth_versionoauth_tokenoauth_token_secretLa información anterior puede ser transportada por una cadena de consulta anexada a la solicitud de URI o incluyéndola en la Autorización Encabezado, aunque este último es recomendado debido a una mejor seguridad..
Este es un proceso largo y debe tenerse en cuenta al desarrollar nuestros propios clientes para interactuar con la API. El propósito del cliente es administrar toda esta jerga y facilitar al usuario en el proceso de autenticación. Dado que usaremos un paquete provisto por el equipo de WP REST API, los detalles anteriores se extraerán y podremos obtener credenciales de token en un número mínimo de pasos.
En la discusión anterior, encontramos tres URI de punto final, a saber:
Estas URI son proporcionadas por el servidor de varias maneras. Una de estas formas es exponiéndolas en la respuesta del servidor al verificar la API. La API de autenticación OAuth para la API REST de WordPress utiliza el mismo método, como veremos en la siguiente sección.
Después de ver cómo funciona OAuth, nuestro siguiente paso es instalar y habilitar la API de autenticación de OAuth para WordPress..
La API de autenticación de OAuth para WordPress permite al servidor aceptar solicitudes autenticadas utilizando la implementación de OAuth. Está construido sobre las especificaciones de OAuth 1.0a y las amplía con un parámetro adicional-wp_scope-para ser enviado a la Solicitud de credencial temporal punto final los wp_scope El parámetro define el alcance del acceso que se otorga al cliente. Puede encontrar más información al respecto en la documentación oficial de GitHub..
El complemento está disponible en Github del equipo WP REST API y solo es compatible con la versión 4.4 o posterior de WordPress.
Vamos a clonar el plugin navegando a la / wp-content / plugins / directorio:
$ git clone https://github.com/WP-API/OAuth1.git
Una vez que se complete la descarga, active el complemento utilizando CLI de WP:
$ wp plugin active OAuth1
Alternativamente, también puede activarlo al navegar en su navegador a la sección de complementos de administración de WordPress si no desea usar la CLI de WP.
Esto es todo lo que se necesita para permitir que el servidor acepte OAuth como un método de autorización. Lo siguiente que debemos hacer es enviar una solicitud al servidor para verificar si la API de OAuth está lista para ser utilizada.
Antes de iniciar el intercambio de OAuth, primero debemos verificar si la API está habilitada en el servidor. Esto se hace enviando un simple OBTENER solicitud a la/ wp-json / punto final y luego analizar la respuesta enviada por el servidor.
Encienda su cliente HTTP y envíe una solicitud a / wp-json / punto final como sigue:
GET http: // su-dev-server / wp-json /
Esto devolverá una respuesta JSON de la siguiente manera:
Nuestro enfoque aquí es el oauth1 valor en el autenticación valor de propiedad. Este objeto tiene las siguientes propiedades definidas:
solicitud: el punto final de la solicitud de credencial temporalautorizar: el punto final de Autorización del propietario del recursoacceso: el punto final de la solicitud de tokenversión: la versión de OAuth en usoLos tres primeros son URL absolutas que encontramos al aprender sobre el mecanismo de OAuth en una sección anterior.
los oauth1 objeto definido en el autenticación el valor de la propiedad muestra que la API de OAuth se ha habilitado correctamente para nuestro sitio de WordPress y podemos comenzar a usarla.
Si la API de OAuth no está habilitada para un sitio, la respuesta del servidor contendría un vacío autorización Valor de la propiedad de la siguiente manera:
Ahora que hemos instalado el complemento OAuth1.0a, veamos cómo podemos crear y administrar consumidores para nuestras aplicaciones..
Una vez que el complemento OAuth1.0 se haya instalado con éxito, podemos crear y administrar consumidores para nuestras aplicaciones yendo al administrador de WordPress y luego a la Usuarios> Aplicaciones página.
En este Aplicaciones Registradas En la página, podemos registrar una nueva aplicación haciendo clic en el botón Agregar nuevo y luego completando los siguientes tres campos en la página resultante:
Una vez creado haciendo clic en el Ahorrar consumidor botón, el Clave de cliente y Secreto del cliente Los parámetros aparecerán en la parte inferior de la página para este consumidor en particular..
Estas Clave de cliente y Secreto del cliente los parámetros actúan como oauth_consumer_key y oauth_consumer_secret parámetros respectivamente.
Nuevo Secreto del cliente se puede crear haciendo clic en el Regenerar el secreto botón en la parte inferior de la página.
El complemento OAuth también expone la funcionalidad para crear un consumidor en la consola a través del complemento CLI de WP. Así que un nuevo consumidor también puede ser creado por el siguiente comando en el terminal:
wp oauth1 add --name =--description =
Este nuevo consumidor creado aparecerá en el Aplicaciones Registradas página donde puedes editarlo.
Una vez registrada nuestra aplicación, ahora estamos listos para comenzar el proceso de autorización de OAuth en las siguientes secciones.
Tenga en cuenta que al momento de escribir este tutorial, el complemento OAuth1.0a ya no es compatible con el paquete CLI del cliente. El paquete CLI del cliente podría actualizarse en un futuro próximo para trabajar con la última versión del complemento OAuth, pero por ahora, consulte la siguiente sección sobre cómo generar credenciales de OAuth usando un cliente HTTP.
El paquete Client-CLI del equipo de la API WP REST permite la interacción remota con un sitio de WordPress mediante la API WP-CLI y WP REST. La fuente se puede encontrar en GitHub.
Para usar este paquete, deberá tener lo siguiente instalado y activado en el servidor donde se encuentra su instalación de WordPress:
En la máquina (o cliente), desde la que desea generar solicitudes, debe instalar lo siguiente:
Puede encontrar las instrucciones para instalar los paquetes anteriores en sus sitios respectivos.
Dicho esto, clonemos el repositorio en el cliente ejecutando el siguiente comando:
$ git clone https://github.com/WP-API/client-cli
Ahora navegue en el directorio clonado e instale las dependencias de paquetes usando Composer:
$ cd client-cli $ composer install
Si todo va bien, la línea de comandos debe mostrar algo similar a lo siguiente:
Ahora que hemos instalado el paquete, estamos listos para generar credenciales de token e interactuar de forma remota a la API REST de WordPress utilizando OAuth.
Para iniciar el proceso de autorización de OAuth, primero obtenemos lo siguiente del servidor:
oauth_consumer_keyoauth_consumer_secretEsto se puede generar dirigiendo el terminal a su directorio de instalación de WordPress en el servidor y ejecutando el siguiente comando de CLP de WP:
$ wp oauth1 add
Esto generará una salida como la siguiente:
los Llave y Secreto aquí se obtienen los oauth_consumer_key y oauth_consumer_secret respectivamente.
Ahora necesitamos vincular al cliente a nuestro sitio de WordPress. En el cliente, navegue a la cliente-cli directorio que clonó en la sección anterior y ejecute el siguiente comando:
$ wp --require = client.php api oauth1 connect http: // your-dev-server / --key =--secreto =
Reemplace la URL y también la clave y el secreto que obtuvo en el paso anterior del comando anterior. La salida debe ser como la siguiente:
$ wp --require = client.php api oauth1 connect http: // localserver / wordpress-api / --key = kXZMTt3O5hBZ --secret = ueDNeCfgNuy estas prácticas a mano de los usuarios de las partes de China y otras partes de este manual. ? oauth_token = wFxrd8OzcIL6lSRkLmmvViIe Ingrese el código de verificación:
Desplácese hasta la URL proporcionada por el servidor y autentíquese haciendo clic en Autorizar botón:
Se le presentará el token de verificación (o el oauth_verifier) en la siguiente pantalla:
Copia el verificador y pégalo en tu terminal. Se le dará una Llave y un Secreto, cuales son básicamente tus oauth_token y oauth_token_secret respectivamente:
Puede usar estas credenciales de token en su cliente HTTP o en cualquier otra aplicación que admita el envío de solicitudes autenticadas utilizando la API de OAuth.
Dado que el complemento del servidor OAuth 1.0a sigue el flujo de tres patas, la generación de credenciales de OAuth implica tres pasos:
Comencemos a implementar cada uno de los pasos anteriores utilizando un cliente HTTP, es decir, Postman.
Para adquirir credenciales temporales, enviamos un ENVIAR solicitud a la / oauth1 / request punto final Este punto final de solicitud de credenciales temporales debe descubrirse automáticamente, ya que un servidor podría reemplazar esta ruta por su propia. Analizamos la función de descubrimiento automático al evaluar la disponibilidad de la API de OAuth en una sección anterior.
los ENVIAR solicitud debe incluir el oauth_consumer_key y oauth_consumer_secret Parámetros adquiridos al registrar un consumidor para la aplicación. La solicitud también podría incluir la oauth_callback El parámetro y esta URL de devolución de llamada deben coincidir con el esquema, host, puerto y ruta de la URL de devolución de llamada que se proporcionó al registrar la aplicación..
Aparte de la oauth_consumer_key y oauth_consumer_secret parámetros, la solicitud también debe incluir el outh_signature y outh_signature_method parámetros Al usar el cartero, el outh_signature Se genera automáticamente y solo tenemos que especificar el outh_signature_method parámetro. Actualmente, solo el HMAC-SHA1 el método de firma es compatible con el complemento del servidor OAuth.
Los parámetros anteriores se pueden pasar de cualquiera de las tres formas siguientes:
Autorización encabezamientoOBTENER) parámetros de consulta en la URLENVIAR) solicitar los parámetros del cuerpo. El tipo de contenido en este caso debe ser aplicación / x-www-form-urlencoded.Depende de usted usar cualquiera de estos métodos anteriores para enviar estos parámetros al servidor.
Comencemos ahora el proceso disparando a Postman y enviando un ENVIAR solicitud al punto final de solicitud de credenciales temporales. Pero antes de eso, copia el Clave del consumidor y Secreto del consumidor parámetros proporcionados por la nueva aplicación registrada, ya que serán necesarios en este paso.
Configurar el cartero para enviar un ENVIAR solicitud a su punto final de credenciales de token temporal. Entonces en el Autorización pestaña, seleccione la OAuth 1.0 Opción de la lista desplegable. Rellene el Clave del consumidor y Secreto del consumidor Campos con los valores proporcionados por el consumidor. Asegúrese de verificar que el Método de firma opción está configurada para HMAC-SHA1.
No necesitamos ingresar ningún otro valor que estos. Haga clic en el Solicitud de actualización botón y finalmente enviar la solicitud haciendo clic en el Enviar botón.
Si no hay error, el servidor devolverá un 200 - ok código de estado junto con el cuerpo de respuesta que tiene un tipo de contenido de aplicación / x-www-form-urlencoded. Este cuerpo de solicitud se parece a la siguiente cadena de texto:
oauth_token = tyNCKaL3WAJXib5SI6jCnr4P & oauth_token_secret = 1GiImP2XBacmk4FhcEFtqqENs3Bt6Q1m3zDf5s0Rk2kDJyTF & oauth_callback_confirmeded
Este cuerpo de respuesta contiene tres parámetros para el siguiente paso del flujo de tres patas. Estos tres parámetros son:
oauth_token: Un token OAuth temporal para el paso de autorización.oauth_token_secret: Un secreto temporal para ser usado a lo largo oauth_token.oauth_callback_confirmed: Estos parámetros siempre se devuelven ya sea que proporcione o no el oauth_callback parámetro en el primer paso.Con estas credenciales temporales listas, estamos listos para el paso de autorización del usuario.
Para el paso de autorización del usuario, abrimos el punto final de autorización del propietario del recurso en el navegador y pasamos el oauth_token y oauth_token_secret Según lo obtenido en el paso anterior como parámetros de consulta como los siguientes:
http: // su-dev-server / oauth1 / authorize? oauth_token =& oauth_token_secret =
El navegador le pedirá que inicie sesión en WordPress (si aún no lo ha hecho) y luego le pedirá que autorice la aplicación:
aquí Aplicación impresionante es el nombre de la aplicación registrada.
Autoriza la aplicación haciendo clic en el Autorizar y se le presentará un token de verificación en la siguiente pantalla:
Este token actúa como el oauth_verifier token en el siguiente paso.
Una vez que el usuario haya autorizado al cliente, la aplicación aparecerá bajo el aplicaciones autorizadas sección sobre el Usuarios> Tu perfil página.
El siguiente y último paso en el flujo de tres patas es el intercambio de fichas. En este paso, los tokens temporales obtenidos en el primer paso se intercambian por un token de larga duración que podría ser utilizado por el cliente.
Para iniciar el proceso de intercambio de token, vuelva a Postman y configúrelo para enviar un ENVIAR solicitud al punto final de solicitud de token.
Utilizando el OAuth 1.0 opción de nuevo en el Autorización pestaña, rellena los campos para Clave del consumidor y Secreto del consumidor con valores proporcionados por el consumidor. Para el Simbólico y Secreto de ficha campos, utilizar los valores de la oauth_token y oauth_token_secret parámetros (credenciales temporales) que se obtuvieron en el primer paso.
Como también podemos pasar parámetros en la URL como parámetros de consulta, agregue el oauth_verifier parámetro a la URL de la siguiente manera:
http: // su-dev-server / oauth1 / access? oauth_verifier =
Con todos los parámetros en su lugar, envíe la solicitud haciendo clic en el Enviar botón. Si todo va bien, el servidor devolverá un 200 - ok código de estado junto con el cuerpo de respuesta que contiene oauth_token y oauth_token_secret parámetros.
oauth_token =& oauth_token_secret =
En este punto, los tokens temporales adquiridos en el primer paso se descartan y ya no se pueden usar..
Estos nuevos oauth_token y oauth_token_secret los parámetros son sus credenciales de OAuth que puede usar en su cliente para generar solicitudes autenticadas.
Ahora que hemos obtenido nuestras credenciales de token, podemos enviar una solicitud de prueba al servidor utilizando Postman para ver si funcionan (¡por supuesto que sí!).
Le enviaremos un BORRAR solicite al servidor que elimine una publicación con un ID de 50. Este ID puede ser diferente en su caso.
Necesitará tener lo siguiente antes de comenzar:
oauth_consumer_key: obtenido en el primer pasooauth_consumer_secret: obtenido en el primer pasooauth_token: obtenido en el paso finaloauth_token_secret: obtenido en el paso finalSeleccionar OAuth 1.0 desde el menú desplegable debajo de Autorización pestaña en Cartero y complete los primeros cuatro campos como se mencionó anteriormente. A continuación es lo que parece:
Haga clic en el Solicitud de actualización Botón después de rellenar los campos. Revisando el Añadir params al encabezado La opción envía los parámetros en el encabezado de la solicitud en lugar de agregarlos en una cadena de consulta..
Envía la solicitud y deberás obtener un 200 - ok Código de estado del servidor, que muestra que la publicación se ha eliminado correctamente..
En este largo tutorial, presentamos una descripción general del método de autenticación de OAuth y cómo funciona para proporcionar acceso delegado seguro a aplicaciones y servicios de terceros. También configuramos la API de autenticación OAuth para WordPress en el servidor y la usamos junto con un cliente HTTP para obtener credenciales de token.
En la siguiente parte de esta serie, buscaremos recuperar contenido a través de la API REST de WP. Así que estad atentos…
