J'ai une situation où j'ai deux WebApps différents en cours d'exécution sur un seul serveur, en utilisant différents ports. Ils exécutent tous les deux le conteneur de servlet de jetty de Java, ils utilisent donc un paramètre de cookie nommé Jsessid pour suivre l'ID de session. Ces deux WebApps se battent sur l'ID de session.
req.getsession (false); i get null . Et si j'appelle req.getsession (true) i Obtenir un nouvel objet de session, mais la réponse HTTP de WebApp2 a une en-tête de cookie définie avec JSessionID = 20
- MAINTENANT, webApp2 a une session de travail, mais la session de WebApp1 est partie. Aller à WebApp1 me donnera une nouvelle session, soufflant la session de WebApp2.
- continuer pour toujours
Pour que les sessions se débrouillent entre chaque application Web. J'aimerais vraiment pour le req.getsession (false) pour renvoyer une session valide s'il existe déjà un cookie Jsessionid défini.
Une option consiste à réprimer essentiellement le cadre de la session avec un hashmap et des cookies appelés WebApp1Sessionid et WebApp2Sessionid, mais cela est craint, et cela signifie que je devrai pirater la nouvelle séance de session dans ActionServille et quelques autres endroits.
Cela doit être un problème que d'autres ont rencontré. Est-ce que Jetty's's's's ''s> httpservletQuest.getsession (booléen) juste merci?
6 Réponses :
C'est un comportement correct. Vous pouvez placer deux votre WebApps dans différents domaines ou par différents chemins.
Vous pouvez également définir le chemin de biscuits Jsessionid, je crois.
Ce n'est pas le problème de la jetée, c'est la manière dont la spécification de cookie a été définie. Outre la paire Nom / Valeur, un cookie peut également contenir une date d'expiration, un chemin, un nom de domaine et si le cookie est sécurisé (c'est-à-dire destiné uniquement aux connexions SSL). Le numéro de port n'est pas répertorié dans ce qui précède ;-) Vous devez donc varier soit sur le chemin ou le domaine, comme le dit Stepancheg dans sa réponse.
Mon problème est que, lorsque la jetée va créer une nouvelle session, par défaut, elle n'essaie même pas d'utiliser la valeur existante de JSessionID. Il choisit simplement une nouvelle valeur pour cela. S'il est réutilisé ceux existants, mes deux cas de jetée pouvaient jouer agréable.
J'ai creusé et j'ai trouvé que dans sur la fouille supplémentaire, cela ne m'aidera que si je gère deux webapps dans différents contextes de la même jetty (par conséquent, contexte croisé). Lors de la création d'un nouvel objet Objet , une nouvelle valeur Depuis que je traite de deux nouvelles instances de jetée différentes en fonctionnant sur deux ports différents, je devrai pirater la source de Jetty pour ne pas faire ce chèque, ni simplement faire mon propre cadre de session. AbstractStressSessionManager , il existe une méthode appelée gecrosscontextsessids () . Si elle renvoie true , alors lors de la création d'une nouvelle session, la jetty vérifiera d'abord si JSessionID est définie et essayez d'utiliser cet ID de session existant. Je pense que je peux définir les valeurs sur true en utilisant une sorte de propriété Java au démarrage.
JSessionID est choisie. Si getcrosscontextsessids () renvoie true , alors il vérifiera si la valeur actuelle jsessidide a été créée par cette jetty (y compris tous les autres contextes) et Si c'était c'était, ça va le réutiliser.
Cela ressemble à vous devoir rester avec une jetée - je ne suppose pas que la solution fonctionnera avec d'autres conteneurs de servlet. En espérant que vous n'ayez jamais besoin de changer :-)
Tu as raison. Nous envisageons de modifier le code de la jetée comme solution à court terme. À long terme, nous mettrons soit en œuvre notre propre gestion de session en utilisant différents cookies, soit tout changera lorsque nous implémentons un système SSO.
J'ai eu un problème similaire: une ou plusieurs instances de la même application sur localhost sur différents ports, choisis lors de l'heure de début de l'application, chacun en utilisant sa propre instance de jetty.
Après un moment, je suis venu avec ceci:
socketmanager.getlocalport () )
- Définissez le nom de la cookie via SessionManager
(SessionHandler.GetsessionManager (). SetSessionCookie (String) )
De cette façon, j'ai une différence nom de cookie pour chaque instance - donc aucune ingérence.
Dans notre cas, nous utilisons Tomcat, la solution consiste donc à utiliser différents noms de cookies de session sur chaque instance.
in context.xml faire quelque chose comme