Recapitulación

En mi blog anterior, echamos un vistazo a cómo implementar OAuth2 en LabVIEW. OAuth2 tiene un flujo de trabajo sencillo en el que lanzamos un navegador a una URL de inicio de sesión específica, capturamos el mensaje de redirección del navegador y, finalmente, solicitamos un token de acceso.

Anteriormente, implementamos un servidor web local para capturar el mensaje de redirección. Aunque era fácil de hacer, no es una solución muy reutilizable. ¿Qué pasaría si quisiéramos crear una biblioteca reutilizable para manejar una API específica? De mi investigación, no he encontrado una manera de distribuir una configuración de servidor web con mi biblioteca.

En este post, revisaremos los pasos 1 y 2 y veremos una mejor manera de manejar la redirección OAuth2.

El Protocolo de Transferencia de Hipertexto

HTTP (Hypertext Transfer Protocol) es un conjunto de reglas para la transferencia de datos a través de la web. HTTP utiliza un conjunto de pares petición/respuesta para permitir que nuestro navegador web solicite archivos de un servidor web y reciba la respuesta.

No es necesario conocer los detalles de HTTP. Sin embargo, el detalle más importante al que hay que prestar atención es el hecho de que HTTP está construido sobre el conjunto TCP/IP. ¿Qué significa esto? Significa que no necesitamos un servidor web. Sólo necesitamos abrir un socket TCP.

Procesamiento de la redirección

En mi entrada anterior, registramos una aplicación (o integración) directamente en el sitio web de Xero. Como parte de esa configuración, especificamos una URL de redirección para:

https://localhost:5002/OAuth/Redirect

Esta URL le dice a Xero que envíe una solicitud HTTP GET a un socket TCP abierto en 127.0.0.1 utilizando el puerto 5002. Así que, después de lanzar el navegador web a la URL de solicitud de autorización, ¡abramos ese socket nosotros mismos!

Figura 1 - Abrir el socket TCP

En la Figura 1, creamos una escucha TCP para localhost en el puerto 5002. Para este ejemplo, no estoy especificando un tiempo de espera. Esto significa que el socket escuchará indefinidamente las conexiones entrantes. Si el usuario cierra el navegador y cancela el proceso de autenticación, esto bloqueará la ejecución del resto de nuestro código y se sentará para siempre. Es recomendable que añadas un tiempo de espera y coloques la escucha en un bucle para proporcionar una forma de que tu aplicación cancele el proceso de autenticación.

El siguiente paso es leer del socket.

Figura 2 - Lectura del socket TCP

Elegí un valor arbitrario de 2000 para la propiedad bytes to read. La realidad es que sólo necesitaremos la primera línea de la respuesta. Una respuesta típica tendrá este aspecto:

Figura 3 - La respuesta HTTP

La sección naranja es la única que nos interesa. Contiene la URL completa de la solicitud GET y, lo que es más importante, el "código" que necesitamos para gestionar el resto de nuestra autenticación.

Analizar esta respuesta es relativamente fácil. Aunque mi ejemplo de la Figura 4 utiliza regex, no es necesario en absoluto. Todo lo que aparece en el recuadro naranja termina con una combinación de retorno de carro y salto de línea que permite dividir la cadena. A continuación, puede buscar la palabra clave "code" y obtener los datos después del signo igual.

Figura 4 - Análisis de la respuesta HTTP

Limpieza

Ahora que podemos recibir la respuesta de la redirección y analizarla, vamos a añadir alguna respuesta al navegador para que el usuario sepa que hemos terminado.

Figura 5 - Respondiendo al navegador

Esto devolverá algo de HTML para que el navegador abierto lo renderice. El HTML de la Figura 5 es aburrido y no visualmente atractivo, por lo que deberás modificarlo para darle el aspecto que desees.

Y con esto, ¿hemos terminado?

Espera, ¡esto no es HTTPS!

Si intentamos ejecutar esto, no obtendremos ninguna respuesta válida. OAuth2 requiere la transferencia de datos a través de SSL. Si intentamos configurar Xero con una URL HTTP, la rechazará.

¿La solución? Añadamos TLS a nuestro socket TCP.

Implementación de TLS

El primer paso para añadir soporte TLS, es generar certificados. La generación de certificados está fuera del alcance de este post. Sin embargo, National Instruments tiene un gran ejemplo de comunicación TLS que detalla como generar sus certificados. Busque el ejemplo VI "TLS Client and Server with Self-Signed Server Certificate".

Figura 6 - Buscador de ejemplos TLS

En el ejemplo, encontrará comentarios de National Instruments detallando como usar la utilidad cfssl para generar los archivos srv-key.pem y chain.pem necesarios para configurar TLS.

Figura 7 - Comentarios CFSSL

Con nuestros archivos pem generados, vamos a aplicarlos al socket TCP. Los pasos a seguir aquí son:

• Cargar la clave privada (srv-key.pem) en memoria
• Cargar los certificados (chain.pem) en memoria
• Crear una nueva configuración TLS
• Añadir la clave privada y los certificados a la configuración
• Hacer que la configuración sea inmutable
• Configurar el socket TCP para que acepte TLS
• Leer la respuesta normalmente
  
  
  
  

Figura 8 - Añadir TLS