Well, so much for that theory. __Secure-JSESSIONID still sets the sessionCookiePath to /. I even removed the entire session-config from the web.xml and turned on copyXML to extract the secure#Foo.xml out to the conf/Catalina/localhost folder. Based on the documentation, if I don't set sessionCookiePath in the context.xml and it's not set by the webapp, which I've confirmed it's not, then the cookie path should be set to the context path. I know the contact path is correct because I can load the application at /secure/Foo just fine. Not sure what's changed in the latest release of Tomcat 10.1, but this has never been an issue in the past that I'm aware of. What seems to work is not to try to set any cookie-config settings in the web.xml or any of the session cookie settings in the context.xml, and leave the OOB CookieProcessor. I'm pretty sure that works fine, and it configures the default JSESSIONID using the context path as the cookie path. At least it does in my local Docker environment.
Anyway, I'd appreciate any pointers if anyone else has any ideas. My next step is to try rolling back the Tomcat versions to find when the behavior changed. -- Thanks, Dan On Thu, Jan 25, 2024 at 9:42 PM Dan McLaughlin <d...@danshome.net> wrote: > To give more context we originally moved to use __Host-JSESSIONID but were > seeing issues with the cookie getting overwritten when switching between > application contexts on the same host. I thought the routeid would play a > part in keeping the session cookies separate, but the browsers apparently > don't care. So we are moving to using __Secure- instead. > > -- > > Thanks, > > Dan > > > On Thu, Jan 25, 2024 at 9:29 PM Dan McLaughlin <d...@danshome.net> wrote: > >> I think I just figured it out. __Host- doesn't allow for setting a path >> to anything other than /. >> >> It would have been nice if Tomcat would have logged an error instead of >> silently failing, or forcing the path to / and not saying anything. That >> would have saved me a ton of time. >> >> -- >> >> Thanks, >> >> Dan >> >> On Thu, Jan 25, 2024 at 7:27 PM Dan McLaughlin <d...@danshome.net> wrote: >> >>> Which one wins the catalina-base/conf/web.xml or the >>> Webapp/WEB-INF/web.xml. >>> >>> I just noticed that the one under catalina base contains: >>> >>> <session-config> >>> <session-timeout>30</session-timeout> >>> </session-config> >>> >>> Or do they get merged? >>> >>> Thanks, >>> >>> Dan >>> >>> On Thu, Jan 25, 2024 at 7:00 PM Dan McLaughlin <d...@danshome.net> wrote: >>> >>>> Does anyone know what class we would crank the log level up to see why >>>> Tomcat would ignore cookie-config in our web.xml? >>>> >>>> We are using Tomcat 10.1.18. Our app WAR is named secure#Foo.war. >>>> We've always depended on the name of the WAR to name the Context Path/Name. >>>> >>>> The only reason I'm messing with this is because we can't get the >>>> cookie path to be anything other than /. We gave up trying to use the >>>> cookie settings in the context.xml since we couldn't get the >>>> sessionCookiePath to use our cookie path /secure/Foo. No matter what we >>>> tried, the cookie path was always /. >>>> >>>> This is what our context.xml looked like before we moved to trying to >>>> use the web.xml cookie-config. >>>> >>>> <Context >>>> privileged="false" >>>> unpackWAR="true" >>>> swallowOutput="true" >>>> clearReferencesHttpClientKeepAliveThread="true" >>>> clearReferencesStopThreads="false" >>>> clearReferencesStopTimerThreads="true" >>>> clearReferencesObjectStreamClassCaches="true" >>>> clearReferencesRmiTargets="true" >>>> clearReferencesThreadLocals="true" >>>> renewThreadsWhenStoppingContext="true" >>>> antiResourceLocking="false" >>>> skipMemoryLeakChecksOnJvmShutdown="false" >>>> copyXML="false" >>>> unloadDelay="10000" >>>> useNaming="false" >>>> sessionCookieName="__Host-JSESSIONID" >>>> sessionCookiePath="/secure/Foo" >>>> useHttpOnly="true" >>>> cookies="true" >>>> logEffectiveWebXml="false"> >>>> <CookieProcessor sameSiteCookies="lax" /> >>>> </Context> >>>> >>>> Since setting the cookie path wasn't working using the context.xml, we >>>> removed all the cookie settings except for the CookieProcessor so we could >>>> set sameSite, and we moved to trying to use the cookie-config in web.xml. >>>> >>>> In our web.xml, we have default-context-path at the top, and we have >>>> session-config at the bottom. Everything is in the order defined in the >>>> xsd. >>>> >>>> <default-context-path>/secure/Foo</default-context-path> >>>> >>>> <session-config> >>>> <session-timeout>30</session-timeout> >>>> <cookie-config> >>>> <name>__Host-JSESSIONID</name> >>>> <path>/secure/Foo</path> >>>> <comment>Session Cookie</comment> >>>> <http-only>true</http-only> >>>> <secure>true</secure> >>>> <max-age>-1</max-age> >>>> </cookie-config> >>>> <tracking-mode>COOKIE</tracking-mode> >>>> </session-config> >>>> >>>> When we try to use the web.xml to set the cookie it's even worse than >>>> with the context.xml, with the context.xml we at least got a cookie, now we >>>> don't get a cookie set at all. >>>> >>>> I've tried with autodeploy off/on and deployonstartup off/on. >>>> >>>> Now I just want to crank up log levels to see what's going on. >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> >>>> Dan >>>> >>> -- *NOTICE:* This e-mail message and all attachments transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is strictly prohibited. The contents of this e-mail are confidential and may be subject to work product privileges. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
