Investigando y depurando fallos en la vinculación de la cuenta de tu Skill de Alexa
Hace poco estuve trabajando en una Skill en la que necesitaba implementar la funcionalidad de vinculación de la cuenta (o account linking) y me encontré con algunos problemas que me llevaron días resolver. Pronto me di cuenta de que la cantidad de información que servía de guía para solventar algunos problemas era escasa y dispersa; además poco o nada en Español. Esto ha motivado el artículo. Básicamente cuento un poco mi experiencia con algunos ejemplos y centralizo en Español todo lo que he conseguido.
¿Qué esperar de este artículo?
- Este tutorial tiene como objetivo principal servir de referencia para ayudarte a descubrir los posibles problemas que puedas tener durante la implementación de la funcionalidad de vinculación de la cuenta (o account linking) en tu Skill de Alexa.
- Breve descripción de OAuth2 (muy breve) y cómo funciona en una Skill.
- Ejemplos de problemas con los que me he conseguido.
- Referencias a los artículos que me han ayudado a solventar los problemas que he conseguido.
Es importante resaltar que este enfoque es sobre las Custom Skills. Existen pequeñas diferencias con respecto a las Smart Home Skills.
Requisitos
- Cuenta en la Consola de AWS. Esto para poder utilizar Lambda.
- Cuenta de desarrollador de Alexa. Esto permite crear skills.
- Una Skill que implemente Vinculación de la cuenta.
- Un servicio OAuth2 y los datos de configuración disponibles.
Primeros pasos
¿De qué se trata la funcionalidad de vinculación de la cuenta (o account linking)?
Permite conectar o asociar el usuario con el que has registrado tu dispositivo Echo con uno en un servicio de terceros, pudiendo así acceder a los servicios que ofrecen estos, en este caso, a través de una Skill. Por ejemplo, cuando vinculas tu cuenta con el usuario de tu restaurante preferido en el que puedes pedir comida a domicilio a través de su Skill o cuando lo vinculas al usuario de tu gimnasio y reservas una clase a través de su Skill.
¿Para qué necesitamos vincular nuestra cuenta con otra en un servicio de terceros?
- Para ofrecer servicios que se ajustan al perfil del usuario.
- Para ofrecer información o una experiencia personalizada.
- Para ofrecer al usuario la posibilidad de comprar/adquirir productos.
Descripción general: ¿Cómo funciona?
La implementación de esta funcionalidad sigue el estándar RFC6749 (reemplazando el antiguo RFC5849 o OAuth). Se conoce como OAuth2. Es un protocolo de autorización, un estándar, que permite a aplicaciones (terceros) tener acceso limitado a un servicio HTTP. Esto se logra de alguna de estas dos formas:
- Gestionando la interacción de aprobación de acceso entre la aplicación y el servicio HTTP en nombre del propietario de los servicios o
- Permitiendo a la aplicación obtener el acceso por sí misma.
Roles
- Propietario de Recursos (Resource Owner): Es la entidad encargada de permitir acceso a recursos protegidos. Cuando este se refiere a una persona, se le llama usuario final (end-user).
- Servidor de Recursos (Resource Server): Es el servidor donde se encuentran los recursos protegidos, es capaz de aceptar y responder solicitudes a recursos protegidos usando access tokens. Es donde se encuentran los recursos a los que el usuario quiere tener acceso.
- Cliente (Client): Es la aplicación capaz de hacer solicitudes a recursos protegidos en nombre, y con autorización, del propietario del recurso.
- Servidor de Autorización (Authorization Server): Es el servidor que autentica la identidad del Propietario de Recursos y asigna el access token. Este puede, en algunos casos, ser el mismo Servidor de Recursos.
Para ilustrarlo mejor, una imagen:
Podemos ver lo siguiente:
( A ) El Cliente realiza una solicitud de autorización al Propietario de Recursos.
( B ) El Propietario de Recursos autoriza al Cliente. El Cliente recibe las credenciales que corresponden a uno de los 4 tipos de permisos que se pueden conceder a un Cliente según la especificación del protocolo, estos son:
- Código de autorización (authorization code). Este es el que se recomienda utilizar en una Skill. Detalles en la siguiente sección.
- Permisos implícitos (Implicit). Este sirve como alternativa en una Skill, aunque aún no conozco ninguna Skill que lo utilice e incluso veo que es poco recomendado.
- Credenciales del Propietario de recursos (Resource Owner Password Credentials).
- Credenciales de Client (Client Credentials).
( C ) El Cliente solicitud un access token utilizando las credenciales obtenidas en (B).
( D ) El Servidor de Autorización autentica al cliente y valida las credenciales presentadas y, en caso de ser validas, otorga el access token.
( E ) El Cliente realiza la solicitud de recursos protegidos al Servidor de Recursos utilizando el access token que le ha sido otorgado.
( F ) El Servidor de Recursos valida el access token y, en caso de ser valido, satisface la solicitud.
Nota: Si deseas información más detallada sobre el protocolo, al final del artículo pongo varias referencias que han sido de mucha ayuda.
Sobre Código de Autorización (Authorization Code Grant)
Una vez que hemos visto, a grandes rasgos cómo funciona el protocolo OAuth2, podemos resaltar que:
- Código de Autorización (Authorization Code Grant): Es el tipo de permiso que se implementan en la gran mayoría de las Skills que tienen esta funcionalidad; entre otras cosas, porque es la que recomienda Amazon.
- Comprender este flujo nos permite depurar errores de mejor manera y además entendernos usando una terminología común con nuestros clientes. Además de entregar documentos de requerimientos técnicos más claros y de mejor calidad.
Código de Autorización (Authorization Code Grant)
Es una credencial que representa la autorización del Propietario de Recursos (para poder acceder a sus recursos) que utiliza el Cliente para solicitar el access token. En este caso específicamente, se trata de un código.
La implementación de este tipo de permiso incluye un elemento nuevo, el User-Agent, que es un Servidor de Autorización que hace de intermediario entre el Cliente y el Servidor de Recursos. Este es capaz de recibir solicitudes de redireccionamiento.
Este agrega una capa de seguridad adicional puesto que el Propietario de Recursos solo se autentica con el Servidor de Autorización y estas credenciales nunca son compartidas con el Cliente ni expuestas públicamente. Además el access token se comparte directamente entre el Servidor de Autorización y el Cliente dejando más seguro al Propietario de Recursos.
Código de Autorización: El flujo
( A ) El Cliente indica al User-Agent la URI del Servidor de Autorización. El Cliente incluye su identificador, el alcance (scope), estado (local state) y la URI a la cual el Servidor de Autorización va a dirigir el User-Agent una vez que el acceso es aprobado o denegado.
( B ) El Servidor de Autorización, a través del User-Agent, autentica al Propietario de Recursos -entendido en este caso como el usuario final- que ha permitido al Cliente realizar esta solicitud en su nombre. El Servidor de Autorización otorga o niega permisos al Cliente.
( C ) En el caso de que se otorgue acceso al Cliente, el Servidor de Autorización redirige el User-Agent al Cliente, utilizando la URI de redirección que el Cliente proporcionó en ( A ) incluyendo también el Código de Autorización y el estado (local state) que también ha sido proporcionado por el Cliente en ( A ).
( D ) El Cliente, utilizando el Código de Autorización obtenido en ( C ) solicita al Servidor de Autorización un access token. El Cliente se autentica con el Servidor de Autorización. En esta solicitud el Cliente incluye la URI utilizada para obtener el Código de Autorización.
( E ) El Servidor de Autorización autentica el Cliente y valida el Código de Autorización, se asegura de que la URI de redirección recibida es igual a la utilizada en ( C ). En caso de ser valida el servidor responde con un access token y opcionalmente con un refresh token.
OAuth2 y nuestra Skill
En esta sección quiero mostrar las similitudes de la terminología utilizada por Amazon Alexa y el protocolo OAuth2 en la implementación de la Vinculación de la Cuenta (Account Linking).
Empecemos por los roles:
- Propietario de Recursos (Resource Owner): Es el usuario de la Skill. El dueño de la información a la que se quiere tener acceso a través de ella.
- Servidor de Recursos (Resource Server): Es el servidor donde se encuentran los recursos a los que el usuario quiere tener acceso a través de la Skill. Por ejemplo, los resultados de su último examen de Matemáticas, el estado de alguna orden en un restaurante, etc.
- Cliente (Client): Es nuestra Skill. Es importante comentar que Alexa tiene un papel de cliente que explicaré más adelante. Esto agrega una capa de seguridad importante.
- Servidor de Autorización (Authorization Server): Es el servidor que autentica la identidad del Propietario de Recursos y asigna los access tokens. Este puede, en algunos casos, ser el mismo Servidor de Recursos.
Otros componentes importantes
Es importante mencionar que algunos de los componentes que marco con un “*” son utilizados en la configuración de la funcionalidad de Vinculación de la Cuenta en el Portal de Desarrolladores de Alexa.
- User-Agent: Es la Aplicación Móvil de Alexa. Esta es capaz de aceptar redireccionamiento y mostrar la web en la que el usuario ingresa sus credenciales para autenticarse.
- Authorization URI*: Esta URI es la que utiliza la aplicación móvil de Alexa para que el usuario ingrese las credenciales que lo autentican y autorizan para utilizar los recursos protegidos que solicita. Usualmente es un portal web, con ciertas características, que permite al usuario utilizar su nombre de usuario y una contraseña.
- Access Token URI*: Es la URI que utiliza Alexa para solicitar el access token y el refresh token.
- Client ID*: Es el ID que identifica a la Skill que, en nombre del usuario, está solicitando autenticación.
- Client Secret*: Es una credencial que combinada con Client ID permite a Alexa autenticarse con el Servidor de Autorización, permitiendo a este saber que la solicitud viene de Alexa.
- State: Es una cadena única que debe permanecer intacta hasta que el proceso de autenticación/autorización termine. Este se genera automáticamente por Alexa.
- Grant Type: En este caso siempre es authorization_code. Este parámetro se pasa en la URL que Alexa utiliza para solicitar el access token y el refresh token. Es seleccionado automáticamente al momento de elegir el tipo de credencial cuando se configura la funcionalidad de Vinculación de la Cuenta en el Portal de Desarrolladores de Alexa.
- Redirection URL: Es la URI a la que el usuario es redirigido una vez que ha sido autenticado. Esta URI se pasa al Servidor de Autenticación como parámetro al hacer la solicitud del Código de Autorización. Amazon ofrece 3 y la utilización de alguna u otra obedece la región en la que nos encontremos:
EU e India https://layla.amazon.com/api/skill/link/<codigo_unico_por_skill>América del Norte
https://pitangui.amazon.com/api/skill/link/<codigo_unico_por_skill>Lejano Este
https://alexa.amazon.co.jp/api/skill/link/<codigo_unico_por_skill>
El <codigo_unico_por_skill> es un código alfanumérico que identifica la Skill y le permite a Alexa saber a cuál pertenecen las credenciales que está almacenando.
- Scope: Determina los permisos que se solicitan. Esto se determina cuando se configura el Servidor de Autenticación (OAuth2).
- Response Type: En el caso de las Skills siempre es code.
Como podemos observar la posibilidades de que algo falle son altas, desde utilizar una URL que no es correcta, utilizar una URL correcta en el sitio equivocado, no agregar todos los parámetros necesarios a cada URL, etc. Como veremos mas adelante puede que el servicio OAuth2 no esté bien configurado y no permita la redirección de las URLs de Amazon o el Cliente ID no tenga los permisos necesarios etc.
Caso de uso: Obtener el día y la hora de mi siguiente WOD de Crossfit.
Mucha teoría, momento de un caso de uso.
La Skill tiene como único objetivo decirte cuando es tu siguiente clase de Crossfit. Asumo dos cosas:
- El usuario ya ha hecho una reservación por lo tanto puede preguntar por la clase directamente.
- La Skill solicita al usuario la Vinculación de la Cuenta al momento de pedirle a Alexa que le diga cuándo es su siguiente clase.
A continuación pongo los distintos pasos de este caso de uso enfocando los detalles en el proceso de Vinculación de la Cuenta.
( A ) Usuario: inicia la Skill.
( B ) Alexa: da la bienvenida y ofrece al usuario alguna funcionalidad.
( C ) Usuario: dime cuando es mi siguiente clase
( D ) Alexa: informa al usuario que necesita vincular su cuenta para tener acceso a esta información y envía una tarjeta a la aplicación móvil de Alexa.
( E ) Usuario: hace tap en enlace de la tarjeta.
( F ) Aplicación Móvil de Alexa: redirige al usuario al portal especial del Box en el que puede insertar su usuario y contraseña.
( F.1 ) La solicitud que se envía al Servidor de Autenticación incluye el Client ID, Response Type, Redirect URI, Scope y State.
( G ) Usuario: inserta sus credenciales.
( H ) El Servidor de Autorización autentica al usuario y, en caso de ser satisfactoria, otorga el Código de Autorización. Aquí es donde entra Alexa y utilizando ese código, el Client ID, Secret ID y el Grant Type, solicita el access token y el refresh token.
( H.1 ) Una vez obtenido el access token y refresh token, los almacena. Utilizará este access token para todas las solicitudes de recursos protegidos del usuario.
( H.2 ) Cuando el access token caduque automáticamente utilizará el refresh token para solicitar un access token nuevo.
( H.3 ) El Servidor de Autorización redirige al usuario al portal de Alexa que indica que la Vinculación ha sido satisfactoria. La cuenta queda vinculada.
( I ) Aplicación Móvil de Alexa: Muestra el portal de Alexa que informa al usuario si la Vinculación de la Cuenta se ha realizado satisfactoriamente o no.
( J ) Alexa: informa al usuario sobre el día y la hora de su siguiente clase. Se despide, envía en una tarjeta la información al usuario y cierra la sesión.Si vemos el flujo utilizando URIs de ejemplo. Sería así:
La aplicación móvil de Alexa inicia el flujo de autenticación enviando la Authorization URI con los parámetros mencionados:
( F ) Aplicación Móvil de Alexa: redirige al usuario al portal especial del Box en el que puede insertar su usuario y contraseña.
( F.1 ) La solicitud que se envía al Servidor de Autenticación incluye el Client ID, Response Type, Redirect URI, Scope y State.
Por ejemplo:
https://api.pumpedcrossfit.xyz/oauth/v2/auth?response_type=code&client_id=98dr4jngfh7w873498jrt&redirect_url=http%3A%2F%2Flayla.amazon.com%2Fapi%2Fskill%2Flink%2FK4J857NGD63GIB&scope=ROLE_USER&state=f9uh408tu0rehjgf038grug3qg8hgh7qr39u( G ) Usuario: inserta sus credenciales.
( H ) El Servidor de Autorización autentica al usuario y, en caso de ser satisfactoria, otorga el Código de Autorización. Aquí es donde entra Alexa y utilizando ese código, el Client ID, Secret ID y el Grant Type, solicita el access token y el refresh token.
Por ejemplo:
https://layla.amazon.com/api/skill/link/K4J857NGD63GIB?state=f9uh408tu0rehjgf038grug3qg8hgh7qr39u&code=Njk0ZDhmYWIrMDM2NDJhZDSe ha obtenido el Código de Autorización. Alexa solicita access token y refresh token, de esta forma:
POST /login?grant_type=authorization_code HTTP/1.1
Host: api.pumpedcrossfit.xyz
Content-Type: application/json
code: Njk0ZDhmYWIrMDM2NDJhZD
redirect_uri: https://layla.amazon.com/api/skill/link/K4J857NGD63GIB
client_id: 98dr4jngfh7w873498jrt
client_secret: dhgrhrdr4jwdefg2h7w878j8rt
{"code": "Njk0ZDhmYWIrMDM2NDJhZD", "redirect_uri": "https://layla.amazon.com/api/skill/link/K4J857NGD63GIB", "client_id": "98dr4jngfh7w873498jrt", "client_secret": "dhgrhrdr4jwdefg2h7w878j8rt"}El servidor responde:
{
"access_token": "OiTUxY2VkZjVlMWJjNjZWQ1MmZjYg",
"expires_in": 600,
"token_type": "bearer",
"scope": "ROLE_USER",
"refresh_token": "M1ZDVlNTYyZWEFiZWY1YThlZDZmMQ"
}( H.1 ) Una vez obtenido el access token y refresh token lo almacena. Utilizará este access token para todas las solicitudes de recursos protegidos del usuario.
( H.3 ) El Servidor de Autorización redirige al usuario al portal de Alexa que indica que la Vinculación ha sido satisfactoria. La cuenta queda vinculada.
Por ejemplo:
https://skills-store.amazon.co.uk/api/skill/link/K4J857NGD63GIB?code=Njk0ZDhmYWIrMDM2NDJhZD&state=f9uh408tu0rehjgf038grug3qg8hgh7qr39uEl usuario solicita la información sobre su siguiente clase:
GET /portfolio HTTP/1.1
Host: api.pumpedcrossfit.xyz/classes
Authorization: Bearer OiTUxY2VkZjVlMWJjNjZWQ1MmZjYg
cache-control: no-cache( J ) Alexa: informa al usuario sobre el día y la hora de su siguiente clase. Se despide, envía en una tarjeta la información al usuario y cierra la sesión.
Descubriendo y depurando problemas
Alexa y la aplicación móvil se encargan de preparar y hacer las solicitudes de Código de Autorización, access token y refresh token, así como de gestionar la solicitud de un nuevo access token cuando este esté caducado utilizando la información que proporcionamos en la configuración de esta funcionalidad en el Portal de Desarrollador de Alexa, de modo que a nosotros los desarrolladores nos llega todo lo que necesitamos en el JSON que envía Alexa a nuestra Skill cuando el usuario la utiliza. Específicamente en:
handler_input.request_envelope.context.system.user.access_token Así que siempre podemos hacer las solicitudes al Servidor de Recursos utilizando este access token.
Esto tiene como desventaja que cuando algo falla, es más o menos complicado y engorroso determinar qué es y poder arreglarlo. Ciertamente algunas cosas son evidentes y otras no tanto. Por eso propongo debajo un compendio de aspectos que debemos tomar en cuenta al momento investigar e incluso implementar esta funcionalidad.
Nota: Es importante mencionar que esto es solo referencia. Está lejos de ser una guía completa.
- Prueba la Vinculación de la Cuenta en el navegador y en diferentes dispositivos. Si en algunos funcionas y en otros no, es muy probable que te faltase agregar un dominio en la lista de dominios permitidos desde los cuales se pueden solicitar recursos. Se configuran aquí:
- Recuerda que las ventanas emergentes (pop-ups) no se permiten, por lo que se intentas realizar el proceso de autenticación para la vinculación de la cuenta, no va a funcionar.
- Si tu proceso de vinculación es iniciado en otra pestaña o ventana en Android o se muestra una ventaba vacía en iOS, asegúrate de que los dominios desde los que se hacen las llamadas están permitidos (whitelisted). Es importante que incluyas hasta los sub-dominios. Por ejemplo, si se realiza una llamada a api.dominio.com y permites dominio.com no va a funcionar, hay que incluir api.dominio.com también.
- Si falla en todos los dispositivos intenta hacer el proceso en un navegador, como Chrome o Firefox activando las Developer Tools, de esta forma puedes observar todas las llamadas a la red y los parámetros que Alexa agrega a estas.
- Presta especial atención al parámetro code y que este permanezca intacto en todos los intercambios.
- La Authorization URI y Access Token URI deben ser HTTPS al puerto 443 y el certificado SSL que se utilice debe pertenecer a una CA Authority aprobada por Amazon. Puedes verificar la lista aquí.
- Asegúrate de recibir una respuesta 200 OK al recibir el access_token.
- Utiliza Credentials in request body como Client Authentication Scheme en la configuración de la funcionalidad en el Portal de Desarrollador de Alexa. Si necesitas más información sobre esto, puedes ver aquí.
- Asegúrate de que el access_token se recibe en JSON, si este se recibe simplemente como cadena de caracteres la vinculación fallará. Esta es, en principio y hasta el momento, la razón por la que no se puede vincular una cuenta GitHub sin utilizar API Gateway.
- El TTL del access_token debe ser mayor a 5 minutos.
- Si tienes acceso a los logs del servidor OAuth2, activa las trazas HTTP y observa los errores en la configuración.
Es algo entre Alexa y OAuth2
Si luego del proceso de autenticación/autorización y redirección se muestra un mensaje, genérico, “La vinculación de la cuenta ha fallado” (o algo similar), no tienes acceso a los logs del lado del servidor OAuth2 u obtener información por parte del equipo que administra el servidor OAuth2 es difícil.
Esta sección también te interesa.
Amazon API Gateway es un servicio de AWS que permite a desarrolladores crear, publicar, mantener, monitorear y asegurar APIs. Se puede integrar como proxy HTTP. Esta integración permite ofrecer una API que permite a una aplicación web tener acceso a las funcionalidades o recursos del back-end al que esta apunta.
Debajo podemos observar la integración de API Gateway como proxy HTTP.
Nota: En este caso, y para variar el ejemplo del documento oficial, asumimos que el servicio OAuth2 es proporcionado por nuestro cliente y no por Amazon. Por eso no utilizamos la Access Token URI. Nos interesa que el servidor de autenticación nos devuelva un access_token valido para poder continuar con el proceso de vinculación.
Manos a la obra…
Ahora vamos a crear e integrar API Gateway como un proxy HTTP. Para ello vamos utilizar CloudFormation, un servicio de AWS que permite describir los recursos AWS que deseamos utilizar en formato JSON.
- Vamos a AWS CloudFormation. Hacemos click en “Create New Stack” (1).
2. Elegimos la opción que nos permite utilizar una plantilla (2), seleccionamos el archivo y hacemos click en “Next”. Aquí puedes encontrar la plantilla. Puedes hacer algunas modificaciones en el archivo antes de utilizarlo en la web o seguir con el siguiente paso.
Si deseas hacer las modificar el archivo antes:
a) Pega en la línea 9 del Gist la URI de Autorización de la sección Account Linking del Portal de Desarrollador de Alexa.
b) Pega en la línea 14 del Gist la URI del Access Token de la sección Account Linking del Portal de Desarrollador de Alexa.El cualquier caso he dejado un par de placeholders (líneas 10 y 15) en el Gist que aparecerán junto a las cajas de texto en el paso siguiente.
3. Si prefieres insertar la información durante el proceso de configuración también es posible. Primero inserta el nombre del conjunto de recursos (4), luego la URI de Autorización (5), la URI de Access Token (6) y haz click en “Next” (7).
4. Simplemente haz click en “Next” (8).
5. Aceptamos que AWS CloudFormation cree los recursos IAM necesarios (9) y haz click en “Next” (10).
6. En esta pantalla se muestra el progreso de creación de los diferentes recursos puedes haces click en (11) para observar el progreso en el panel inferior. Esperamos a que el proceso termine.
7. Si observamos (12) podemos ver en verde “CREATE_COMPLETE”. Ya tenemos disponibles las URLs de nuestro proxy y que son las que vamos a utilizar en la configuración de la funcionalidad de Vinculación de la Cuenta del Portal de Desarrolladores de Alexa.
8. Haz click en ”Outputs” (8) y veras las dos URLs que nos interesan (14 y 15). Como mencioné antes, nos interesa para este caso la URL de Autenticación (15), la copiamos. Ya que nos interesa obtener un access_token, no vamos a utilizar la URL de Access Token que nos proporciona la API Gateway, no funcionaría.
9. Ahora vamos al Portal de Desarrollador de Alexa, en la sección de Vinculación de la Cuenta. Pegamos en Authorization URI (16) la URL de Autorización que obtuvimos al crear la API y salvamos los cambios (17).
10. Salvados los cambios. Vamos a CloudWatch Logs y seleccionamos los Logs. Observamos en un nuevo grupo de Logs (18) cuyo nombre empieza por “API-Gateway-Execution-Logs_<código_identificación_único>/DebugStage”, el código de identificación único es el que se encuentra al inicio de la URL de Autorización que se ha generado, en el caso es “83x9bt9xs0”.
Es en estos logs donde podremos observar la información que nos interesa.
11. Ahora iniciamos el proceso de Vinculación de la Cuenta en cualquiera de nuestros dispositivos, aplicación móvil o navegador y esperamos que se escriban los logs.
Debajo un par de ejemplos de errores que podemos ver utilizando nuestro nuevo proxy.
El primer caso (19) es debido a que el tiempo de refrescamiento del token no era suficiente, en el servidor se aumentó y esa fue la solución.
En este segundo caso (20) es debido a que el tipo de credencial para el cliente que teníamos configurado no estaba permitido. La solución fue darle los permisos.
En este artículo
- He descrito, la funcionalidad de vinculación de la cuenta.
- Brevemente, el estándar RFC 6749 y los roles que implementa, las credenciales de tipo código de autorización.
- Cómo funciona el protocolo en nuestra Skill y los diferentes componentes necesarios para su implementación.
- Un ejemplo en el cual se podría utilizar.
- Liste algunas consideraciones generales a tener en cuenta cuando la funcionalidad falla como primeros pasos de depuración e investigación del problema.
- Describí cómo utilizar Amazon API Gateway como un proxy HTTP que, integrado con nuestro back-end, podemos utilizar para observar las diferentes transacciones que suceden entre Alexa Voice Service y el servidor OAuth2.
- Coloqué un par de ejemplos de fallos que podemos observar utilizando los logs del proxy.
Referencias (muy útiles)
- Guía de depuración de problemas (en inglés).
- Documentación sobre la implementación de Vinculación de la Cuenta de Amazon (en inglés).
- Documentación sobre la implementación de la Vinculación de la Cuenta en Custom Skills de Amazon (en inglés).
- Documentación sobre las credenciales de código de autorización (en inglés).
- Estándar RFC6749 (en inglés).
- Guía de implementación del proxy HTTP utilizando AWS API Gateway para depurar Skills (en inglés).
- Documentación de AWS API Gateway: Construcción de una API con Integración de un Proxy HTTP (en inglés).
Muchas gracias por leer.
Escribió para Diseñando para la Voz, Francisco.
¿Tienes dudas?, ¿Conoces alternativas de depuración o investigación a las que menciono?, ¿Conoces mejoras que se puedan implementar a las del artículo?. Déjanos un comentario. Nos encantaría conocer tus consideraciones.
