Hey Konstantin, Thanks for the reply.
I synced the source last night. I haven't had a chance to step through with a debugger yet. But the only way I could get the Cookie Path set was to modify the context.xml and add sessionCookiePath to every application. I'm pretty sure this wasn't how things worked in the past. And the documentation even states (or how I interpret it) that the cookie path should default to the context path if cookie path isn't set by the app or in the context.xml. We don't set it anywhere in our code that I could find, and it's not in our web.xml either. I also checked the server.xml and context.xml in catalina base, and nothing sets anything related to the session cookie. Locally in docker, I could confirm that if you don't set anything except the cookie processor, then you end up with a JSESSIONID with a cookie path that is the same as the context if it's not the root context. But if you try to set sessionCookie in the context.xml for the app to _Secure-JSESSIONID and you don't set the sessionCookiePath, then your cookie path will be / regardless of what the context path is. Seems like a bug to me. If I have time to try some more tests and can confirm the same using the examples web app, then I'll open a bug. We do set privileged="false" in our context.xml so the only thing I can think of is that the cookie processor or whatever code is managing the cookies is blocked from calling the api's needed to check the context path and so it defaults to /. Anyway, I'd have to do quite a bit more testing before I'd feel comfortable opening a bug, but there looks to be changes in the areas related to Sessions and Cookies lately, so I'm guessing at this point that one of those changes introduced a behavior change. -- Thanks, Dan On Fri, Jan 26, 2024 at 2:36 AM Konstantin Kolinko <knst.koli...@gmail.com> wrote: > пт, 26 янв. 2024 г. в 04:01, Dan McLaughlin <d...@danshome.net.invalid>: > > > > 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. > > 1. I think that you can configure an AccessLogValve to log the actual > value of "Set-Cookie" header that is snt with your response, as well > as "Cookie" headers sent by clients. > > 2. "<default-context-path>" setting is not processed by Tomcat. > Only your war name matters, > https://tomcat.apache.org/tomcat-10.1-doc/config/context.html#Naming > > "<comment>Session Cookie</comment>" > Why? What do you expect this is for? > In the old times this would be sent to a browser, but I think nowadays > it is just ignored. > > I recommend to validate your web.xml against its schema. (Tomcat can > be configured to do validation at deployment time, but this feature is > off by default). > > 3. If your scenario is easy to reproduce, I recommend remote debugging. > > > https://cwiki.apache.org/confluence/display/TOMCAT/Troubleshooting+and+Diagnostics#TroubleshootingandDiagnostics-CommonTroubleshootingScenario > > Places to look at: > a) the cookie is generated by a CookieProcessor . Look at the > implementation class that you have configured with your > CookieProcessor element. > b) "sessionCookieName" and other attributes are set on Context, It is > org.apache.catalina.core.StandardContext class. > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- *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.
