Dan,
On 1/26/24 02:44, Dan McLaughlin wrote:
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.
Lots of stuff here.
First, you should pretty much never touch CATALINA_BASE/conf/web.xml or
CATALINA_BASE/conf/web.xml. Do everything from within your application
(i.e. META-INF/context.xml and WEB-INF/web.xml).
Second... I don't think Tomcat changes the rules for what paths are
allowed depending upon the name of the cookie. Specifically, Tomcat does
not appear to contain any code to enforce the requirements of __Host- or
__Secure- cookies. Are you using HTTPS to access these pages? Mozilla's
documentation says it's required. Do your cookies have the "secure" flag
set?
When you do your tests, be sure to look at the Set-Cookie HTTP response
headers your application (or Tomcat) are sending.
Do you really need to use these special cookie names?
-chris
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
