[Jsp] Comment différer les sessions dans les onglets du navigateur?



Answers

Vous devez réaliser que les sessions côté serveur sont un complément artificiel à HTTP. Étant donné que HTTP est sans état, le serveur doit en quelque sorte reconnaître qu'une requête appartient à un utilisateur particulier qu'il connaît et à qui une session est destinée. Il y a 2 façons de faire ceci:

  • Biscuits. La méthode plus propre et plus populaire, mais cela signifie que tous les onglets du navigateur et les fenêtres par un utilisateur partagent la session - OMI c'est en fait souhaitable, et je serais très ennuyé à un site qui m'a fait me connecter pour chaque nouvel onglet, puisque je utiliser les onglets très intensivement
  • Réécriture d'URL. Toute URL sur le site a un ID de session ajouté à celui-ci. C'est plus de travail (vous devez faire quelque chose partout où vous avez un lien interne au site), mais il est possible d'avoir des sessions séparées dans différents onglets, bien que les onglets ouverts via le lien partagent toujours la session. Cela signifie également que l'utilisateur doit toujours se connecter lorsqu'il vient sur votre site.

Qu'est-ce que vous essayez de faire de toute façon? Pourquoi voudriez-vous que les onglets aient des sessions séparées? Peut-être qu'il y a un moyen d'atteindre votre objectif sans utiliser de session du tout?

Modifier: pour tester, d'autres solutions peuvent être trouvées (comme l'exécution de plusieurs instances de navigateur sur des machines virtuelles distinctes). Si un utilisateur doit agir dans des rôles différents en même temps, le concept de «rôle» doit être géré dans l'application afin qu'une même connexion puisse avoir plusieurs rôles. Vous devrez décider si cela, en utilisant la réécriture d'URL, ou tout simplement vivre avec la situation actuelle est plus acceptable, car il n'est tout simplement pas possible de gérer les onglets du navigateur séparément avec des sessions basées sur les cookies.

Question

Dans une application web implémentée en Java en utilisant JSP et Servlets; Si je stocke des informations dans la session utilisateur, ces informations sont partagées à partir de tous les onglets du même navigateur. Comment différer les sessions dans les onglets du navigateur? Dans cet exemple:

<%@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>

Copiez ce code dans une page jsp ( testpage.jsp ), déployez ce fichier dans un contexte existant d'une application web sur le serveur (j'utilise Apache Tomcat), puis ouvrez un navigateur (FF, IE7 ou Opera) en utilisant l'URL correcte ( localhost/context1/testpage.jsp ), tapez votre nom dans l'entrée et envoyez le formulaire. Ensuite, ouvrez un nouvel onglet dans le même navigateur, puis vous pouvez voir votre nom (obtenir de la session) sur le nouvel onglet. Soyez prudent avec le navigateur-cache, semble parfois que cela n'arrive pas, mais c'est dans le cache, actualiser le deuxième onglet.

Merci.




Vous pouvez utiliser la réécriture de liens pour ajouter un identifiant unique à toutes vos URL lorsque vous démarrez sur une seule page (par exemple, index.html / jsp / whatever). Le navigateur utilisera les mêmes cookies pour tous vos onglets afin que tout ce que vous mettez dans les cookies ne soit pas unique.




Tu ne devrais pas. Si vous voulez faire une telle chose soit vous devez forcer l'utilisateur à utiliser une seule instance de votre application en écrivant des URL à la volée, utilisez un id de session identique (pas de session, ça ne marchera pas) et passez-le dans chaque URL.

Je ne sais pas pourquoi vous en avez besoin, mais à moins que vous ayez besoin de faire une application totalement inutilisable, ne le faites pas.




Nous avons eu ce problème et nous l'avons résolu très facilement. Je veux dire facile parce qu'aucune programmation impliquée. Ce que nous voulions faire était de laisser un utilisateur se connecter à plusieurs comptes dans la même fenêtre du navigateur sans conflit entre les sessions.

Donc, la solution était des sous-domaines aléatoires.

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

Nous avons donc demandé à notre administrateur système de configurer les certificats SSL pour * .abc.com plutôt abc.com Ensuite, avec peu de changement de code, chaque fois qu'un utilisateur tente de se connecter, il est connecté à un onglet avec un numéro de sous-domaine aléatoire. Chaque onglet peut donc avoir sa propre session indépendamment. Aussi, pour éviter tout conflit, nous avons développé le nombre aléatoire en utilisant un hash ou md5 de l'identifiant de l'utilisateur.




Je pense que ce que vous voulez probablement est de maintenir l'état de navigation entre les onglets et pas spécifiquement créer une seule session par onglet. C'est exactement ce que le framework Seam atteint avec son périmètre / contexte de Conversation. Leur implémentation repose sur le fait qu'un identifiant de conversation est propagé avec chaque requête et crée la notion de conversation côté serveur, ce qui se situe entre une session et une requête. Il permet le contrôle du flux de navigation et la gestion de l'état.

Bien que ce soit principalement destiné à JSF, jetez un oeil et vérifiez si c'est quelque chose où vous pouvez prendre quelques idées de: http://docs.jboss.org/seam/latest/reference/en-US/html_single/#d0e3620




J'ai résolu ceci de la manière suivante:

  • J'ai assigné un nom à la fenêtre ce nom est la même chose de la ressource de connexion.
  • plus 1 à débarrasser stocké dans cookie pour attacher la connexion.
  • J'ai créé une fonction pour capturer toutes les réponses xmloutput et assigner sid et débarrasser au cookie au format json. Je fais cela pour chaque window.name.

voici le code:

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);
    }

J'espère t'aider




How to differ sessions in browser-tabs?

La manière la plus directe de différer les sessions dans les onglets du navigateur est d'interdire à votre domaine particulier de définir des cookies. De cette façon, vous pouvez avoir des sessions séparées à partir d'onglets séparés. Supposons que vous refusiez les cookies de ce domaine: www.xyz.com. Vous ouvrez l'onglet 1, connectez-vous et commencez à naviguer. Ensuite, vous ouvrez l'onglet 2, et vous pouvez vous connecter soit comme un même utilisateur ou un autre; De toute façon, vous aurez une session séparée de l'onglet 1. Et ainsi de suite.

Mais bien sûr, cela est possible lorsque vous avez le contrôle du côté client. Sinon, les solutions prescrites par les gens ici devraient s'appliquer.




J'ai lu ce post parce que je pensais que je voulais faire la même chose. J'ai une situation similaire pour une application sur laquelle je travaille. Et c'est vraiment une question de test plus que de praticité.

Après avoir lu ces réponses, en particulier celle donnée par Michael Borgwardt, j'ai réalisé le flux de travail qui doit exister:

  1. Si l'utilisateur accède à l'écran de connexion, recherchez une session existante. S'il en existe un, ignorez l'écran de connexion et envoyez-les à l'écran d'accueil.
  2. Si l'utilisateur (dans mon cas) accède à l'écran d'inscription, recherchez une session existante. S'il en existe un, informez l'utilisateur que vous allez ouvrir une session. S'ils sont d'accord, déconnectez-vous et commencez l'inscription.

Cela résoudra le problème de voir les données "d'un autre utilisateur" dans sa session. Ils ne voient pas vraiment les données "d'un autre utilisateur" dans leur session, ils voient vraiment les données de la seule session qu'ils ont ouverte. Clairement, cela provoque des données intéressantes, car certaines opérations remplacent certaines données de session et pas d'autres afin que vous ayez une combinaison de données dans cette seule session.

Maintenant, pour résoudre le problème des tests. La seule approche viable consisterait à tirer parti des directives du préprocesseur pour déterminer si des sessions sans cookie doivent être utilisées. Voir, en construisant dans une configuration spécifique pour un environnement spécifique, je suis en mesure de faire quelques hypothèses sur l'environnement et à quoi il sert. Cela me permettrait techniquement d'avoir deux utilisateurs connectés en même temps et le testeur pourrait tester plusieurs scénarios de la même session de navigateur sans jamais se déconnecter de l'une de ces sessions de serveur.

Cependant, cette approche comporte de sérieuses réserves. Le fait que ce que le testeur teste n'est pas ce qui va fonctionner en production.

Donc je pense que je dois dire que c'est finalement une mauvaise idée.




Je vois de nombreuses implémentations qui ont des changements côté client pour manipuler les cookies d'identification de session. Mais en général, les cookies d'identification de session devraient être HttpOnly afin que java-script ne puisse pas accéder sinon cela pourrait conduire à un détournement de session via XSS.







Links