En una aplicación web implementada en Java usando JSP y Servlets; Si almaceno información en la sesión del usuario, esta información se comparte desde todas las pestañas del mismo navegador. ¿Cómo diferenciar las sesiones en las pestañas del navegador? En este ejemplo:
<%@page language="java"%>
<%
String user = request.getParameter("user");
user = (user == null ? (String)session.getAttribute("SESSIONS_USER") : user);
session.setAttribute("SESSIONS_USER",user);
%>
<html><head></head><body>
<%=user %>
<form method="post">
User:<input name="user" value="">
<input type="submit" value="send">
</form>
</body></html>Copie este código en una página jsp ( testpage.jsp), implemente este archivo en un contexto existente de una aplicación web en el servidor (uso Apache Tomcat), luego abra un navegador (FF, IE7 u Opera) usando la URL correcta ( localhost/context1/testpage.jsp), escriba su nombre en la entrada y envíe el formulario. Luego abra una nueva pestaña en el mismo navegador, y luego podrá ver su nombre (obtener de la sesión) en la nueva pestaña. Tenga cuidado con el caché del navegador, a veces parece que no sucede, pero está en el caché, actualice la segunda pestaña.
Gracias.
Respuestas:
Puede usar HTML5 SessionStorage (window.sessionStorage). Generará una identificación aleatoria y guardará en la sesión Almacenamiento por pestaña del navegador. Luego, cada pestaña del navegador tiene su propia identificación.
fuente
Debe darse cuenta de que las sesiones del lado del servidor son un complemento artificial de HTTP. Como HTTP no tiene estado, el servidor debe reconocer de alguna manera que una solicitud pertenece a un usuario en particular que conoce y para el que tiene una sesión. Hay 2 formas de hacer esto:
¿Qué intentas hacer de todos modos? ¿Por qué quieres pestañas para tener sesiones separadas? ¿Quizás hay una manera de lograr tu objetivo sin usar sesiones?
Editar: para realizar pruebas, se pueden encontrar otras soluciones (como ejecutar varias instancias de navegador en máquinas virtuales separadas). Si un usuario necesita actuar en diferentes roles al mismo tiempo, entonces el concepto de "rol" debe manejarse en la aplicación para que un inicio de sesión pueda tener varios roles. Tendrá que decidir si esto, usando la reescritura de URL, o simplemente viviendo con la situación actual, es más aceptable, porque simplemente no es posible manejar las pestañas del navegador por separado con sesiones basadas en cookies.
fuente
La propiedad Javascript window.name es lo único que persistirá en la actividad de la pestaña, pero puede permanecer independiente (en lugar de URL guff).
fuente
No deberías Si desea hacer algo así, debe obligar al usuario a usar una sola instancia de su aplicación escribiendo URL sobre la marcha, use una ID de sesión por igual (no sessionid, no funcionará) id y páselo en cada URL.
No sé por qué lo necesita, pero a menos que necesite hacer una aplicación totalmente inutilizable, no lo haga.
fuente
Se me ocurrió una nueva solución, que tiene un poco de sobrecarga, pero parece estar funcionando hasta ahora como un prototipo. Una suposición es que está en un entorno de sistema de honor para iniciar sesión, aunque esto podría adaptarse solicitando una contraseña cada vez que cambie de pestaña.
Use localStorage (o equivalente) y el evento de almacenamiento HTML5 para detectar cuándo una nueva pestaña del navegador ha cambiado qué usuario está activo. Cuando eso suceda, cree una superposición fantasma con un mensaje que indique que no puede usar la ventana actual (o deshabilite la ventana temporalmente, es posible que no desee que sea tan visible). Cuando la ventana recupera el foco, envíe un registro de solicitud AJAX el usuario vuelve a entrar.
Una advertencia para este enfoque: no puede hacer que se realicen llamadas AJAX normales (es decir, las que dependen de su sesión) en una ventana que no tiene el foco (por ejemplo, si tuvo una llamada después de un retraso), a menos que realiza manualmente una llamada de reinicio de sesión AJAX antes de eso. Entonces, realmente todo lo que necesita hacer es verificar primero su función AJAX para asegurarse de que localStorage.currently_logged_in_user_id === window.yourAppNameSpace.user_id, y si no, inicie sesión primero a través de AJAX.
Otra es la condición de la carrera: si puede cambiar las ventanas lo suficientemente rápido como para confundirlo, puede terminar con una secuencia relogin1-> relogin2-> ajax1-> ajax2, con ajax1 en la sesión incorrecta. Para evitar esto, inserte las solicitudes de inicio de sesión de AJAX en una matriz, y luego almacene y antes de emitir una nueva solicitud de inicio de sesión, cancele todas las solicitudes actuales.
Lo último que debes tener en cuenta es la actualización de ventanas. Si alguien actualiza la ventana mientras tiene una solicitud de inicio de sesión AJAX activa pero no completada, se actualizará en el nombre de la persona incorrecta. En este caso, puede usar el evento no estándar antes de la descarga para advertir al usuario sobre la posible confusión y pedirle que haga clic en Cancelar, mientras tanto, vuelva a emitir una solicitud de inicio de sesión AJAX. Entonces, la única forma en que pueden fallar es haciendo clic en Aceptar antes de que se complete la solicitud (o presionando accidentalmente enter / barra espaciadora, porque OK es, desafortunadamente para este caso, el predeterminado). Hay otras formas de manejar este caso, como detectar F5 y Ctrl + R / Alt + R presiona, lo que funcionará en la mayoría de los casos, pero podría verse frustrado por la reconfiguración de acceso directo del teclado del usuario o el uso alternativo del sistema operativo. Sin embargo, este es un caso marginal en realidad, y los peores escenarios nunca son tan malos: en una configuración de sistema de honor, se iniciaría sesión como la persona incorrecta (pero puede hacer obvio que este es el caso personalizando páginas con colores, estilos, nombres prominentemente mostrados, etc.); en una configuración de contraseña, la responsabilidad recae en la última persona que ingresó su contraseña para cerrar sesión o compartir su sesión, o si esta persona es realmente el usuario actual, entonces no hay infracción.
Pero al final tiene una aplicación de un usuario por pestaña que (con suerte) simplemente actúa como debería, sin tener que configurar necesariamente perfiles, usar IE o reescribir URL. Sin embargo, asegúrese de que sea obvio en cada pestaña quién ha iniciado sesión en esa pestaña en particular ...
fuente
Tuvimos este problema y lo resolvimos muy fácil. Me refiero a fácil porque no hay programación involucrada. Lo que queríamos era permitir que un usuario iniciara sesión en varias cuentas dentro de la misma ventana del navegador sin entrar en conflicto con las sesiones.
Entonces la solución fue subdominios aleatorios.
Entonces le pedimos a nuestro administrador del sistema que configure los certificados SSL para * .abc.com en lugar de abc.com. Luego, con un pequeño cambio de código, cada vez que un usuario intenta iniciar sesión, se registra en una pestaña con un número de subdominio aleatorio. para que cada pestaña pueda tener su propia sesión de forma independiente. También para evitar cualquier conflicto, desarrollamos el número aleatorio usando un hash o md5 de identificación de usuario.
fuente
Seré honesto aquí. . . todo lo anterior puede o no ser cierto, pero todo parece MUY complicado, o no aborda saber qué pestaña se está usando en el lado del servidor.
A veces necesitamos aplicar la navaja de Occam.
Aquí está el enfoque de Occam: (no, no soy Occam, murió en 1347)
1) asigne una identificación única del navegador a su página en carga. . . si y solo si la ventana aún no tiene una identificación (así que use un prefijo y una detección)
2) en cada página que tenga (use un archivo global o algo así) simplemente coloque el código para detectar el evento de enfoque y / o el evento de mouseover. (Usaré jquery para esta parte, para facilitar la escritura del código)
3) en su función de enfoque (y / o mouseover), configure una cookie con la ventana.
4) lea el valor de la cookie desde el lado del servidor cuando necesite leer / escribir datos específicos de la pestaña.
Lado del cliente:
lado del servidor (C # - por ejemplo)
Hecho.
fuente
Puede usar la reescritura de enlaces para agregar un identificador único a todas sus URL cuando comience en una sola página (por ejemplo, index.html / jsp / whatever). El navegador usará las mismas cookies para todas sus pestañas, por lo que todo lo que coloque en las cookies no será único.
fuente
Creo que lo que probablemente desee es mantener el estado de navegación en las pestañas y no crear específicamente una sola sesión por pestaña. Esto es exactamente lo que el marco de trabajo de Seam logra con su alcance / contexto de conversación. Su implementación se basa en el hecho de que una identificación de conversación se propaga con cada solicitud y crea la noción de una conversación en el lado del servidor, que es algo que se encuentra entre una sesión y una solicitud. Permite el control del flujo de navegación y la gestión del estado.
Aunque eso está dirigido principalmente a JSF, eche un vistazo y verifique si es algo de lo que puede tomar algunas ideas: http://docs.jboss.org/seam/latest/reference/en-US/html_single/#d0e3620
fuente
En javascript, ¿cómo puedo identificar de forma exclusiva una ventana del navegador desde otra que se encuentre en la misma sesión basada en cocina?
Esencialmente use window.name. Si no está configurado, configúrelo con un valor único y úselo. Será diferente en las pestañas que pertenecen a la misma sesión.
fuente
Otro enfoque que funciona es crear una identificación de ventana única y almacenar este valor junto con la identificación de la sesión en una tabla de base de datos. El id de la ventana que uso a menudo es entero (ahora). Este valor se crea cuando se abre una ventana y se reasigna a la misma ventana si la ventana se actualiza, se recarga o se envía a sí misma. Los valores de ventana (entradas) se guardan en la tabla local utilizando el enlace. Cuando se requiere un valor, se obtiene de la tabla de la base de datos basada en el enlace id de ventana / id de sesión. Si bien este enfoque requiere una base de datos local, es prácticamente infalible. El uso de una tabla de base de datos fue fácil para mí, pero no veo ninguna razón por la cual las matrices locales no funcionarían tan bien.
fuente
Desarrollé una solución a este problema recientemente usando Cookies. Aquí hay un enlace a mi solución. También he incluido un código de muestra de la solución usando ASP.NET, debería poder adaptarlo a JSP o Servelets si lo necesita.
https://sites.google.com/site/sarittechworld/track-client-windows
fuente
Spring Session admite múltiples sesiones en el mismo navegador. Mire las muestras y los detalles de implementación http://docs.spring.io/spring-session/docs/current/reference/html5/guides/users.html
fuente
Nota: La solución aquí debe hacerse en la etapa de diseño de la aplicación. Sería difícil diseñar esto más tarde.
Use un campo oculto para pasar el identificador de sesión .
Para que esto funcione, cada página debe incluir un formulario:
Cada acción de su lado, incluida la navegación, PUBLICA el formulario (configurando
actionsegún corresponda). Para las solicitudes "inseguras" , puede incluir otro parámetro, por ejemplo, que contenga un valor JSON de los datos que se enviarán:Como no hay cookies, cada pestaña será independiente y no tendrá conocimiento de otras sesiones en el mismo navegador.
Muchas ventajas, particularmente cuando se trata de seguridad:
Algunas desventajas:
Más información aquí .
fuente
Resolví esto de la siguiente manera:
aqui el codigo:
Espero ayudarte
fuente
He estado leyendo esta publicación porque pensé que quería hacer lo mismo. Tengo una situación similar para una aplicación en la que estoy trabajando. Y realmente se trata de probar más que la practicidad.
Después de leer estas respuestas, especialmente la dada por Michael Borgwardt, me di cuenta del flujo de trabajo que debe existir:
Esto resolverá el problema de que el usuario vea los datos de "otro usuario" en su sesión. Realmente no están viendo los datos de "otro usuario" en su sesión, realmente están viendo los datos de la única sesión que tienen abierta. Claramente, esto causa algunos datos interesantes, ya que algunas operaciones sobrescriben algunos datos de sesión y no otros, por lo que tiene una combinación de datos en esa única sesión.
Ahora, para abordar el problema de las pruebas. El único enfoque viable sería aprovechar las directivas de preprocesador para determinar si se deben utilizar sesiones sin cookies. Vea, al construir una configuración específica para un entorno específico, puedo hacer algunas suposiciones sobre el entorno y para qué se utiliza. Esto me permitiría técnicamente tener dos usuarios conectados al mismo tiempo y el probador podría probar múltiples escenarios desde la misma sesión del navegador sin cerrar sesión en ninguna de esas sesiones del servidor.
Sin embargo, este enfoque tiene algunas advertencias serias. No menos importante es el hecho de que lo que el probador está probando no es lo que se ejecutará en la producción.
Así que creo que tengo que decir que, en última instancia, es una mala idea.
fuente
Almacenar el timeStamp en window.sessionStorage si aún no está configurado. Esto le dará un valor único para cada pestaña (incluso si las URL son las mismas)
http://www.javascriptkit.com/javatutors/domstorage.shtml
https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage
Espero que esto ayude.
fuente
La forma más directa de diferenciar las sesiones en las pestañas del navegador es no permitir que su dominio particular establezca cookies. De esa manera, puede tener sesiones separadas desde pestañas separadas. Supongamos que no permite las cookies de este dominio: www.xyz.com. Abre la pestaña 1, inicia sesión y comienza a navegar. Luego abre la pestaña 2, y puede iniciar sesión como un mismo usuario o uno diferente; De cualquier manera, tendrá una sesión separada de la pestaña 1. Y así sucesivamente.
Pero, por supuesto, esto es posible cuando tienes control sobre el lado del cliente. De lo contrario, las soluciones prescritas por la gente aquí deberían aplicarse.
fuente
deberás hacer
1- almacena una cookie para la lista de cuentas
2- opcional almacenar una cookie por defecto
3- tienda para cada cuenta con su índice como acc1, acc2
4- ponga en la url algo que represente el índice de cuentas y si no, seleccionará el predeterminado como google mail domain.com/0/some-url >> 0 aquí representa el índice de cuentas también puede que necesite saber cómo usar urlwrite
5- cuando seleccione una cookie, selecciónela de acuerdo a su urlpath representa el índice de la cuenta
Saludos
fuente
Veo muchas implementaciones que tienen cambios en el lado del cliente para manipular las cookies de identificación de sesión. Pero, en general, las cookies de identificación de sesión deben ser HttpOnly, de modo que java-script no pueda acceder; de lo contrario, puede provocar el Secuestro de sesión a través de XSS
fuente
Si es porque cada pestaña ejecutará un flujo diferente en su aplicación, y mezclar ambos flujos causa problemas, entonces es mejor "Regionalizar" los objetos de la sesión, de modo que cada flujo use una región diferente de la sesión
Esta región se puede implementar de manera tan simple como tener diferentes prefijos para cada flujo, o el objeto de sesión contendrá varios mapas (uno para cada flujo), y usted usa esos mapas en lugar de los atributos de sesión, lo mejor sería extender su clase de sesión y úsalo en su lugar.
fuente