Problème de partage de session

Question

Je rencontre un problème lorsque nous utilisons plusieurs onglets depuis le partage de la même session. Des alternatives à cela? Pouvons-nous créer une session unique lorsque quelqu'un utilise l'onglet ou CTRL + N.

C'est une application d'entreprise Java EE/Struts2 si cela est important.

Answer 1

Il n'y a pas de moyen simple d'y parvenir que je connaisse.

La manière habituelle de résoudre ce problème consiste à modifier l'application afin qu'elle puisse traiter les utilisateurs utilisant plusieurs onglets (si possible). Il existe plusieurs solutions de contournement pour désactiver l'ancienne fenêtre si l'utilisateur appuie sur Ctrl + N en parcourant un formulaire en plusieurs étapes, mais vous devrez fournir des informations plus détaillées pour trouver des idées à ce sujet.

Answer 2

Habituellement, une instance de navigateur est traitée comme un seul utilisateur/entité à des fins de suivi de session. Surtout si vous utilisez des cookies pour suivre les sessions. Je ne suis pas sûr que j'aime l'idée de permettre à différents onglets d'avoir différentes sessions. Cela semble peu intuitif pour les applications Web. Tout à mon humble avis, bien sûr. Cela dit, si vous voulez changer cela, vous devrez créer une implémentation personnalisée. Vous pouvez peut-être générer et associer différents identifiants de session à l'URL pour différents onglets. Je n'ai jamais essayé cela moi-même, donc je ne sais pas si c'est facile ou difficile.

Answer 3

Ceci est un problème auquel sont confrontées toutes les applications Web axées sur le serveur, ce n'est pas spécifique à Java EE. Le problème est que la plupart des navigateurs stockent les cookies par utilisateur, et non par onglet. En outre, ce comportement n'est généralement pas transparent pour l'utilisateur, ce qui ajoute à la confusion. Quelques solutions auxquelles je peux penser (bien qu'aucune d'elles ne soit vraiment satisfaisante):

• Hébergez l'application sous plus d'un URI. De cette façon, n'importe quel navigateur va stocker les cookies indépendamment, et par conséquent, vous avez une session par application.
• Propager des identifiants de session via un mécanisme différent, par ex. à travers l'URI. Ceci, cependant, a quelques avertissements - il expose l'ID de session à l'utilisateur, il crée des URIs laids, et il constitue un risque de sécurité (détournement de session et autres) lorsque les utilisateurs copient-collent ou mettent en signet l'URI actuel. stocker l'identifiant de session dans le lien).
• Propagez des ID de session via des champs masqués dans la page. Cette solution vous oblige probablement à réécrire une partie de la gestion de session intégrée et perd l'ID de session lorsque votre page contient des liens vers d'autres pages de votre application.
• Pour Firefox, il existe un module appelé «cookie pie», qui permet aux utilisateurs d'avoir des magasins de cookies indépendants pour certains ou tous les onglets. L'inconvénient est que les utilisateurs doivent activement l'activer, et le travail autour du problème de tabulation devient la responsabilité de l'utilisateur. En outre, cela ne fonctionne pas dans toutes les circonstances (par exemple, google trouve votre connexion active indépendamment).
• Évitez d'utiliser l'état de session et utilisez d'autres mécanismes pour conserver l'état entre les demandes. Comme passer des identifiants de session à travers des champs cachés, cela casse dans certaines circonstances.
• Rendre l'application entièrement centrée sur le client, c'est-à-dire programmer l'ensemble de l'interface en javascript et communiquer avec le serveur via des appels ajax. De cette façon, vous ne dépendez pas du tout de l'implémentation du cookie du navigateur. Les chances sont que vous devrez réécrire des quantités substantielles de code, en supposant que votre application fonctionne déjà.