Identificación de sesión de ASP.NET compartida entre las pestañas del navegador

Question

Recientemente he estado desarrollando un sitio web utilizando formularios web asp.net que se utiliza en las sesiones de proceso y noté que los identificadores de sesión se comparten entre las pestañas del navegador. Así que me preguntaba lo que haría para las siguientes situaciones:

Problema: inicio de sesión múltiple con diferentes usuarios en el problema de un navegador

1. abre usuario pestaña del navegador 1, nombres de usuarios con "usuario1" - almacenar en sesión
2. el usuario abre la pestaña del navegador 2, los inicios de sesión con "usuario 2" - tienda en sesión
3. en esta etapa la información de sesión ahora apunta a "usuario2" debido a la forma del ID de sesión se comparte am ongst navegador pestañas
4. usuario intenta una acción en la ficha 1 y de repente tienen "usuario2" información

¿Cómo alertar al usuario de la lengüeta 1 que el usuario ha cambiado o cómo forzar usuario Tab1 para desconectarse?

Mi idea inicial era mantener una lista de usuarios activos con ID de sesión a través de la base de datos u objeto de aplicación, pero el problema es que en la pestaña 1 comparto la lista cuando hago una solicitud la HttpContext.Current.User se actualizaría con "Usuario 2", ¿cómo sé pestaña del navegador 1 fue inicialmente para "usuario1"

Apreciar a nadie que me deja saber de cualquier alternativa o mejores prácticas para el problema anterior

Saludos DotnetShadow

Answer 1

¿Por qué no avisas cuando el usuario2 inicia sesión? Con un mensaje como "Ya inició sesión como usuario1, ¿está seguro de que desea volver a iniciar sesión como otro usuario?"

Answer 2

Así es como es. No puedes hacer mucho al respecto. Los usuarios ahora están acostumbrados a este comportamiento, ya que es coherente entre los sitios de Internet famosos, como gmail, etc ... por lo que no debería ser un gran problema para ellos.

Answer 3

Todas las pestañas de un navegador pertenecen a la misma instancia, por lo que todas las pestañas comparten cookies y sesiones, no hay mucho que pueda hacer al respecto. Si desea implementar esto mal, la única solución que se le viene a la mente es llevar una identificación de sesión única con cada URL. En función de esa identificación única, puede vincular a un usuario específico. Necesitará personalizar la lógica de la sesión y deberá asegurarse de que todos los enlaces en su sitio web lleven esta identificación única. Se podría hacer con mucho esfuerzo, pero la verdadera pregunta es, ¿vale la pena hacerlo?

Answer 4

Lo que hago para evitar este problema es redireccionar para agregar un identificador de inicio de sesión corto, aleatorio en la url.

Luego, en lugar de usar la sesión directamente, almaceno un objeto fuertemente tipado en los valores de sesión bajo el código aleatorio en url, y uso ese objeto para el almacenamiento de la sesión. Si desea mantenerlo simple, podría usar un diccionario. Además del tiempo de espera de sesión normal, debe hacer un seguimiento del último uso dentro de cada id de inicio de sesión y agotar el tiempo de espera manualmente si es demasiado viejo para evitar que los nuevos usuarios mantengan los inicios de sesión antiguos con vida.

Básicamente, cada sesión ASP.NET corresponde a cualquier número de sesiones de inicio de sesión.

Esto tiene las siguientes ventajas:

• Usted puede de registro en forma de múltiples usuarios simultáneamente. Es útil para muchos sitios.
• En terminales públicas, ayuda a evitar el secuestro accidental de la sesión. Cuando un usuario abandona un terminal público, cierra la pestaña de aplicaciones web pero no el navegador (que es bastante común) y otra persona se acerca a ese terminal y abre una nueva ventana o pestaña en su sitio, este nuevo usuario no ve rastro de lo previamente registrado en usuario Por supuesto, los usuarios deben cerrar sesión, y cualquiera puede inspeccionar el historial, pero no hay razón para invitar abuso.
• CSRF ataques contra su sitio son un poco más difíciles ya que una url sin la identificación de acceso aleatorio no tiene sentido.
• La implementación es bastante simple si usa una tabla hash; después de todo, cualquier usuario de sesión ya está escrito para almacenar y recuperar datos de una tabla hash, solo necesita cambiar la tabla hash que está usando e idealmente debería incluir un tiempo de espera personalizado.

El inconveniente obvio es que debe incluir el código aleatorio en la url; y que necesitas un poco de implementación adicional. Puede ocultar el código adicional usando un iframe y/o un sitio basado en javascript + XHR, pero hacerlo es un cambio mucho más invasivo en un sitio. Finalmente, tenga en cuenta que las sesiones sin cookies no son lo mismo; aunque son más fáciles de activar, implican un token de URL mucho más largo y menos humano, y al carecer del token de sesión de cookie normal, también son menos seguros que el secuestro de sesión (ya que de repente cualquier otro programa o incluso una máquina que descubre el ID de sesión puede pretender ser ese usuario).

Answer 5

Algunos han sugerido agregar uniquifiers en la URL y el seguimiento basado en ellos.

Si va a hacer esto, también puede dejar que ASP.Net haga esto por usted activando cookieless sessions - luego usa la URL para contener la ID de la sesión.

Answer 6

¿Qué tal si almacenamos los datos en viewstate? Eso sería exclusivo de cada ventana.