Voxel engineering

Tiempo de lectura: 4 minutos

Empezaba un lunes, más tarde conocido como “Disaster Monday”, de una manera que parecía tranquila en Voxel.

En el sprint teníamos una User Story Tech que trataba la subida de framework de una de nuestras aplicaciones Aspx. Concretamente, queríamos subir de Net Framework 4.6.1 a 4.8. Empezamos a desarrollar la User Story y conseguimos subir a Net Framework 4.8 sin mucho problema.

Subimos esta versión de la aplicación a un entorno de demo y se hicieron las pruebas pertinentes para probar el funcionamiento de la aplicación. Dato importante para más adelante, estas pruebas se hicieron con un explorador web Firefox.

Hasta aquí parecía todo correcto, por lo que por la tarde decidimos subir a Producción.

Una vez en producción, se realizaron pruebas manuales y todo parecía correcto.

Se lanzaron nuestros smoke tests automatizados (lanzados en un explorador web Firefox) y pasaron correctamente.
Qué buen día parecía: subida de framework y subida a producción sin problemas. #DeveloperLifeEnjoyer

Antes de iniciar el “Disaster Monday”, un poco de contexto

Para poder entender mejor el contexto de lo que ocurrió, es necesario explicar un poco por encima cómo gestionamos los logins de usuarios desde Voxel.

Cuando un usuario quiere entrar en la plataforma, le aparece una pantalla de login. Una vez introduce las credenciales, estas se validan en nuestro Servicio validador de identidades y se lanza un callback desde este para hacer un redirect a la web a la que quería acceder inicialmente nuestro usuario.

Este servicio validador de identidades cuenta con una caché documental que almacena los tokens temporales de acceso.

Una vez tenemos un poquito más de contexto, podemos iniciar el “Disaster Monday”.

Disaster #1

A la hora de subir a producción, diferentes clientes nos reportan que no pueden acceder a ninguna de las webs.

Miramos nuestro servicio de logs y vemos muchísimos errores en los streams. Los logs indican que hay problemas de conexión entre el servidor de identidades y la caché.

Avisamos al departamento de Infraestructura y nos pusimos a trabajar de forma conjunta en este tema:

Resulta ser que de los 3 nodos que teníamos de caché, uno de ellos cayó y esto hacía que el Servicio validador de identidades no se pudiera conectar a la caché.
No contábamos con un Balanceador en producción que balanceara a los diferentes nodos de caché activos.
Fallaba el Servicio validador de identidades al intentar conectar con la caché y esto hacía que ninguna persona pudiera pasar del login en las webs.

Una vez identificado el problema, quitamos el nodo de caché que daba fallos y anotamos las mejoras para planificarlas en los siguientes sprints y así evitar que volviera a ocurrir. Probamos el acceso a las webs (mediante Firefox) y todo parecía funcionar correctamente de nuevo.

Disaster #2

Justo cuando pensábamos que podíamos cerrar por hoy con la incidencia resuelta e ir a merendar tranquilamente, vemos que compañeros nuestros nos reportan que no pueden acceder a las webs mediante el navegador Google Chrome. A partir de ese momento, clientes nos reportan que tienen el mismo problema.

Y aquí empieza lo divertido.

Después de estar investigando, encontramos el problema: A partir de la versión Chrome 80, Google decidió cambiar el comportamiento original de un atributo de cookies llamado SameSite.

Originalmente, este parámetro admitía 2 valores:

Same Site Lax: Indicaba que la cookie debería de ser enviada dentro del mismo site o mediante GET de tu site hacia otros.
Same Site Strict: Limitaba la cookie a requests originadas dentro del mismo site.

¿Qué fue lo que hizo Google? Actualizó el estándar, añadiendo un nuevo valor:

Same Site None.
Cambio el valor por defecto a Same Site Lax.

¿Por qué hizo Google este cambio?

Se dice que con intención de forzar el uso de urls con https en los sitios web.

¿Por qué esto nos afecta?

Operaciones de OpenId Connect (login / logout) envían peticiones POST desde un site externo (Servicio validación identidad) al site de origen de la request (Aplicaciones).

Con este cambio, Chrome “rompe” los OpenId Connect logins.

A partir del cambio en Chrome, estas operaciones necesitarán excluirse de Same site, no estableciendo la propiedad, para garantizar que estas cookies se envíen durante sus flujos de trabajo.

Como hay diferentes navegadores web y cada uno de ellos puede interpretar el Same Site de una manera diferente (por eso ocurrió el error solamente con Chrome y no con Firefox), las aplicaciones .Net deberán modificarse para enviar este parámetro como Same Site None.

¿Por qué ocurre ahora?

Por la subida de Framework, ya que .Net cambia el comportamiento de su atributo Same Site a partir de las versiones:

Net Framework 4.7.2.
Net Core 2.1.

¿Cómo solucionamos este problema?

Una vez identificado el problema, decidimos hacer un wrapper alrededor de la gestión de nugets por defecto de Owin.OpenIdConnect y así poder settear el parámetro Same Site a None en la aplicación subida.

¿Qué aprendizajes hemos obtenido?

Ese día aprendimos y recordamos varias cosas.

La primera fue asegurarse de poder balancear los diferentes nodos de caché y hacer que el servicio validador de identidad no caiga si se queda sin caché.

Como autocrítica tenemos que comentar que fallamos al solamente probar con un navegador. Ya que sabemos que nuestros clientes utilizan diferentes navegadores y cada uno de estos puede implementar cambios que otros no pueden.

Teniendo un entorno de demo igual que el de producción, podríamos haber detectado este fallo mucho antes de llegar a producción y afectar a los clientes.

Conclusión final

Una vez vemos todo lo ocurrido, ¿cómo podemos evitar que suceda de nuevo? Surgieron varias iniciativas que transformamos en historias de usuario para prevenir en un futuro:

Utilizar un balanceador de los nodos de caché para evitar problemas si uno de los nodos cae.
Hacer que el servicio validador de identidad sea resistente a trabajar sin la caché.
Realizar tests automáticos que prueben en varios navegadores.

Finalmente, voy a aprovechar este post para agradecer a todas las personas que se volcaron en ayudar cuando surgieron estos diferentes problemas, ya que cambia mucho cuando hay un día así, pero te sientes respaldado por personas que trabajan contigo hacia un objetivo común.

Así que como reflexión, os animo a seguir haciendo pequeños actos hacia vuestros compañeros y compañeras de equipo. Puesto que solamente el hecho de enviar un mensaje y preguntar que si puedes ayudarle en algo puede marcar la diferencia.

Bibliografía:

Sobre el autor:
Twitter
Linkedin