¿Cómo diferenciar las sesiones en las pestañas del navegador?


135

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.



1
Esto es algo que el usuario debe hacer: abrir IE, hacer clic en "Archivo-> Nueva sesión"
Stefan Steiger

3
@Quandary, su solución no es una solución genérica (en otros navegadores no funciona) y, lo más importante, no es fácil de usar (los usuarios no conocen las sesiones).
Oriol Terradas

2
Algunas personas parecen incapaces de imaginar cuál es el propósito de esto. El dominio del problema es casi cualquier situación en la que desee permitir diferentes "vistas" de su sitio web. Una vez que el usuario puede tener más de una vista de su sitio web, inevitablemente anhelan (o intentan accidentalmente) acceder a dos vistas diferentes al mismo tiempo. Los ejemplos incluyen: versiones temporales (cambiar a ver el sitio web tal como existía en cierto punto en el pasado); sandboxing (realizar cambios en el sitio web que otros aún no pueden ver); vistas basadas en roles (vea cómo se ve el sitio web para usuarios menos privilegiados); etc.
Ron Burk

Respuestas:


92

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.

Los datos almacenados mediante sessionStorage no persisten en las pestañas del navegador, incluso si dos pestañas contienen páginas web del mismo origen de dominio. En otras palabras, los datos dentro de sessionStorage se limitan no solo al dominio y al directorio de la página de invocación, sino a la pestaña del navegador en la que está contenida la página. Compare eso con las cookies de sesión, que persisten los datos de pestaña a pestaña.


77
De los documentos: "Los datos almacenados usando sessionStorage no persisten en las pestañas del navegador, incluso si dos pestañas contienen páginas web del mismo origen de dominio. En otras palabras, los datos dentro de sessionStorage se limitan no solo al dominio y al directorio de la página de invocación, sino a la pestaña del navegador en la que está contenida la página. Compare eso con las cookies de sesión, que persisten los datos de una pestaña a otra ". Las pruebas simples confirman este comportamiento en Chrome y FF.
jswanson

21
Tenga en cuenta que la ID se duplicará cuando use la función "Duplicar pestaña" de Chrome. Esto generalmente no es un problema, pero debe pensarse bien.
JosiahDaniels

Excepto cuando "Duplica" una pestaña en Chrome o Firefox. En este caso, SessionStorage se copia.
Tiago Freitas Leal

@Gonzalo Gallotti: ¿Y cómo me ayudará eso si la sesión es del lado del servidor? )))
Stefan Steiger

@StefanSteiger. Luego puede enviar la identificación de BrowserTab (guardada en el Almacenamiento de sesión) con su Llamada Ajax. En el lado del servidor necesitará una lógica personalizada, porque la WebSession es la misma. Pero puede crear un HashMap con objetos de sesión por pestaña.
Gonzalo Gallotti

23

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:

  • Galletas. El método más limpio y más popular, pero significa que todas las pestañas y ventanas del navegador de un usuario comparten la sesión: en mi opinión, esto es realmente deseable, y estaría muy molesto en un sitio que me hizo iniciar sesión para cada nueva pestaña, ya que usar pestañas muy intensamente
  • Reescritura de URL. Cualquier URL en el sitio tiene una ID de sesión adjunta. Esto es más trabajo (debe hacer algo en todas partes donde tenga un enlace interno del sitio), pero hace posible tener sesiones separadas en pestañas diferentes, aunque las pestañas abiertas a través del enlace aún compartirán la sesión. También significa que el usuario siempre debe iniciar sesión cuando visita su sitio.

¿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.


66
Es para una gran aplicación que mantiene la información del usuario y el entorno. Cuando alguien inicia sesión con diferentes usuarios en diferentes pestañas, para pruebas o para diferentes roles, entonces está cruzando la información de las pestañas.
Oriol Terradas

Solo un complemento muy tardío, en cuanto a por qué: porque necesito saber esto para saber EN QUÉ página de mi sitio, por ejemplo, un usuario está enfocado, y no solo que han ido de una página a otra ( en su lugar, fueron de pestaña en pestaña).
Oliver Williams el

16

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).


3
window.sessionStorage también lo hace
felickz

3
cuidado como almacenamiento sesión se copia en una nueva pestaña cuando el usuario elige "Abrir en nueva pestaña" ... gustaría tener acoplamiento para los detalles, pero ver: bugzilla.mozilla.org/show_bug.cgi?id=818389
felickz

2
Tenga en cuenta que lo que guarde en la configuración de window.name seguirá estando disponible en otros dominios, cuando el usuario cambie a otras páginas en la misma pestaña.
nakib

15

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.


9
Es para una gran aplicación que mantiene la información del usuario y el entorno. Cuando alguien inicia sesión con diferentes usuarios en diferentes pestañas, para pruebas o para diferentes roles, entonces está cruzando la información de las pestañas.
Oriol Terradas

38
antigua respuesta, lo sé, pero el correo de Google le permite tener diferentes cuentas por pestaña y no es una "aplicación totalmente inutilizable"
George

2
@George, la respuesta sigue siendo correcta, y para su ejemplo, verá en el número de url el índice de cuentas almacenadas en cookies, google mail solo almacena todas las cookies y selecciona una de acuerdo con la url.
Mhmd

55
No estoy seguro de que la respuesta siga siendo correcta, claramente puedes hacerlo. Gmail lo hace. En cuanto a cómo lo hace, puede que no sea elegante, pero funciona y eso es lo importante
George

2
Respuesta anterior, pero puedo agregar que Whatsapp y Telegram no le permiten tener dos pestañas abiertas al mismo tiempo. Esto no los hace inutilizables
Charlie

13

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 ...


66
¡+1 porque te tomaste el tiempo para pensarlo realmente! :-) Mirando todas las advertencias, sabes que es una mala idea. Lo que aprendí de estas cosas es entender realmente qué datos deberían entrar en las sesiones y qué datos no deberían.
Peter

10

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.

23423.abc.com
242234.abc.com
235643.abc.com

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.


3
Esto parece una alternativa inteligente a la reescritura de URL. Terminas con la variable deseada (ID de sesión) en un lugar compatible con HTTP que es visible pero no molesto. Nits que recuerdan: 1) necesitan comodines en DNS, obviamente, 2) todo su sitio web debe evitar cualquier URL absoluta que dirija al usuario de regreso (por ejemplo) al subdominio "www", 3) probablemente quiera mantener a rastreadores web , pero esta es probablemente una situación de web privada, por lo que ya se puede hacer. ¡Gracias por compartir esto!
Ron Burk

@ user3534653: Me gusta el enfoque. Pero dijiste "no hay programación involucrada". Luego continúas diciendo "con un pequeño cambio de código". Entonces, ¿realmente, un pequeño cambio de código no es programación? ;) Además, este enfoque podría no funcionar si tiene varias aplicaciones con enlaces canónicos donde el dominio está codificado / configurado (canónicamente).
Stefan Steiger

5

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:

//Events 
$(window).ready(function() {generateWindowID()});
$(window).focus(function() {setAppId()});
$(window).mouseover(function() {setAppId()});


function generateWindowID()
{
    //first see if the name is already set, if not, set it.
    if (se_appframe().name.indexOf("SEAppId") == -1){
            "window.name = 'SEAppId' + (new Date()).getTime()
    }
    setAppId()
}

function setAppId()
{
    //generate the cookie
    strCookie = 'seAppId=' + se_appframe().name + ';';
    strCookie += ' path=/';

    if (window.location.protocol.toLowerCase() == 'https:'){
        strCookie += ' secure;';
    }

    document.cookie = strCookie;
}

lado del servidor (C # - por ejemplo)

//variable name 
string varname = "";
HttpCookie aCookie = Request.Cookies["seAppId"];
if(aCookie != null) {
     varname  = Request.Cookies["seAppId"].Value + "_";
}
varname += "_mySessionVariable";

//write session data 
Session[varname] = "ABC123";

//readsession data 
String myVariable = Session[varname];

Hecho.


1
Realmente me gusta tu respuesta simplificada y la referencia de la navaja de Occam. Solo quería verificar que esta solución aún funcione para usted.
Jeff Marino

1
Vale la pena notar que si la actualización de la página debe mantener su sesión, este enfoque no funcionaría. El otro enfoque sugerido en otra respuesta de usar window.sessionStorage me parece más razonable.
rosenfeld

@quijibo Todavía funciona perfectamente en mi aplicación, sí. En cuanto a la actualización de la página, puede ser cierto para algunos navegadores, el uso de window.sessionStorage puede resolver el problema, no lo he probado
Mike A.

3
¿Cuál es la función "se_appframe ()"?
AndreMiranda

¿Qué es se_appframe ?
Kiquenet

2

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.


2
Creo que reescribir enlaces para codificar sesiones es tedioso y propenso a errores. Tengo una gran aplicación, con muchos enlaces, necesito una solución transparente o fácil de implementar.
Oriol Terradas

2

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



1

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.




1

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:

<form method="post" action="/handler">

  <input type="hidden" name="sessionId" value="123456890123456890ABCDEF01" />
  <input type="hidden" name="action" value="" />

</form>

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:

<input type="hidden" name="action" value="completeCheckout" />
<input type="hidden" name="data" value='{ "cardNumber" : "4111111111111111", ... ' />

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:

  • Sin dependencia de JavaScript o HTML5.
  • Inherentemente protege contra CSRF .
  • No depende de las cookies, por lo que protege contra POODLE .
  • No vulnerable a la fijación de la sesión .
  • Puede evitar el uso del botón de retroceso, lo cual es deseable cuando desea que los usuarios sigan una ruta establecida a través de su sitio (lo que significa que pueden evitarse errores lógicos que a veces pueden ser atacados por solicitudes fuera de orden).

Algunas desventajas:

  • Se puede desear la funcionalidad del botón Atrás.
  • No es muy efectivo con el almacenamiento en caché ya que cada acción es una POST.

Más información aquí .


1

Resolví esto de la siguiente manera:

  • Le he asignado un nombre a la ventana, este nombre es el mismo del recurso de conexión.
  • más 1 para deshacerse de la cookie almacenada para conectar la conexión.
  • He creado una función para capturar toda la respuesta de salida xml y asignar sid y deshacerse de las cookies en formato json. Hago esto para cada window.name.

aqui el codigo:

var deferred = $q.defer(),
        self = this,
        onConnect = function(status){
          if (status === Strophe.Status.CONNECTING) {
            deferred.notify({status: 'connecting'});
          } else if (status === Strophe.Status.CONNFAIL) {
            self.connected = false;
            deferred.notify({status: 'fail'});
          } else if (status === Strophe.Status.DISCONNECTING) {
            deferred.notify({status: 'disconnecting'});
          } else if (status === Strophe.Status.DISCONNECTED) {
            self.connected = false;
            deferred.notify({status: 'disconnected'});
          } else if (status === Strophe.Status.CONNECTED) {
            self.connection.send($pres().tree());
            self.connected = true;
            deferred.resolve({status: 'connected'});
          } else if (status === Strophe.Status.ATTACHED) {
            deferred.resolve({status: 'attached'});
            self.connected = true;
          }
        },
        output = function(data){
          if (self.connected){
            var rid = $(data).attr('rid'),
                sid = $(data).attr('sid'),
                storage = {};

            if (localStorageService.cookie.get('day_bind')){
              storage = localStorageService.cookie.get('day_bind');
            }else{
              storage = {};
            }
            storage[$window.name] = sid + '-' + rid;
            localStorageService.cookie.set('day_bind', angular.toJson(storage));
          }
        };
    if ($window.name){
      var storage = localStorageService.cookie.get('day_bind'),
          value = storage[$window.name].split('-')
          sid = value[0],
          rid = value[1];
      self.connection = new Strophe.Connection(BoshService);
      self.connection.xmlOutput = output;
      self.connection.attach('bosh@' + BoshDomain + '/' + $window.name, sid, parseInt(rid, 10) + 1, onConnect);
    }else{
      $window.name = 'web_' + (new Date()).getTime();
      self.connection = new Strophe.Connection(BoshService);
      self.connection.xmlOutput = output;
      self.connection.connect('bosh@' + BoshDomain + '/' + $window.name, '123456', onConnect);
    }

Espero ayudarte


0

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:

  1. Si el usuario navega a la pantalla de inicio de sesión, verifique si hay una sesión existente. Si existe, omita la pantalla de inicio de sesión y envíela a la pantalla de bienvenida.
  2. Si el usuario (en mi caso) navega a la pantalla de inscripción, verifique si hay una sesión existente. Si existe, informe al usuario que cerrará sesión. Si están de acuerdo, cierre sesión y comience la inscripción.

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.


0

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.


1
Esto probablemente esté bien, pero en teoría es inseguro. Algunos sistemas operativos (por ejemplo, Windows) tienen una granularidad de marca de tiempo muy gruesa, lo que significa que puede buscar la marca de tiempo varias veces y recuperar el mismo valor. Además, si vuelve a abrir un navegador después de un bloqueo y vuelve a abrir todas las pestañas a la vez, es posible que obtengan la misma marca de tiempo.
Gili

0
How to differ sessions in browser-tabs?

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.


0

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


0

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


0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.