Administrar el flujo de datos / control de sesión de aplicación web para varias tabs

Tengo una aplicación web Java que almacena algunos datos en la sesión. Los datos en la sesión cambian a medida que el usuario interactúa con la aplicación (por ejemplo, un controlador controla el flujo, cada controlador tiene varias páginas de formulario, en cada página de formulario algunos datos se actualizan en la sesión y el flujo pasa a la siguiente página de formulario).

El problema es que algunos usuarios están abriendo más de una pestaña a la aplicación, cada pestaña con un paso diferente en el flujo. En este punto, los datos de la sesión están en mal estado ya que las tabs comparten la misma sesión (la aplicación usa sesiones administradas por cookies).

Decir a los usuarios usar diferentes navegadores para evitar compartir el mismo ID de sesión (por ejemplo, una ventana de Firefox y una ventana de IE) no es una opción, ya que seguramente en algún momento alguien olvidará hacerlo y en su lugar usará tabs, arruinando sus datos.

Agregar algunas verificaciones que detectan que se solicita otro flujo desde otra pestaña y mostrar un mensaje al usuario diciendo que esto no está permitido tampoco es una opción, ya que molesta a los usuarios y no queremos eso, ¿verdad? :RE

El hecho es que usar otra pestaña es útil para los usuarios porque son más eficientes en lo que utilizan para la aplicación, por lo que mantengo esta opción. Pero la pregunta ahora es ¿cuál es la mejor forma de administrar los datos de una sesión para las tabs más?

Lo que pensé fue que el controlador genere un token cuando comience el flujo y pase este token a cada página del formulario, que a su vez lo envía de vuelta para identificarse. Si otra pestaña solicita la misma acción de controlador cuando hay un flujo continuo, genere otro token y páselo.

Básicamente, quiero que cada flujo tenga un token y dentro de la sesión no solo mantendré un conjunto de datos, sino que tendré un conjunto de datos para cada token y luego uniré las solicitudes basadas en el token.

Ahora el problema es que este enfoque necesitará muchas reescrituras para la aplicación y me pregunto si existe una mejor práctica para manejar una situación así o si alguien puede sugerir otros enfoques. Estoy abierto a ideas.

¿Has encontrado esta situación? ¿Cómo lo manejaste?

Esto generalmente se hace asignando un identificador de ventana para cada pestaña / ventana y pasándolo en cada solicitud. Jsf apoya esto a través de la orquesta . Spring mvc lo apoyará en la próxima versión.

Recientemente necesité esto para un caso simple, así que lo implementé yo mismo. Tomó media hora. Sin embargo, mi scope era muy limitado:

  • pase un windowId con cada solicitud y devuélvala para la siguiente solicitud. La primera vez – generarlo.
  • para cualquier atributo que desee almacenar en la sesión, coloque un Map donde la clave sea windowId

Esto es exactamente lo que Seam fue creado para manejar. En Seam hay un concepto llamado Conversación que básicamente hace exactamente lo que estás explicando. Las conversaciones son básicamente una forma de dividir la sesión en muchas piezas que pueden caducar en algún momento. Puede ver el código fuente de la clase org.jboss.seam.core.Manager para ver cómo se implementa y cómo se inspira;)

Dependiendo de la complejidad de su aplicación, es posible que desee investigar la implementación de tabs dentro de su aplicación. Esto le brinda un control total sobre el flujo, a la vez que proporciona a los usuarios la funcionalidad que desean. Yo diría que es, en términos de errores, la solución más robusta, ya que no tendrá una dependencia en la forma en que el navegador maneja las sesiones, lo que minimiza la cantidad de “incógnitas conocidas”.

Por supuesto, potencialmente habrá un gran costo inicial para esto, dependiendo de cómo esté estructurada su aplicación. Sin más información sobre su aplicación, usted es la persona mejor colocada para decidir.

También puede intentar envolver su aplicación dentro de Adobe Air

Y luego limite su aplicación web para que solo sea accesible desde este air. Al hacer esto, no necesita considerar la fragmentación del navegador web y su comportamiento único.