Gestione dei dati di sessione webapp / del controller per più tabs

Ho un’applicazione web Java che memorizza alcuni dati nella sessione. I dati nella sessione cambiano man mano che l’utente interagisce con l’applicazione (ad esempio, il stream è gestito da un controller, ciascun controller ha diverse pagine di moduli, in ogni pagina di modulo alcuni dati vengono aggiornati nella sessione e il stream passa alla pagina successiva del modulo).

Il problema è che alcuni utenti stanno aprendo più di una scheda per l’applicazione, ciascuna scheda con un passo diverso nel stream. A questo punto i dati nella sessione sono incasinati poiché le tabs condividono la stessa sessione (l’app utilizza le sessioni gestite dai cookie).

Dire agli utenti di utilizzare browser diversi per evitare di condividere lo stesso ID di sessione (ad esempio una finestra di Firefox e una finestra di IE) non è un’opzione, perché sicuramente a un certo punto qualcuno si dimenticherà di farlo e invece di usare le tabs, quindi incasinando i propri dati.

L’aggiunta di alcune verifiche che rilevano che un altro stream è richiesto da un’altra scheda e visualizza un messaggio all’utente che dice che questo non è permesso non è un’opzione in quanto fa pisciare gli utenti e non vogliamo che lo facciamo noi? : D

Il fatto è che l’utilizzo di un’altra scheda è utile per gli utenti perché sono più efficienti in quello che usano per l’applicazione, quindi sto mantenendo questa opzione. Ma la domanda ora è quanto è meglio gestire i dati di una sessione per le altre tabs?

Quello che ho pensato, era avere il controller generare un token quando avvia il stream e passare questo token a ogni pagina del modulo che a sua volta lo rimanda per identificarsi. Se un’altra scheda richiede la stessa azione del controller quando c’è un stream in corso, allora genera un altro token e lo passa in giro.

Fondamentalmente, voglio che ogni stream abbia un token e all’interno della sessione non manterrò solo un set di dati, ma avrò un set di dati per ciascun token e quindi abbineremo le richieste in base al token.

Ora il problema è che questo approccio richiederà molte riscritture per l’applicazione e mi chiedevo se esiste una buona pratica per gestire una situazione del genere o qualcuno può suggerire altri approcci. Sono aperto alle idee.

Hai incontrato questa situazione? Come lo hai gestito?

Questo di solito viene fatto assegnando un windowId per ogni tab / finestra e passandolo su ogni richiesta. Jsf lo supporta tramite l’ orchestra . Spring mvc lo supporterà nella prossima versione.

Di recente ho avuto bisogno di questo per un caso semplice, quindi l’ho implementato personalmente. Abbiamo impiegato mezz’ora. Tuttavia, il mio ambito era molto limitato:

  • passare una windowId con ogni richiesta e restituirla per la richiesta successiva. La prima volta: generalo.
  • per qualsiasi attributo che si desidera archiviare nella sessione, inserire una Map dove la chiave è windowId

Questo è esattamente ciò che Seam è stato creato per gestire. In Seam c’è un concetto chiamato Conversazione che fondamentalmente fa esattamente quello che stai spiegando. Le conversazioni sono fondamentalmente un modo per dividere la Sessione in molti pezzi che possono scadere in un certo timeout. Puoi guardare il codice sorgente per la class org.jboss.seam.core.Manager per vedere come è effettivamente implementato e ottenere ispirazione;)

A seconda della complessità dell’applicazione, è ansible esaminare le tabs di implementazione all’interno dell’applicazione. Questo ti dà il controllo totale sul stream, pur fornendo agli utenti le funzionalità che vogliono. Direi che è, bugwise, la soluzione più solida, dal momento che non si ha una dipendenza dal modo in cui il browser gestisce le sessioni, riducendo al minimo il numero di “sconosciute conosciute”.

Naturalmente, ci sarà potenzialmente un grosso costo iniziale a questo, a seconda di come è strutturata la tua applicazione. Senza ulteriori informazioni sulla tua app, sei la persona più adatta a decidere.

Puoi anche provare a racchiudere la tua applicazione in Adobe Air

E quindi limitare la tua applicazione web per essere accessibile solo da quest’aria. In questo modo non è necessario considerare la frammentazione del browser Web e il loro comportamento univoco.