Re: Dynamic session cookie domain... possible?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Phillipe, On 2/14/18 6:50 PM, Philippe Busque wrote: > I'm migrating from Tomcat 8.0.X to Tomcat 9.0.5 and I have a issue > I've been dragging for too long that I wise to correct. I have been > searching for a workaround and so far, I've found nothing so far > that work out of the box. > > Here is the situation: > > We have a single webapp that can handle multiple domains, some of > which are sub-domains. Example: www.example1.com, > images.example1.com, assets.example1.com, www.example2.com > > As far as I know Tomcat only allows us to set define a domain > through a sessionCookieDomain in the context. But this domain is > fixed. If I set sessionCookieDomain=".example1.com", this will > break www.example2.com and vice-versa. > > If I leave sessionCookieDomain empty, I don't get sub-domain > support as no domain is set and the browser fallback to the current > domain serviced. > > All the manipulation of the session cookie are managed in the > org.apache.catalina.connector.Response class and is not > customizable. > > So far, when we were using Tomcat 8, we were able to do a > workaround by overriding the method addSessionCookieInternal inside > the Response class through a facade, but this is a dirty hack and I > would rather not alter any of Tomcat's inner classes... And a proxy > is out of the question, Response not being an interface. > > The other workaround I can think of is splitting *.example1.com > & example2.com into 2 separate tomcat instance or webapps, but that > would only duplicate the resources required (ram + disk space) for > as many different domains we decide to support. > > > Is there therefor a better way to handle manipulating session > cookies, or is it frozen and out of reach for multiple subdomain? > > A "SessionCookieProcessor", which would take the context & the > cookie, would be most welcome for such a case This all comes down to how cookies actually work. The simply trust is that the web browser isn't going to let you set a cookie for another domain. I'm not even sure how your "hack" even worked. You said that you couldn't use a Proxy... I assume you mean java.lang.reflect.Proxy, right? Well... what about a reverse-proxy (a networking component) that serves all applications under a single domain name? (e.g. examples-all.com)? Then all applications can appear to be using the same shared domain name? If you can't do that, and you really need to support multiple hostnames, then you'll have to do something like trampolining: 1. Client makes a request to https://www.example1.com/resource 2. Respond with 302 ; Set-Cookie: JSESSIONID=foo ; Location:https://www.exmaple2.com/create-session 3. Client follows redirect to https://www.example2.com/create-session 4. Respond with 302 ; Set-Cookie JSESSIONID=bar ; Location: https://www.example1.com/back-from-hostname2 5. Do whatever you need to do afterwards. This is awkward, but it will work. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlqHLnIACgkQHPApP6U8 pFi8Vw//V3H/owH7QbLlok99pF5LJ3BHxHQya2AIg5+q2PtqHFSx4dANERF0GL4h /wsdb6UxnQnIkn4rCSSJ46ZMfNTVzkocJPKpWFOIbBrBeuMvqG3Zdtvn/xkAlEFy Bb7kUr3ZFNxiGE+6mZ2bwD79N9FosvWi3Uh7dH2brskcwf+IVvkSd2KR3GsW6Kiy kqovAkAAF+c1BvfnWZrtljoErAUtuwSVELRCxwf+0WvyktrDDLz2EZjP3WlevBck cJyZ0o88dLTN7Apcb054kGVvbY1r0peOkJjmfxs4n/FnOtOTiL6fBIYe+PLBgS0w UNH2XQfBP8+a8cNHi8/8kUtuprHctx+U5aldto+Gm96h9CnDOiwBBJCVx7JN0w9O kdV5yYGLLgHsPOFStFfOl7Oz9I7xNZaHkPSY9X5L1oue8mEQri9aTSUAHW9d2lc7 84Uu543p7prxjgiDhl+jhg7ILxBmKU8NvoAJcYsDQLnDi6KFfeN9rY69QEVE/t9Y l6PfK+QTgPxnlGkwptHayAPr+PyiQIlczpLRyBOwBNCcKc3fNBkb8NTrxXVSxgdB /6tseX0aNQgaTL9+aMxRSMff7vCVU+NZv8LEVWGuYGe5yIc5RtvulvLPwpTZ2hgj 4NLQonTHcj417+xjavtkZjvUKEL53G++7mrYF/Ghs/1z4NoFWok= =RCyY -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Dynamic session cookie domain... possible?
Hello, I'm migrating from Tomcat 8.0.X to Tomcat 9.0.5 and I have a issue I've been dragging for too long that I wise to correct. I have been searching for a workaround and so far, I've found nothing so far that work out of the box. Here is the situation: We have a single webapp that can handle multiple domains, some of which are sub-domains. Example: www.example1.com, images.example1.com, assets.example1.com, www.example2.com As far as I know Tomcat only allows us to set define a domain through a sessionCookieDomain in the context. But this domain is fixed. If I set sessionCookieDomain=".example1.com", this will break www.example2.com and vice-versa. If I leave sessionCookieDomain empty, I don't get sub-domain support as no domain is set and the browser fallback to the current domain serviced. All the manipulation of the session cookie are managed in the org.apache.catalina.connector.Response class and is not customizable. So far, when we were using Tomcat 8, we were able to do a workaround by overriding the method addSessionCookieInternal inside the Response class through a facade, but this is a dirty hack and I would rather not alter any of Tomcat's inner classes... And a proxy is out of the question, Response not being an interface. The other workaround I can think of is splitting *.example1.com & example2.com into 2 separate tomcat instance or webapps, but that would only duplicate the resources required (ram + disk space) for as many different domains we decide to support. Is there therefor a better way to handle manipulating session cookies, or is it frozen and out of reach for multiple subdomain? A "SessionCookieProcessor", which would take the context & the cookie, would be most welcome for such a case Thanks -- *Philippe Busque* , rue St-Charles Ouest, Tour Est, bureau 255 Longueuil (Québec) Canada J4K 5G4 Tél. : 450-449-0102 ext. 3017 Télec. : 450-449-8725 Ce message et les fichiers d’accompagnement transmis avec celui-ci s’adressent expressément au(x) destinataire(s) et peuvent contenir des renseignements confidentiels et privilégiés. Si vous recevez ce message par erreur, veuillez en aviser immédiatement l’expéditeur par courrier électronique. Veuillez également ne pas en prendre connaissance et en supprimer toutes les copies immédiatement. Technologies Interactives Mediagrif Inc. et ses filiales n’acceptent aucune responsabilité à l’égard des opinions exprimées dans le message ou des conséquences de tout virus informatique qui pourrait être transmis avec ce message. Ce message fait également l’objet d’un copyright. Il est interdit d’en reproduire, adapter ou transmettre quelque partie que ce soit sans le consentement écrit du détenteur du copyright. This email and any files transmitted with it are solely intended for the use of the addressee(s) and may contain information that is confidential and privileged. If you receive this email in error, please advise us by return email immediately. Please also disregard the contents of the email, delete it and destroy any copies immediately. Mediagrif Interactive Technologies Inc. and its subsidiaries do not accept liability for the views expressed in the email or for the consequences of any computer viruses that may be transmitted with this email. This email is also subject to copyright. No part of it should be reproduced, adapted or transmitted without the written consent of the copyright owner. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
