java - persistenttokenrepository - ¿Por qué recordarme token?
security remember me (5)
Al implementar la función "recordarme" para un sitio web, ¿por qué complicamos las cosas y tenemos un token llamado recordarme token aparte de un token de sesión?
Según mi entender, recuerden que token se puede usar para iniciar sesión y crear un token de sesión nuevo, mientras que el token de sesión solo dura unos minutos o hasta que el usuario cierra el navegador. ¿Por qué no podemos aumentar la duración de caducidad del token de sesión al tiempo deseado hasta el que queremos que el usuario inicie sesión?
Tengo la necesidad de implementar dicha funcionalidad en una aplicación basada en flex corriendo sobre tomcat y me pregunto la necesidad de recordar tokens
Además, ¿es posible obtener esta funcionalidad de la caja dentro de tomcat?
Porque, por definición, una sesión finaliza tan pronto como el usuario cierra su navegador. Por lo tanto, la cookie de sesión caducará tan pronto como se cierre el navegador.
Como el objetivo de la función de recordarme es mantener al usuario conectado a través de las sesiones, la información almacenada en la cookie de recordarme debe permanecer en todos los reinicios del navegador.
Para obtener esta funcionalidad "de fábrica", consulte el uso de un marco como Spring Security .
1) Las sesiones suelen contener un montón de datos distintos al nombre de inicio de sesión del usuario. Por lo tanto, si establece la fecha de vencimiento en unas pocas semanas o meses, como un token de recordarme, probablemente se encuentre con problemas de rendimiento en el servidor debido a miles o millones de objetos de sesión pesados.
2) Recuerde que los tokens son del lado del cliente, no del lado del servidor. Esto pone todos los requisitos de almacenamiento en el navegador del usuario, que es una mejor solución para datos simples como nombres de inicio de sesión. Si confió en las ID de sesión vinculadas a objetos en memoria en el servidor, cada vez que reinicie su servidor o el proceso del servidor (para implementar una aplicación actualizada, por ejemplo), todos esos objetos de sesión se perderán.
Las cookies Remember-me generalmente almacenan el nombre de usuario y algún tipo de token. Ambos se usan para autenticar al usuario. Eche un vistazo a Mejores prácticas de cookies de inicio de sesión mejorado que describe el proceso bastante bien.
La cookie de sesión se usa para almacenar una ID de sesión en el cliente, lo que le permite al servidor reconocer una sesión y cargar los datos de la sesión asociados a la sesión.
Así que recuerde que las cookies tienen una vida más larga (generalmente días o semanas) que las cookies de sesión. Las cookies de sesión generalmente caducan después de unos minutos o cuando el navegador está cerrado.
Desde lo más alto de mi cabeza hay algunas razones por las cuales se usan dos cookies diferentes:
- Si solo se utilizara la cookie persistente "remember-me", el servidor necesitaría autenticar al usuario con cada solicitud. Cuando se utiliza una cookie de sesión adicional, el servidor no tiene que hacer esto mientras la sesión sea válida. Por supuesto, la ID de la sesión podría almacenarse dentro de la cookie Remember-me, pero ¿de qué sirve hacer eso?
- Desde el punto de vista de la codificación, es mejor reutilizar el mecanismo de sesión existente. ¿Por qué reinventar la rueda en lugar de simplemente agregar una función (autenticación a través de la cookie recordar-me) que se puede activar / desactivar fácilmente?
La gente ha dicho correctamente que la sesión contiene varios objetos pesados. Con suficientes usuarios en su sistema, si trata de mantenerlos todos en la cantidad finita de memoria que tiene el servidor, con el tiempo se bloqueará el servidor cuando se agote esa memoria.
Trabajé en un proyecto una vez donde una actualización del código de producción tenía una pérdida de memoria. Era un proyecto J2EE (sí J2EE no Java EE). Cuando un usuario inició sesión para verificar su factura en esta compañía telefónica, la sesión del usuario no se publicó correctamente desde la memoria (no recuerdo la causa, pero ese fue definitivamente el problema). Este error imita a propósito de lo que está preguntando.
El servidor siguió estrellándose. Así que le pusimos un perfilador. Veríamos cómo el uso de la memoria aumentaba a lo largo del día hasta que llegaba a su punto más alto y poco después de que el servidor de la aplicación fallara. Agregamos memoria e incrementamos la configuración de la memoria VM. Les dije que era una pérdida de memoria, pero como yo no era un "servidor experto" de $ 200.00 por hora, la gente no quería creerlo porque la gente que estaba allí todavía creía que el recolector de basura era todo poderoso en lugar de ser simplemente muy bueno.
Dos días más tarde (afectó el sistema "ver su factura", no el sistema comercial principal, es decir, no tenía la misma carga de trabajo o los mismos requisitos de memoria a pesar de tener mucha memoria de hardware en los servidores), contrataron un par de Consultores de $ 200.00 por hora que después de un día les dijeron que la aplicación tenía la pérdida de memoria antes mencionada. Fue arreglado y todo estuvo bien ... menos los honorarios de los consultores.
En cualquier caso, aquí está la conclusión: si no finaliza las sesiones de usuario cuando los usuarios cierran sesión o cierran su navegador (tiempo de espera de sesión), corre un riesgo real de agotar su memoria y bloquear sus servidores. Especialmente si su sitio o aplicación tiene una cantidad significativa de usuarios. Como lo mencionaron otros, los tokens / cookies ligeros son los mejores.
El motivo por el que deberíamos utilizar otra cookie que no sea la cookie sessionId para recordar al usuario no es porque las sesiones caduquen rápidamente o tenga problemas de rendimiento en el servidor.
Jetty (y probablemente muchos otros contenedores de servlets) tiene una característica que permite el desalojo automático de las sesiones inactivas de la memoria al disco o la base de datos que IMHO descarta todas las justificaciones anteriores sobre problemas de rendimiento que viene con el almacenamiento de sesiones pesadas en la memoria.
La razón por la que se utiliza otra cookie es que recuerde: me recuerda al usuario incluso después de que la sesión haya expirado. Entonces, si la sesión del usuario ha expirado, la otra cookie se usa para autenticar al usuario sin que tenga que ingresar una contraseña, lo que obviamente hace que los ataques de phishing sean menos probables. Aunque también hay desventajas, por ejemplo, si alguien obtiene acceso a su computadora portátil y roba sus tokens de autenticación, podría hacerse pasar por usted, a menos que el servidor aplique aún más medidas de seguridad para vincular el token a su cliente y ubicación únicamente.
En resumen, recordarme es un mecanismo de autenticación y no un reemplazo de las cookies de sesión.
Creo que está bien tener fechas de vencimiento de la sesión a largo plazo, siempre que estén almacenadas sin memoria. Y una vez que caduquen, simplemente solicite una contraseña. Muchos sitios web ofrecen esta característica como "Recordarme durante 30 días", que se logra simplemente mediante el uso de una cookie sessionId a largo plazo, nada más.