Re: Session Cookie Logging

[Konstantin Kolinko]

пт, 26 янв. 2024 г. в 04:01, Dan McLaughlin :
>
> 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.
>
> 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="1"
>   useNaming="false"
>   sessionCookieName="__Host-JSESSIONID"
>   sessionCookiePath="/secure/Foo"
>   useHttpOnly="true"
>   cookies="true"
>   logEffectiveWebXml="false">
>   
> 
>
> 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.
>
> /secure/Foo
>
> 
> 30
> 
>   __Host-JSESSIONID
>   /secure/Foo
>   Session Cookie
>   true
>   true
>   -1
> 
> COOKIE
>   
>
> 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. "" setting is not processed by Tomcat.
Only your war name matters,
https://tomcat.apache.org/tomcat-10.1-doc/config/context.html#Naming

"Session Cookie"
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

Re: Tomcat not syncing existing sessions on restart

[Manak Bisht]

Hi Mark,
I tried running your *cluster-test* war example on a stock 8.5.98
installation, however, I am facing the same issue. Session sync does not
trigger on restarting a node. Could you please share your configuration?

Sincerely,
Manak Bisht

How to access the request URL in a custom valve implementation?

[Manak Bisht]

Hi,
I am trying to extend the AccessLogValve to modify logging behaviour for
certain URLs. However, I don't have access to the request object in the
AccessLogValve API. So, I am left with regex matching on the CharArrayWriter
message object. Is there a better way to do this?

Sincerely,
Manak Bisht

Re: How to access the request URL in a custom valve implementation?

[Tim Funk]

It depends on what you are trying to accomplish. ExtendedAccessLogValve is
a
little more flexible where you can write out arbitrary request
attributes but still format the request like the standard access
log. So you could have a filter set the value and not need to
write your own access logger.

-Tim

On Fri, Jan 26, 2024 at 5:47 AM Manak Bisht  wrote:

> Hi,
> I am trying to extend the AccessLogValve to modify logging behaviour for
> certain URLs. However, I don't have access to the request object in the
> AccessLogValve API. So, I am left with regex matching on the
> CharArrayWriter
> message object. Is there a better way to do this?
>

Re: How to access the request URL in a custom valve implementation?

[Tim Funk]

My bad - AccessLogValve also supports that feature too

   - *%{xxx}r* write value of ServletRequest attribute with name xxx (escaped
   if required, value ?? if request is null)

https://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Access_Logging

-Tim


On Fri, Jan 26, 2024 at 7:23 AM Tim Funk  wrote:

> It depends on what you are trying to accomplish. ExtendedAccessLogValve is
> a
> little more flexible where you can write out arbitrary request
> attributes but still format the request like the standard access
> log. So you could have a filter set the value and not need to
> write your own access logger.
>
> -Tim
>
> On Fri, Jan 26, 2024 at 5:47 AM Manak Bisht 
> wrote:
>
>> Hi,
>> I am trying to extend the AccessLogValve to modify logging behaviour for
>> certain URLs. However, I don't have access to the request object in the
>> AccessLogValve API. So, I am left with regex matching on the
>> CharArrayWriter
>> message object. Is there a better way to do this?
>>
>

Re: How to access the request URL in a custom valve implementation?

[Mark Thomas]

On 26/01/2024 10:46, Manak Bisht wrote:

Hi,
I am trying to extend the AccessLogValve to modify logging behaviour for
certain URLs. However, I don't have access to the request object in the
AccessLogValve API. So, I am left with regex matching on the CharArrayWriter
message object. Is there a better way to do this?


It depends what you are trying to do - which you haven't explained.

You have direct access to the request object in the invoke() method.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: How to access the request URL in a custom valve implementation?

[Manak Bisht]

I want to obfuscate values of query params for certain URLs, however, I
would still like to log the request. Therefore, I cannot use the existing
conditionif/conditionunless attributes that AccessLogValve provides.

Sincerely,
Manak Bisht

On Fri, Jan 26, 2024 at 6:18 PM Mark Thomas  wrote:

> On 26/01/2024 10:46, Manak Bisht wrote:
> > Hi,
> > I am trying to extend the AccessLogValve to modify logging behaviour for
> > certain URLs. However, I don't have access to the request object in the
> > AccessLogValve API. So, I am left with regex matching on the
> CharArrayWriter
> > message object. Is there a better way to do this?
>
> It depends what you are trying to do - which you haven't explained.
>
> You have direct access to the request object in the invoke() method.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: How to access the request URL in a custom valve implementation?

[Tim Funk]

See AbstractAccessLogValve (which AccessLogValve overrides)

Then you could override AbstractAccessLogValve.createAccessLogElement()
which has
case 'q':
return new QueryElement();

To possible do doing something like
case 'q':
return new ObfuscatedQueryElement();

Where ObfuscatedQueryElement is much like the existing QueryElement with
your additional requirements.
 They both would implement AccessLogElement which has access to the
Request object

-Tim

On Fri, Jan 26, 2024 at 7:58 AM Manak Bisht  wrote:

> I want to obfuscate values of query params for certain URLs, however, I
> would still like to log the request. Therefore, I cannot use the existing
> conditionif/conditionunless attributes that AccessLogValve provides.
>
>

Re: EOL - Tomcat versions

[Christopher Schultz]

Aryeh,

On 1/20/24 4:19 AM, Aryeh Friedman wrote:

Top posting since my comments are not 100% relevant to the issue in
the thread (i.e. related but not in detail).

It would be nice if Tomcat published EOL's since there are
applications (like HIPAA webapps [I do remote cardiac monitoring])
that are automatically declared to be insecure if the underlying
platform has any EOL'ed components (this why just upgraded from 9.0.35
to 9.0.85) and in some cases (like HIPAA) have goverment imposed fines
if there is a breach due to using EOL'ed components.   Thus there is a
need for known/published EOL dates in such apps.


What makes you think that we don't publish EOLs?

There is an EOL date for Tomcat 8.5. There is no EOL date for Tomcat 9 
(yet). Shall we just pick a date far into the future and say "we know 
that 3 years from now, you are out of luck"? Or should we want until we 
know what the data is going to be and /then/ publish it?


We have an (unwritten) policy to give 1 year of notice for any EOL 
announcement. We aren't going to say "oh BTW this is the last release 
YOLO" and walk away.


The announcement for 8.5's EOL date (2024-03-31) was made on 2022-12-13, 
over a year in advance.


The announcement for 8.0's EOL date (2018-06-30) was made on 2017-06-30, 
exactly a year in advance.


The announcement for 7.0's EOL date (2021-03-31) was made on 2020-03-02, 
a year in advance.


The announcement for 6.0's EOL date (2016-12-31) was made on 2015-06-03, 
18 months in advance. There were security updates made to Tomcat 6 which 
extended *beyond* that EOL date, so we even supported it *after* the 
announced EOL date.


You will have plenty of notice.

Plus if you are on Tomcat 9, you can /already upgrade to Tomcat 10 or 
11/ neither of which have been EOL'd and are unlikely to experience such 
things until long after Tomcat 9 goes EOL.


If you want to avoid being caught up by Tomcat 9's EOL, then upgrade in 
advance.


I would like to mention that no Tomcat 9 releases have reached EOL. That 
means that your 9.0.35 version had not reached any EOL per se. There 
have been some security fixes applied in the intervening months which 
may be important for your environment, but this team does not provide 
support for specific releases.


HIPAA does not have a fine structure for use of out-of-date software. If 
you suffer a breach and an investigation reveals that a CE or BA was 
using software with known, unpatched vulnerabilites, *that's* what gets 
you into trouble.


-chris


On Fri, Jan 19, 2024 at 6:58 PM Mark Thomas  wrote:


On 19/01/2024 19:06, Francisco Dellanio Leite Alencar wrote:

@Mark Thomas,

Is it possible to consider that the minimum support time of Apache Tomcat 9.0.X 
is until 2027 (10 years since Released)?


I'd say 2027 is a reasonable estimate of the likely EOL date for 9.0.x
but I'm not going to provide any guarantees on that.

The Tomcat community has committed to providing at least 12 months
notice of EOL of any major version.

More detail in the thread listed below against 9.0.x.

If long term support is your concern then I'd consider looking at Tomcat
10.1.x. It does require Java 11 (Tomcat 9.0.x requires Java 8) but it
will get you an additional ~3 years support.

I will take the opportunity to point out that what you get with Tomcat
is already pretty good.

- major versions support for ~10 years including new features, bug
fixes and security fixes

- monthly releases throughout that ~10 year period (with the odd gap)

- all reproducible bugs reported fixed in the next release (this is the
one where Tomcat really stands out)

- you can actually talk to the folks the maintain the code


If you really need 9.0.x and really need guarantees on dates then there
are commercial organizations that will sell you that service. Just make
sure you pick one that has the skills and in-depth Tomcat knowledge
necessary to deliver that support.

Mark





Thanks.



On 2024/01/08 08:42:28 Mark Thomas wrote:



On 08/01/2024 06:47, i...@flyingfischer.ch wrote:

https://endoflife.date/tomcat

Am 08.01.24 um 07:39 schrieb Deshmukh, Kedar:

Hello,

Could you please throw some light on Tomcat versions and its EOL plan?


See https://tomcat.apache.org/whichversion.html


 1.  8.5.X


EOL 31 March 2024


 2.  9.0.X


No plans.
See https://lists.apache.org/thread/qlzpscgoqct9wspkj5qjkm34s66jswj0


 3.  10.0.X


Already EOL as of 31 October 2022


 4.  10.1.X


No plans.
See https://lists.apache.org/thread/qlzpscgoqct9wspkj5qjkm34s66jswj0

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



--

Re: Cannot Start Tomcat Windows Service_01/21/24

[Christopher Schultz]

To whom it may concern,

On 1/21/24 2:59 PM, support wrote:
I receive the Windows error below every time I try to start the Tomcat 
Windows service after modifying the server.xml file to require TLS. I 
used the instructions below and other online sources to find the proper 
syntax to modify server.xml. Nothing has worked. I used the *keytool 
*commands to create my own keystore and self-signed certificate.

**
*Instructions*
https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html 


*Key Information*
keytool -genkeypair -alias  -keyalg RSA -validity 1095 -keystore 
"C:\Program Files\Apache Software Foundation\Tomcat 
9.0_Tomcat9.0.85\conf\Certificates\"


The above command will not work as written. You can't point -keystore to 
a directory. It must be a file.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: EOL - Tomcat versions

[Aryeh Friedman]

On Fri, Jan 26, 2024 at 1:57 PM Christopher Schultz
 wrote:
>
> Aryeh,
>
> On 1/20/24 4:19 AM, Aryeh Friedman wrote:
> > Top posting since my comments are not 100% relevant to the issue in
> > the thread (i.e. related but not in detail).
> >
> > It would be nice if Tomcat published EOL's since there are
> > applications (like HIPAA webapps [I do remote cardiac monitoring])
> > that are automatically declared to be insecure if the underlying
> > platform has any EOL'ed components (this why just upgraded from 9.0.35
> > to 9.0.85) and in some cases (like HIPAA) have goverment imposed fines
> > if there is a breach due to using EOL'ed components.   Thus there is a
> > need for known/published EOL dates in such apps.
>
> What makes you think that we don't publish EOLs?
>
> There is an EOL date for Tomcat 8.5. There is no EOL date for Tomcat 9
> (yet). Shall we just pick a date far into the future and say "we know
> that 3 years from now, you are out of luck"? Or should we want until we
> know what the data is going to be and /then/ publish it?
>
> We have an (unwritten) policy to give 1 year of notice for any EOL
> announcement. We aren't going to say "oh BTW this is the last release
> YOLO" and walk away.
>
> The announcement for 8.5's EOL date (2024-03-31) was made on 2022-12-13,
> over a year in advance.
>
> The announcement for 8.0's EOL date (2018-06-30) was made on 2017-06-30,
> exactly a year in advance.
>
> The announcement for 7.0's EOL date (2021-03-31) was made on 2020-03-02,
> a year in advance.
>
> The announcement for 6.0's EOL date (2016-12-31) was made on 2015-06-03,
> 18 months in advance. There were security updates made to Tomcat 6 which
> extended *beyond* that EOL date, so we even supported it *after* the
> announced EOL date.
>
> You will have plenty of notice.

Thanks for clarifying that.

>
> HIPAA does not have a fine structure for use of out-of-date software. If
> you suffer a breach and an investigation reveals that a CE or BA was
> using software with known, unpatched vulnerabilites, *that's* what gets
> you into trouble.

Not completely true while "officially" your correct in reality OCR
(Office of Civil Rights of HHS) has a number of times said that EOL'ed
is tell-tell sign of not meeting the security rule:

https://www.proactive-info.com/blog/how-hipaa-compliance-relates-to-end-of-life

If you wish I can send you privately a sanitized version of report we
wrote for our client that details the implications of EOL and our
current system (which we just did a whole sale upgrade specifically
for HIPAA reasons and was triggered by a CVE posted on this list
[among a few other minor CVE's in other system components]).



-- 
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Session Cookie Logging

[Christopher Schultz]

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  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  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  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:


   30


Or do they get merged?

Thanks,

Dan

On Thu, Jan 25, 2024 at 7:00 PM Dan McLaughlin  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.

  
   


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.

/secure/Foo


 30
 
   __Host-JSESSIONID
   /secure/Foo
   Session Cookie
   true
   true
   -1
 
 COOKIE
   

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

Re: Session Cookie Logging

[Dan McLaughlin]

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 
wrote:

> пт, 26 янв. 2024 г. в 04:01, Dan McLaughlin :
> >
> > 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.
> >
> >   >   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="1"
> >   useNaming="false"
> >   sessionCookieName="__Host-JSESSIONID"
> >   sessionCookiePath="/secure/Foo"
> >   useHttpOnly="true"
> >   cookies="true"
> >   logEffectiveWebXml="false">
> >   
> > 
> >
> > 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.
> >
> > /secure/Foo
> >
> > 
> > 30
> > 
> >   __Host-JSESSIONID
> >   /secure/Foo
> >   Session Cookie
> >   true
> >   true
> >   -1
> > 
> > COOKIE
> >   
> >
> > 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. "" setting is not processed by Tomcat.
> Only your war name matters,
> https://tomcat.apache.org/tomcat-10.1-doc/config/context.html#Naming
>
> "Session Cookie"
> 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 de

Re: Session Cookie Logging

[Mark Thomas]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org