You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dan McLaughlin <da...@danshome.net.INVALID> on 2024/01/26 01:00:12 UTC
Session Cookie Logging
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.
Re: Session Cookie Logging
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Dan,
On 2/1/24 11:54, Dan McLaughlin wrote:
> I was able to identify the problem - there was a session configuration with
> cookie configuration in the catalina-base/web.xml file.
catalina-base/conf/web.xml?
I did mention on 26 Jan that this wasn't a good idea and could be
causing this kind of problem. Whatever is in the application's
WEB-INF/web.xml file should override the global setting, though. If you
are finding that it's not working that way, please file a bug.
> I just wanted to suggest that it would be great if logging could be enabled
> to show not only what the parameters were set to, but also where the
> values came from. It seems like the sessionCookiePath could be resolved in
> many ways, such as from the filename of the war, context.xml file name, the
> sessionCookiePath, the cookie-config under the web.xml file in the
> catalina-base/conf directory or from the web.xml packaged in the WAR. I
> haven't had a chance to look at the logic in the Apache code, but this
> would be a helpful addition and would have saved a lot of time trying to
> debug where the value came from.
That may be a tall order. There are many many configurations settings
that can come from all over the place with defaults, default-defaults,
and spec-defined defaults. The session cookie path isn't particularly
special in this way... it just happens to be the one configuration
setting you are really really interested in, specifically.
Tracking exactly where a specific configuration setting came from would
likely require a lot of extra code for not much benefit.
-chris
> On Thu, Feb 1, 2024 at 10:31 AM Mark Thomas <ma...@apache.org> wrote:
>
>>
>>
>> On 27/01/2024 14:38, Dan McLaughlin wrote:
>>> Hey Mark,
>>>
>>> If you see a bug report, then that will mean I was able to reproduce
>> it. I
>>> see different behaviors in our local docker environment. Still, it's
>>> nowhere as complex as our production environment--where everything is
>>> clustered and behind load balancers, etc... It probably would be easier
>>> for me to reproduce in our pre-prod environment and attach a debugger to
>>> see where the / is coming from.
>>>
>>> I glanced at the code, and SessionConfig is the only place setting the
>>> CookiePath to / might happen. Would you agree?
>>>
>>> } else {
>>> // Only handle special case of ROOT context where cookies require a
>>> // path of '/' but the servlet spec uses an empty string
>>> if (contextPath.length() == 0) {
>>> contextPath = "/";
>>> }
>>
>> There are other places such as the RewriteValve. I think debugging is
>> your best option here.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Cookie Logging
Posted by Dan McLaughlin <da...@danshome.net.INVALID>.
Hey Mark,
I was able to identify the problem - there was a session configuration with
cookie configuration in the catalina-base/web.xml file.
I just wanted to suggest that it would be great if logging could be enabled
to show not only what the parameters were set to, but also where the
values came from. It seems like the sessionCookiePath could be resolved in
many ways, such as from the filename of the war, context.xml file name, the
sessionCookiePath, the cookie-config under the web.xml file in the
catalina-base/conf directory or from the web.xml packaged in the WAR. I
haven't had a chance to look at the logic in the Apache code, but this
would be a helpful addition and would have saved a lot of time trying to
debug where the value came from.
--
Thanks,
Dan
On Thu, Feb 1, 2024 at 10:31 AM Mark Thomas <ma...@apache.org> wrote:
>
>
> On 27/01/2024 14:38, Dan McLaughlin wrote:
> > Hey Mark,
> >
> > If you see a bug report, then that will mean I was able to reproduce
> it. I
> > see different behaviors in our local docker environment. Still, it's
> > nowhere as complex as our production environment--where everything is
> > clustered and behind load balancers, etc... It probably would be easier
> > for me to reproduce in our pre-prod environment and attach a debugger to
> > see where the / is coming from.
> >
> > I glanced at the code, and SessionConfig is the only place setting the
> > CookiePath to / might happen. Would you agree?
> >
> > } else {
> > // Only handle special case of ROOT context where cookies require a
> > // path of '/' but the servlet spec uses an empty string
> > if (contextPath.length() == 0) {
> > contextPath = "/";
> > }
>
> There are other places such as the RewriteValve. I think debugging is
> your best option here.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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.
Re: Session Cookie Logging
Posted by Mark Thomas <ma...@apache.org>.
On 27/01/2024 14:38, Dan McLaughlin wrote:
> Hey Mark,
>
> If you see a bug report, then that will mean I was able to reproduce it. I
> see different behaviors in our local docker environment. Still, it's
> nowhere as complex as our production environment--where everything is
> clustered and behind load balancers, etc... It probably would be easier
> for me to reproduce in our pre-prod environment and attach a debugger to
> see where the / is coming from.
>
> I glanced at the code, and SessionConfig is the only place setting the
> CookiePath to / might happen. Would you agree?
>
> } else {
> // Only handle special case of ROOT context where cookies require a
> // path of '/' but the servlet spec uses an empty string
> if (contextPath.length() == 0) {
> contextPath = "/";
> }
There are other places such as the RewriteValve. I think debugging is
your best option here.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Cookie Logging
Posted by Dan McLaughlin <da...@danshome.net.INVALID>.
Hey Mark,
If you see a bug report, then that will mean I was able to reproduce it. I
see different behaviors in our local docker environment. Still, it's
nowhere as complex as our production environment--where everything is
clustered and behind load balancers, etc... It probably would be easier
for me to reproduce in our pre-prod environment and attach a debugger to
see where the / is coming from.
I glanced at the code, and SessionConfig is the only place setting the
CookiePath to / might happen. Would you agree?
} else {
// Only handle special case of ROOT context where cookies require a
// path of '/' but the servlet spec uses an empty string
if (contextPath.length() == 0) {
contextPath = "/";
}
}
--
Thanks,
Dan
On Sat, Jan 27, 2024 at 12:12 AM Mark Thomas <ma...@apache.org> wrote:
> On 26/01/2024 22:22, Dan McLaughlin wrote:
> > 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.
>
> I have tested this with a clean build of both 10.1.x and 11.0.x and both
> correctly set the path to "/examples" when I open the Servlet session
> example in the examples app with sessionCookieName="_Secure-JSESSIONID".
>
> > 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 /.
>
> Nope. Cookie processing doesn't require privileged.
>
> > 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.
>
> There have been a few changes but nothing that is likely to affect this.
> I don't recall any changes that touched cookie paths in a long time.
>
> This looks like an app issue (or an issue in a library the app uses) to
> me at the moment.
>
> If you are able to reproduce this on a clean install of the latest
> 10.1.x release (or any other currently supported version) I'd be happy
> to take another look. All we'd need would be the steps to recreate the
> issue from the clean install.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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.
Re: Session Cookie Logging
Posted by Mark Thomas <ma...@apache.org>.
On 26/01/2024 22:22, Dan McLaughlin wrote:
> 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.
I have tested this with a clean build of both 10.1.x and 11.0.x and both
correctly set the path to "/examples" when I open the Servlet session
example in the examples app with sessionCookieName="_Secure-JSESSIONID".
> 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 /.
Nope. Cookie processing doesn't require privileged.
> 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.
There have been a few changes but nothing that is likely to affect this.
I don't recall any changes that touched cookie paths in a long time.
This looks like an app issue (or an issue in a library the app uses) to
me at the moment.
If you are able to reproduce this on a clean install of the latest
10.1.x release (or any other currently supported version) I'd be happy
to take another look. All we'd need would be the steps to recreate the
issue from the clean install.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Cookie Logging
Posted by Dan McLaughlin <da...@danshome.net.INVALID>.
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 <kn...@gmail.com>
wrote:
> пт, 26 янв. 2024 г. в 04:01, Dan McLaughlin <da...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@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.
Re: Session Cookie Logging
Posted by Konstantin Kolinko <kn...@gmail.com>.
пт, 26 янв. 2024 г. в 04:01, Dan McLaughlin <da...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Cookie Logging
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 <da...@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 <da...@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 <da...@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 <da...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Session Cookie Logging
Posted by Dan McLaughlin <da...@danshome.net.INVALID>.
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 <da...@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 <da...@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 <da...@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 <da...@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.
Re: Session Cookie Logging
Posted by Dan McLaughlin <da...@danshome.net.INVALID>.
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 <da...@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 <da...@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 <da...@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.
Re: Session Cookie Logging
Posted by Dan McLaughlin <da...@danshome.net.INVALID>.
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 <da...@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 <da...@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.
Re: Session Cookie Logging
Posted by Dan McLaughlin <da...@danshome.net.INVALID>.
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 <da...@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.