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.



Reply via email to