Tendrá que hacer un seguimiento del lado del servidor de estado de sesión para esto, y caducar las sesiones que no hayan tenido ninguna actividad en el último X número de segundos. Diga que X es 60 , lo que significa que forzará el cierre de sesión en cualquier sesión que no haya tenido ninguna actividad en el último minuto.
Si no desea que se cierre la sesión de los usuarios si no navegan a otra página dentro de cada minuto, podría tener un AJAX keep-alive que haga una solicitud a la página. Yo sugeriría usar X/2 segundos para esta verificación para permitir el tiempo de latencia de la red. Entonces, cada 30 segundos se activará su AJAX, enviando la cookie de sesión al servidor que actualizará el tiempo last action registrado en la sesión a la hora actual del servidor.
Aún puede implementar un temporizador de inactividad que vencería la sesión si, por ejemplo, recibe 15 minutos de keep-alives AJAX pero no hay solicitudes manuales del usuario.
Al final del día, debe darse cuenta de que esta es una situación controlada por el cliente, por lo que solo puede llevar esto hasta el momento. Por ejemplo, un usuario podría actualizar automáticamente la página utilizando un complemento del navegador para evitar el cierre de sesión automático.
algunos navegadores suspenden el código JavaScript para pestañas de fondo (o aplicaciones en dispositivos móviles).
Si esto es una preocupación, podría aumentar el valor de X . Si su aplicación es muy sensible, tal vez la educación del usuario sea la clave. Enseñe a sus usuarios que deben cerrar sesión cuando hayan terminado de usar su aplicación. Podría detectar si los usuarios están agotando el tiempo de espera o explícitamente desconectándose, y si es más frecuente el primero, podría mostrar un mensaje destacado en su sitio.
¿Qué hacen actualmente los sitios web de mayor seguridad en este espacio?
Hay una forma muy segura, sin embargo, esto debería implementarse desde el principio dentro de la arquitectura de su aplicación web y no se puede colocar simplemente. Aquí es donde los ID de sesión se colocan en campos de formulario ocultos en lugar de estar contenidos dentro de un Galleta. Sin embargo, deben enviarse por POST (es decir, en el cuerpo de la solicitud). El uso de esto en combinación con el almacenamiento en caché deshabilitado evitará que una sesión continúe entre los reinicios del navegador.
La desventaja de este enfoque es que cada acción de navegación es necesaria para enviar un formulario.
Por ejemplo, podríamos tener un formulario para manejar la navegación en cada página construida así:
<form method="post" action="/navigate">
<input type="hidden" name="navigationPage" />
<input type="hidden" name="sessionId" value="12345678" />
</form>
Al hacer clic en la navegación, JavaScript se ejecutará y establecerá navigationPage en el valor apropiado (por ejemplo, myAccount , orderHistory , etc.) y luego enviará el formulario. El /navigate URI verificará el sessionId y luego navegará a la página especificada en navigationPage si la sesión es válida. Usando este método, todas las páginas dentro de su sesión iniciada tendrán el mismo URI ( www.example.com/navigate en este caso).
Esto es más seguro que agregar un valor de cadena de consulta en el sentido de que la ID de la sesión no se filtrará en los encabezados referer en el caso de los enlaces externos. Los enlaces externos pueden simplemente vincularse directamente al recurso y no serán la forma POST que utiliza la navegación interna.
Muchos sistemas bancarios emplean una técnica similar para una protección adicional contra el secuestro de sesiones dentro de la sesión. En estos escenarios, sessionId en el campo de formulario oculto se regenerará en cada carga de página, lo que garantiza que solo un navegador web navegue a la vez. Sin embargo, esto evitará el uso del botón Atrás porque obliga a volver a enviar los datos de la POST, o a abrir enlaces en pestañas separadas del navegador porque la ID no está actualizada en ambos lugares. Esto se usa a menudo en combinación con las cookies de sesión, pero se puede usar de forma aislada. Las acciones que requieren información adicional, como transferencias de dinero, pueden incluir simplemente campos de formulario adicionales que se enviarán con el formulario principal.
Otra ventaja de este enfoque es que es inherentemente seguro contra CSRF . Si otra página realiza una solicitud entre sitios, faltará el sessionId porque no se enviará automáticamente de la misma forma que las cookies.
Esto también se puede implementar en HTML solo sin JavaScript, donde cada botón de la página enviará un ID del navigationPage .
Este enfoque significa que también puedes mantener el tiempo de espera de tu sesión actual y no hay necesidad de un latido del corazón.