Meilleure façon d'autoriser les cookies de session de sous-domaine à l'aide de Tomcat

Question

Par défaut, tomcat créera un cookie de session pour le domaine en cours.

Si vous êtes sur www.example.com, votre cookie sera créé pour www.example.com (ne fonctionnera que sur www.example.com). Alors que pour example.com il sera créé pour .example.com (le comportement désiré, travaillera sur n'importe quel sous-domaine de example.com aussi bien qu'exemple.com lui-même). J'ai vu quelques valves Tomcat qui semblent intercepter la création de cookies de session et créer un cookie de remplacement avec le domaine .example.com correct, mais aucun d'entre eux ne semble fonctionner parfaitement et ils semblent tous quitter le cookie existant et en créer un nouveau. Cela signifie que deux cookies JSESSIONID sont envoyés avec chaque requête.

Je me demandais si quelqu'un avait une solution définitive à ce problème.

Answer 1

Ceci est apparemment pris en charge via un paramètre de configuration de 6.0.27 et suivantes:

La configuration se fait en éditant META-INF/context.xml

< Contexte sessionCookiePath = "/ quelque chose" sessionCookieDomain =/>

"domain.tld."

https://issues.apache.org/bugzilla/show_bug.cgi?id=48379

Answer 2

Je l'ai rencontré dans $ DAYJOB. Dans mon cas, je voulais implémenter le code SSL puis rediriger vers une page non SSL. Le problème principal dans tomcat est la méthode (de la mémoire) SessionManager.configureSessionCookie qui code dur toutes les variables auxquelles vous souhaitez avoir accès.

Je suis venu avec quelques idées, y compris un hack particulièrement flagrant utilisant mod_headers dans apache pour réécrire le cookie basé sur la substitution de regex.

La manière définitive de résoudre ce problème serait de soumettre un correctif aux développeurs de tomcat qui ajoute des paramètres configurables à la classe SessionManager.

Answer 3

Comme une session (et son identifiant) est fondamentalement considérée comme valable uniquement pour l'application émettrice, vous pouvez plutôt rechercher un cookie supplémentaire. Jetez un coup d'œil à Tomcats SingleSignOnValve, en fournissant l'extra-Cookie JSESSIONIDSSO (notez le ... SSO) pour le chemin du serveur "/" au lieu de "/ applicationName" (comme les cookies JSESSIONID sont généralement définis). Avec une telle Valve, vous pouvez implémenter toute communication interprocessus dont vous avez besoin pour synchroniser n'importe quel état entre différents serveurs, hôtes virtuels ou webapps sur n'importe quel nombre de Tomcats/Serveurs Web/quoi que ce soit.

Une autre raison pour laquelle vous ne pouvez pas utiliser le cookie de session tomcats à vos propres fins est que plusieurs webapps sur le même hôte ont des identifiants de session différents. Par exemple. Il existe différents cookies pour "/ webapp1" et "/ webapp2". Si vous fournissez le cookie "/ webapp1" à "/ webapp2", la session que vous avez référencée ne sera pas trouvée, votre session + cookie sera invalidé et votre nouveau cookie sera créé. Vous devrez réécrire tout le traitement des sessions de tomcats pour accepter les valeurs d'identifiant de session externe (mauvaise idée de sécurité) ou pour partager un certain état entre les applications.

La gestion de session devrait être considérée comme l'activité des conteneurs (tomcats). Tout ce dont vous avez besoin, vous devez ajouter sans interférer avec ce que le conteneur estime nécessaire de faire.

Answer 4

Les techniques de vannes ne semblent pas parfaites à 100%. Si vous osez modifier Tomcat lui-même:

catalina.jar contient la classe suivante: org.apache.catalina.connector.Demande

La demande a une méthode:

configureSessionCookie(Cookie cookie) 

Pour notre environnement, il est préférable de simplement hardcode, mais vous pouvez faire une logique plus de fantaisie:

cookie.setDomain(".xyz.com"); 

semble fonctionner parfaitement. Ce serait bien si c'était configurable dans tomcat.

Answer 5

Je viens de traverser tout cela à la recherche d'une solution simple. J'ai commencé à le regarder du point de vue de Tomcat d'abord. Tomcat ne donne pas un accès direct à la configuration du cookie de domaine pour la session, et je ne voulais absolument pas personnaliser le correctif tomcat pour résoudre ce problème comme indiqué dans d'autres publications.

Les vannes dans tomcat semblent également être une solution problématique en raison des limitations d'accès aux en-têtes & cookies intégrés à la spécification Servlet. Ils échouent également complètement si la réponse http est validée avant d'être transmise à votre valve.

Depuis que nous avons envoyé nos requêtes via Apache, je suis passé à la façon d'utiliser apache pour résoudre le problème.

J'ai d'abord essayé la directive mod_proxy ProxyPassReverseCookieDomain, mais cela ne fonctionne pas pour les cookies JSESSIONID car tomcat ne définit pas l'attribut domain et ProxyPassReverseCookieDomain ne peut pas fonctionner sans qu'une sorte de domaine fasse partie du cookie. J'ai également rencontré un hack utilisant ProxyPassReverseCookiePath où ils réécrivaient le chemin d'accès pour ajouter un attribut de domaine au cookie, mais cela semblait désagréable pour un site de production.

Je l'ai enfin réussi à réécrire les en-têtes de réponse en utilisant le module mod_headers dans apache comme mentionné par Dave ci-dessus.

J'ai ajouté la ligne suivante dans la définition d'hôte virtuel:

Header edit Set-Cookie "(JSESSIONID\s?=[^;,]+?)((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(;\s?(?:(?i)Domain\s?=)[^;,]+?)?((?:;\s?(?:(?i)Comment|Max-Age|Path|Version|Secure)[^;,]*?)*)(,|$)" "$1$2; Domain=.example.com$4$5" 

ci-dessus doivent tous être une seule ligne dans la configuration. Il remplacera tout attribut de domaine de cookies JSESSIONID par ".example.com". Si un cookie JSESSIONID ne contient pas d'attribut de domaine, le modèle en ajoute un avec la valeur ".example.com". En prime, cette solution ne souffre pas du double problème de cookies JSESSION des vannes.

Le modèle doit fonctionner avec plusieurs cookies dans l'en-tête Set-Cookie sans affecter les autres cookies dans l'en-tête. Il devrait également être modifiable de travailler avec d'autres cookies en changeant JSESSIONID dans la première partie du modèle à n'importe quel nom de cookie que vous désirez.

Je ne suis pas un utilisateur power reg-ex, donc je suis sûr qu'il y a quelques optimisations qui pourraient être apportées au pattern, mais ça semble marcher pour nous jusqu'à maintenant.

Je vais mettre à jour ce post si je trouve des bugs avec le motif. J'espère que cela empêchera quelques-uns d'entre vous de subir les frustrations des deux derniers jours comme je l'ai fait.