Month: septiembre 2024

Al crear aplicaciones web modernas, especialmente aquellas que requieren autenticación de usuarios, uno de los métodos más utilizados es JWT (JSON Web Token) . En este artículo, analizaremos en profundidad qué es JWT, cómo funciona y explicaremos un fragmento de código que genera y establece un JWT como cookie.

Comencemos por entender los conceptos básicos.

¿Qué es JWT?

JWT son las siglas de JSON Web Token , que es una forma compacta y segura de representar información entre dos partes (el cliente y el servidor). En el contexto de una aplicación web, se utiliza para verificar la identidad de un usuario sin necesidad de comprobar sus credenciales (como una contraseña) repetidamente.

Imagine un JWT como un ticket que recibe un usuario después de iniciar sesión. Este ticket tiene cierta información sobre el usuario (como su ID) y está firmado por el servidor. El usuario conserva este ticket y lo presenta cada vez que solicita algo al servidor, de modo que el servidor sepa quién es.

Componentes clave de un JWT:

• Encabezado : contiene metadatos sobre el token, como el tipo (JWT) y el algoritmo utilizado para firmarlo.
• Carga útil : contiene los datos reales, como el ID del usuario ( userId), y puede incluir otros detalles.
• Firma : es una firma única que se crea utilizando una clave secreta (conocida únicamente por el servidor). Garantiza que nadie pueda manipular el token.

Los JWT se utilizan normalmente para la autenticación en aplicaciones web. Cuando un usuario inicia sesión, el servidor genera un JWT y lo envía al cliente (normalmente en una cookie ). El cliente envía este token con cada solicitud, lo que permite al servidor verificar la identidad del usuario.

Desglose del código: Generación de un JWT y configuración del mismo en una cookie

Aquí hay un fragmento de código que ilustra cómo generar un JWT y almacenarlo en una cookie:

Vamos a desglosarlo y explicar cada parte.

1. Creación del JWT ( jwt.sign)

La primera parte de la función crea el JWT. Esto es lo que sucede:

• jwt.sign({ userId }, process.env.JWT_SECRET, { expiresIn: "7d" }):Esto genera un JWT con el userIdcomo parte de su carga útil. El process.env.JWT_SECRETes una clave secreta almacenada en las variables de entorno que se utiliza para firmar el token, lo que garantiza su seguridad. El token está configurado para expirar en 7 días ( expiresIn: "7d"), lo que significa que después de ese período, ya no será válido y el usuario deberá iniciar sesión nuevamente.

¿Por qué es esto importante?

• Este token se utiliza para autenticar al usuario. Cuando el usuario realice solicitudes futuras, enviará este token al servidor para que este pueda verificar su identidad.

Si omite este paso:

• Sin generar un token, el servidor no tendrá forma de saber quién es el usuario después de iniciar sesión. Esto significa que no podrá acceder a páginas ni realizar acciones que requieran autenticación, como ver su perfil o realizar una compra.

2. Almacenamiento del token en una cookie ( res.cookie)

Después de crear el token, debemos almacenarlo en algún lugar para que el navegador pueda enviarlo junto con cada solicitud. Para ello, lo guardamos en una cookie .

Esto es lo que significa cada parte:

• res.cookie("token", token, {...}): Esto establece una cookie en el navegador del usuario. La cookie se llama "token"y almacena el JWT ( token).
• httpOnly: true:Esto significa que el JavaScript que se ejecuta en el navegador no puede acceder a la cookie. Es una función de seguridad para evitar que scripts maliciosos roben el token.
• sameSite: "strict": Esto ayuda a proteger contra ataques CSRF (falsificación de solicitud entre sitios) . Garantiza que la cookie solo se envíe cuando el usuario interactúa directamente con su sitio (no cuando se lo engaña para que haga clic en un enlace de otro sitio).
• secure: process.env.NODE_ENV === "production":Esto garantiza que la cookie solo se envíe a través de conexiones HTTPS seguras en un entorno de producción. En el desarrollo, se puede enviar a través de HTTP para fines de prueba.
• maxAge: 7 * 60 * 60 * 1000:Esto establece el tiempo de expiración de la cookie en 7 días , al igual que el token.

¿Por qué es esto importante?

• La cookie es donde almacenamos el JWT para que el navegador pueda enviarlo automáticamente con cada petición. De esta forma, el servidor siempre sabe quién es el usuario sin que tenga que iniciar sesión nuevamente en cada carga de página.

Si omite este paso:

• Si no instala la cookie, el navegador no almacenará el token y el usuario deberá iniciar sesión nuevamente cada vez que actualice la página o visite una nueva página en su sitio. La sesión del usuario no se mantendrá y se cerrará la sesión constantemente.

El panorama más amplio: ¿Por qué utilizar JWT y cookies para la autenticación?

El uso de JWT y cookies para la autenticación tiene varias ventajas:

1. Autenticación sin estado : los JWT permiten que el servidor permanezca sin estado . Esto significa que el servidor no necesita almacenar datos de sesión para cada usuario. En cambio, el JWT se envía con cada solicitud y el servidor puede verificarlo rápidamente.
2. Seguridad : al utilizar una clave secreta para firmar el JWT, el servidor garantiza que el token no haya sido alterado. El almacenamiento del JWT en una cookie httpOnly agrega una capa adicional de seguridad, lo que evita que los scripts del lado del cliente accedan al token.
3. Comodidad para el usuario : una vez que el usuario inicia sesión, no necesita volver a ingresar sus credenciales cada vez que carga una nueva página o vuelve a visitar el sitio dentro de los 7 días.

¿Qué sucede si omite la autenticación JWT?

Resumamos lo que sucederá si omite la generación del token o su configuración en una cookie:

1. Sin token : si no genera un JWT, el servidor no sabrá quién es el usuario después de que inicie sesión. Como resultado, el usuario no podrá acceder a partes del sitio que requieren autenticación (como ver su perfil o realizar acciones como un usuario conectado).
2. Sin cookies : aunque se genere el token, si no se almacena en una cookie, el navegador no lo recordará. El usuario perderá su estado de autenticación después de actualizar la página o visitar una nueva página, y se lo tratará como si hubiera cerrado la sesión.

Conclusión

En esta publicación, hemos explorado los conceptos básicos de los JWT y las cookies para la autenticación de usuarios en aplicaciones web. El código que analizamos le ayuda a:

• Generar un JWT que pruebe la identidad del usuario.
• Almacene este token en una cookie para que el navegador del usuario lo envíe automáticamente con cada solicitud.

Al utilizar JWT y cookies, puede administrar de manera eficiente y segura las sesiones de usuario, permitiéndoles permanecer conectados y acceder a áreas protegidas de su sitio.

Pero la determinación no es el único activo que necesita un desarrollador. También se necesita información para depurar el código: ¿Cuáles son los síntomas y efectos del problema? ¿Cuál es su frecuencia? ¿Su generalización? ¿Su procedencia? La evidencia y los artefactos de un error (un volcado de memoria, un seguimiento de la pila, un registro o un caso de prueba) son invaluables.

Exploremos algunas técnicas y herramientas disponibles para los desarrolladores de Ruby y Rails para recopilar e investigar evidencia de un problema. Los datos no pueden reemplazar la tenacidad, pero pueden ayudar a facilitar sus esfuerzos (y ahorrarle sueño).

Utilice variables de entorno para optimizar sus herramientas en Rails

Rails ofrece algunas herramientas excelentes para examinar una aplicación en ejecución, incluido un registrador configurable para capturar diagnósticos propios y cualquier otro que desee agregar. Rails también ofrece un registro de consultas detallado para identificar el origen de las consultas de la base de datos y un registro de puesta en cola detallado para indicar dónde se ponen en cola los trabajos en segundo plano. Los dos últimos registros están habilitados de forma predeterminada en el entornodevelopment; puede habilitar ambos en otros entornos con dos instrucciones.

Una opción de registro menos conocida disponible desde Rails 7 anota cada consulta SQL con comentarios. Si agrega lo siguiente a config/application.rbcualquier archivo de entorno:

El registro de consultas se modifica automáticamente con el nombre de la aplicación, el nombre del controlador, el nombre de la acción o el nombre del trabajo en segundo plano. El siguiente ejemplo de salida proviene directamente de la guía de depuración de Rails :

Probablemente no desee habilitar todas estas funciones en producción. La generación de registros puede resultar costosa en términos de memoria y tiempo (recursos limitados para una aplicación bajo carga).

Sin embargo, existen excepciones. Es posible que desee habilitar brevemente una función a pedido, especialmente al depurar en los modos de desarrollo y prueba. En lugar de modificar el código (y quizás volver a implementarlo) para habilitar o deshabilitar un diagnóstico, use variables de entorno para controlar el estado. En algunos entornos, como Heroku, cambiar la configuración de una variable de entorno no obliga a una nueva implementación.

Por ejemplo, puede definir un conjunto de variables para controlar el registro y el nivel de detalle.

Para mayor comodidad, cree una clase pequeña para consultar la configuración.

Ahora use las variables y el código para configurar las funciones de registro en config/application.rb:

Utilice su shell, un archivo dotenv, su integración continua o su plataforma de alojamiento e implementación para configurar cada opción. También puede utilizar una función a pedido. Simplemente inicie la aplicación con la variable de entorno definida en la línea de comandos.

Pon a punto a Puma para el desarrollo

Basándonos en la sección anterior, veamos cómo usar variables de entorno para adaptar la configuración de Puma para la depuración en el entorno de desarrollo.

Por lo general, Puma está configurado para maximizar el rendimiento en producción, ejecutando varios trabajadores y muchos subprocesos por trabajador. En desarrollo, se desea lo opuesto: un trabajador, un subproceso y un tiempo de espera muy largo para permitir la depuración interactiva. Cada uno de ellos es un parámetro que se puede ajustar.

Modificar config/puma.rbpara reflejar el siguiente código.

Ahora puede configurar las tres variables de entorno para controlar Puma en cada entorno. En el desarrollo, configure los valores para optimizar la depuración interactiva.

Si desea validar la configuración de Puma, configure la variable de entorno PUMA_LOG_CONFIG=truee inicie la aplicación. Puma emite su configuración activa al iniciarse.

Casualmente, la configuración predeterminada de Puma en la versión más reciente de Rails es similar a la que se muestra aquí (gracias a Nate Matykiewicz por el dato).

Ejecutar trabajos en segundo plano en línea

Una aplicación Rails de cualquier complejidad normalmente aprovecha los trabajos en segundo plano para ejecutar tareas que requieren un uso intensivo de recursos informáticos y que requieren una ejecución (relativamente) prolongada. Los trabajos en segundo plano se ejecutan de forma asincrónica, desconectados del ciclo de solicitud/respuesta. Los candidatos ideales para el procesamiento "fuera de banda" incluyen la generación de informes, el envío de correos electrónicos y la interacción con API de terceros. Pero la naturaleza asincrónica de los trabajos también complica la depuración.

Para simplificar la resolución de problemas, ejecute los trabajos inmediatamente en sus entornos de desarrollo y prueba locales. En el modo inmediato, los trabajos no se ponen en cola, sino que se ejecutan instantáneamente. Al ejecutarlos en "primer plano", puede establecer puntos de interrupción e inspeccionar el estado de forma interactiva.

Veamos un ejemplo en el que se utiliza Delayed Job , un backend de cola popular y fácil de administrar para Active Job . Delayed Job proporciona una configuración para habilitar la cola. De manera predeterminada, la configuración es truey los trabajos se ponen en cola como de costumbre. Sin embargo, si se configura en false, los trabajos se ejecutan inmediatamente.

Agregue el siguiente código a su aplicación en config/initializers/delayed_job.rb:

Si DELAYED_JOBS_DISABLE_JOB_QUEUESse establece en cualquier valor, se deshabilita la cola. Si la variable de entorno está en blanco o no está definida, se habilita la cola.

A continuación, en su shell, en la línea de comandos o en sus archivos dot, configúrelo
DELAYED_JOBS_DISABLE_JOB_QUEUESsegún sea necesario.

Establezca la variable de entorno en nada o elimine la variable de entorno para restaurar la puesta en cola.