Meilleur moyen 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 actuel.

Si vous êtes sur www.example.com, votre cookie sera créé pour www.example.com (ne fonctionnera que sur www.example.com). Considérant que, par exemple.com, il sera créé pour .example.com (le comportement souhaité s’appliquera à n’importe quel sous-domaine de example.com et à example.com lui-même).

J'ai vu quelques vannes Tomcat qui semblaient intercepter la création de cookies de session et créer un cookie de remplacement avec le domaine correct .example.com, mais aucune d'entre elles ne semble fonctionner parfaitement et toutes semblent quitter le système existant. cookie et juste créer un nouveau. Cela signifie que deux cookies JSESSIONID sont envoyés avec chaque demande.

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

Answer 1

Ceci est apparemment supporté via un paramètre de configuration dans les versions 6.0.27 et suivantes:

  

La configuration se fait par édition   META-INF / context.xml

     

< Contexte   sessionCookiePath = " / quelque chose "   sessionCookieDomain = & "; .domain.tld &"; / >

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

Answer 2

Je viens de parcourir tout cela à la recherche d'une solution simple. J'ai commencé par l'examiner du point de vue de tomcat.

Tomcat ne donne pas d'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 le montrent d'autres publications.

Les vannes dans tomcat semblent également poser problème en raison des restrictions d'accès aux en-têtes & amp; cookies intégrés dans la spécification Servlet. Ils échouent également complètement si la réponse http est validée avant qu'elle ne soit transmise à votre vanne.

Puisque nous adressons nos requêtes par proxy via Apache, j'ai ensuite expliqué comment 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 de domaine et que ProxyPassReverseCookieDomain ne peut pas fonctionner sans qu'un domaine ne fasse partie du cookie.

J'ai également rencontré un piratage en utilisant ProxyPassReverseCookiePath où ils réécrivaient le chemin pour ajouter un attribut de domaine au cookie, mais cela semblait compliqué pour un site de production.

J'ai finalement 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 de l'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"

Tout ce qui précède devrait ê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 ajoutera un avec une valeur de & "; .Example.com &"; En prime, cette solution ne souffre pas du problème de double cookies JSESSION.

Le modèle devrait fonctionner avec plusieurs cookies dans l'en-tête Set-Cookie sans affecter les autres cookies de l'en-tête. Il devrait également être modifiable de travailler avec d’autres cookies en remplaçant JSESSIONID dans la première partie du motif par le nom de cookie de votre choix.

Je ne suis pas un utilisateur chevronné, je suis donc sûr que quelques optimisations pourraient être apportées au motif, mais cela semble fonctionner pour nous jusqu'à présent.

Je mettrai à jour ce post si je trouve des bugs dans le motif. J'espère que cela évitera à quelques-uns d'entre vous de passer par les frustrations des deux derniers jours, comme je l'ai fait.

Answer 3

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

J'ai proposé quelques idées, y compris un piratage particulièrement flagrant utilisant mod_headers dans apache pour réécrire le cookie en fonction de la substitution de regex.

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

Answer 4

Dans la mesure où une session (et son identifiant) est généralement considérée comme ayant une valeur uniquement pour l'application émettrice, vous pouvez plutôt rechercher la configuration d'un cookie supplémentaire. Jetez un coup d’œil à Tomcats SingleSignOnValve, qui fournit l’extra-cookie JSESSIONIDSSO (remarquez ... SSO) pour le chemin du serveur & Quot; / & Quot; au lieu de " / nomapplication " (comme les cookies JSESSIONID sont généralement définis).

Avec une telle vanne, vous pouvez implémenter toute communication inter-processus dont vous avez besoin pour synchroniser n’importe quel état entre différents serveurs, hôtes virtuels ou applications Web, sur n’importe quel nombre de tomcats / serveurs Web / quel que soit votre choix.

Une autre raison pour laquelle vous ne pouvez pas utiliser le cookie de session tomcats à vos propres fins est que plusieurs applications Web 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 de & Quot; / webapp1 & Quot; à & "/ Webapp2 &", La session que vous avez référencée ne serait pas trouvée, cela invaliderait votre session + cookie et le définirait. propre nouvelle. Vous devrez réécrire toute la gestion de session tomcats pour accepter les identifiants de session externes (mauvaise idée en matière de sécurité) ou pour partager un certain état entre les applications.

La gestion de session doit être considérée comme une activité de conteneurs (tomcats). Vous devez ajouter tout ce dont vous avez besoin sans interférer avec ce que le conteneur pense nécessaire de faire.

Answer 5

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

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

La demande a une méthode:

configureSessionCookie(Cookie cookie)

Pour notre environnement, il était préférable de le coder en dur, mais vous pouvez utiliser une logique plus sophistiquée:

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

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