J'ai trouvé une nouvelle solution, qui a un petit peu de frais généraux, mais semble fonctionner jusqu'à présent comme un prototype. Une hypothèse est que vous êtes dans un environnement système d'honneur pour vous connecter, bien que cela puisse être adapté en demandant à nouveau un mot de passe chaque fois que vous changez d'onglet.
Utilisez localStorage (ou équivalent) et l'événement de stockage HTML5 pour détecter lorsqu'un nouvel onglet de navigateur a changé l'utilisateur actif. Lorsque cela se produit, créez une superposition fantôme avec un message indiquant que vous ne pouvez pas utiliser la fenêtre actuelle (ou désactivez temporairement la fenêtre, vous ne voudrez peut-être pas qu'elle soit aussi visible.) Lorsque la fenêtre reprend le focus, envoyez une demande de journalisation AJAX l'utilisateur revient dans.
Une mise en garde à cette approche: vous ne pouvez pas avoir d'appels AJAX normaux (c'est-à-dire ceux qui dépendent de votre session) dans une fenêtre qui n'a pas le focus (par exemple si vous avez eu un appel après un délai), sauf si vous effectuez manuellement un appel de reconnexion AJAX avant cela. Donc, tout ce que vous avez à faire est de vérifier d'abord votre fonction AJAX pour vous assurer que localStorage.currently_logged_in_user_id === window.yourAppNameSpace.user_id, et si ce n'est pas le cas, connectez-vous d'abord via AJAX.
Une autre est les conditions de concurrence: si vous pouvez changer de fenêtre assez rapidement pour la confondre, vous pouvez vous retrouver avec une séquence relogin1-> relogin2-> ajax1-> ajax2, avec ajax1 étant fait sous la mauvaise session. Contournez ce problème en poussant les demandes de connexion AJAX sur un tableau, puis sur le stockage et avant d'émettre une nouvelle demande de connexion, abandonnez toutes les demandes en cours.
Le dernier problème à rechercher est l'actualisation de la fenêtre. Si quelqu'un actualise la fenêtre alors que vous avez une demande de connexion AJAX active mais pas terminée, elle sera actualisée au nom de la mauvaise personne. Dans ce cas, vous pouvez utiliser l'événement non standard beforeunload pour avertir l'utilisateur de la confusion potentielle et lui demander de cliquer sur Annuler, tout en réémettant une demande de connexion AJAX. Ensuite, la seule façon de le bâcler est de cliquer sur OK avant la fin de la demande (ou en appuyant accidentellement sur entrée / barre d'espace, car OK est - malheureusement pour ce cas - la valeur par défaut.) Il existe d'autres façons de gérer ce cas, comme détecter les pressions F5 et Ctrl + R / Alt + R, ce qui fonctionnera dans la plupart des cas mais pourrait être contrecarré par la reconfiguration des raccourcis clavier de l'utilisateur ou l'utilisation alternative du système d'exploitation. Cependant, c'est un peu un cas de pointe en réalité, et les pires scénarios ne sont jamais aussi mauvais: dans une configuration de système d'honneur, vous seriez connecté comme la mauvaise personne (mais vous pouvez rendre évident que c'est le cas en personnalisant les pages avec des couleurs, des styles, des noms bien en évidence, etc.); dans une configuration de mot de passe, il incombe à la dernière personne qui a entré son mot de passe de se déconnecter ou de partager sa session, ou si cette personne est en fait l'utilisateur actuel, il n'y a pas de violation.
Mais à la fin, vous avez une application à un utilisateur par onglet qui (espérons-le) agit comme il se doit, sans avoir à configurer nécessairement des profils, à utiliser IE ou à réécrire les URL. Assurez-vous de le rendre évident dans chaque onglet qui est connecté à cet onglet particulier, cependant ...