Nous avons une application Web en cours de création pour servir plusieurs TLD de sites Web régionaux. En outre, l'application Web prend également en charge des milliers de sous-domaines dynamiques. Voici quelques exemples:GlassFish v3 JSESSIONID Sous-domaines et TLD multiples
www.example.com
www.example.co.uk
www.example.com.ar
fred123.example.co.uk <== Thousands of this form
fred123.p.example.us <== Thousands of this form
Alors que nous pouvons comprendre que les différents TLDs de domaine se traduisent par de nouvelles sessions un problème commence à apparaître avec ces 2 derniers exemples ci-dessus qui se traduisent également dans les cas de nouvelle session. Par exemple, si un utilisateur:
- Goes to: www.example.co.uk une nouvelle session est créée puis ...
- clique sur un lien: fred123.example.co.uk une nouvelle session est créé, puis ...
- clique sur un lien: sam99.example.co.uk une nouvelle session est créée ...
3 clics == >> 3 sessions !!!!
Le problème semble être dû au fait que GlassFish v3 fait automatiquement du domaine de JSESSIONID le nom de domaine complet de la requête hôte.
Ce qui est nécessaire est que la partie du nom d'hôte soit dépouillé de la valeur de domaine à tout le moins avoir des valeurs de domaines tels que:
.example.com
.example.co.uk
.example.com.ar
.example.co.uk <== Thousands of this form
.p.example.us <== Thousands of this form
Est-ce que quelqu'un sait comment cela peut être réalisé. J'ai trouvé le Q suivant & A mais dans notre cas, les TLDs ne sont pas tous les sous-domaines match:
An issue dealing with JSP Session
Ergo la solution de configuration statiquement le soleil web.xml ou à l'aide d'une solution Servlet 3.0 ne semble pas aider. La création d'un wrapper de réponse de filtre ne fonctionne pas non plus car le cookie JSESSIONID est affecté aux niveaux inférieurs du serveur d'applications et n'est pas exposé à l'interception Web.
Les seules deux autres options que je pense que je l'ai sont:
a) Patch le code GlassFish v3 qui définit la valeur de domaine du cookie JSESSIONID FQDN de sorte que certains décapage se produit ou
b) Faire quelque chose dans le Couche proxy inverse de Sun Web Server 7.0 pour laquelle nous devons réécrire la valeur du domaine de cookie JSESSIONID retournée dans l'en-tête set-cookie. Cependant, je n'ai pas trouvé d'exemples sur la façon de le faire
Quelqu'un peut-il aider à résoudre ce problème? ? Tous les indices/aide seront très appréciés! Utilisation de Apache et mod_headers pour réécrire les cookies?
Toutes ces URL sont-elles mappées à une application Web unique? –
Oui. Ils sont tous mappés à une webapp. Initialement, il y aura 8 TLDs régionaux et plus tard, plus seront ajoutés et comme nous aurons 2 serveurs LB'd avec 6 instances de glassfish, il commencera à déployer des applications web distinctes afin de permettre des valeurs de cookie de domaine JSESSIONID distinctes. De plus, indépendamment de webapps séparé est toujours un problème pour les domaines dynamiques. Pensées??? – nikolaosinlight
Deux domaines que je regarde: 1) Certains comment obtenir Sun Web Server 7.0 RP pour réécrire la valeur du domaine de cookie JSESSIONID définie dans la réponse d'en-tête renvoyée par le serveur GlassFish v3. Quelqu'un sait comment? 2) écrire une version modifiée de la classe dans GlassFish v3 qui détermine le nom de domaine complet de la valeur du domaine de cookie JSESSIONID afin qu'il puisse mieux définir la valeur. En fait, c'est exactement la façon dont les cookies de notre code actuel calculent sa valeur de domaine de cookie pour définir les paramètres régionaux de domaine sélectionnés/déterminés. Quelqu'un sait quelle classe dans le code je devrais mettre à zéro dessus? – nikolaosinlight