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.
