Re: Session Cookie Logging

[Dan McLaughlin]

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

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


 --

 Thanks,

 Dan

>>>

-- 








*NOTICE:* This e-mail message and all attachments transmitted with 
it are for 

Re: Session Cookie Logging

[Dan McLaughlin]

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

[Dan McLaughlin]

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

[Dan McLaughlin]

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

Session Cookie Logging

[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.

 
  


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

-- 








*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: Tomcat Version 9.0.79 - SAML2 - - Error occurred while attempting to refresh metadata from ':\WEB-INF\idp-meta-downloaded.xml'

[Mark Thomas]

On 25/01/2024 13:55, Tobias Blum (Fujitsu) wrote:

Hello together,

we have updated the Tomcat from Version 9.0.65 to Version 9.0.79.

We are running tomcat on Windows Server 2019

Our Tomcat Version is delivered with SAP BusinessObjects.

We have configured for our Web Application which runs on the Tomcat the 
SAML2 Authentication, after the update to the Version  9.0.79 we are 
seeing in the “stdout.log” File the following message:


13:26:17.576 [main] ERROR 
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider - 
Error occurred while attempting to refresh metadata from 
'E:\WEB-INF\idp-meta-downloaded.xml'
org.opensaml.saml2.metadata.provider.MetadataProviderException: Metadata 
file 'E:\WEB-INF\idp-meta-downloaded.xml' does not exist


We are not understand the message is popping up now and why the Tomcat 
is searching outside of his Installation Directory (E:\BO\tomcat) . I’m 
search on Google and Tomcat Help Pages, but I not found how we can 
adjust the search location for the SAML2 Metadata Provider File?


Can you help us here? Is this a wrong configuration? Or a Problem with 
Tomcat?


This isn't something the Tomcat community can help you with. You need to 
contact whichever organization provides you with support for Business 
Objects and/or OpenSAML.


Mark


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

Tomcat Version 9.0.79 - SAML2 - - Error occurred while attempting to refresh metadata from ':\WEB-INF\idp-meta-downloaded.xml'

[Tobias Blum (Fujitsu)]

Hello together,

we have updated the Tomcat from Version 9.0.65 to Version 9.0.79.

We are running tomcat on Windows Server 2019

Our Tomcat Version is delivered with SAP BusinessObjects.

We have configured for our Web Application which runs on the Tomcat the SAML2 
Authentication, after the update to the Version  9.0.79 we are seeing in the 
"stdout.log" File the following message:

13:26:17.576 [main] ERROR 
org.opensaml.saml2.metadata.provider.AbstractReloadingMetadataProvider - Error 
occurred while attempting to refresh metadata from 
'E:\WEB-INF\idp-meta-downloaded.xml'
org.opensaml.saml2.metadata.provider.MetadataProviderException: Metadata file 
'E:\WEB-INF\idp-meta-downloaded.xml' does not exist

We are not understand the message is popping up now and why the Tomcat is 
searching outside of his Installation Directory (E:\BO\tomcat) . I'm search on 
Google and Tomcat Help Pages, but I not found how we can adjust the search 
location for the SAML2 Metadata Provider File?

Can you help us here? Is this a wrong configuration? Or a Problem with Tomcat?

Mit freundlichen Grüßen / best regards
Tobias Blum B.Sc.
Principal SAP Technical Consultant / Teamlead
FJ CE SD BA PBS SAP B 7


[Associate]

Certified SAP Business Objects BIP 4.1
Certified SAP Business Objects BIP 
4.3
Certified SAP System Administration NW 7.31 (Oracle 
DB)
Microsoft AZURE 
Administrator

[cid:image002.png@01DA4F9D.4F652760]
Fujitsu
Konrad-Zuse-Straße 16, 74172 Neckarsulm, Germany
T  +49 7132 366-
M-
F  -
E  tobias.b...@fujitsu.com
Wfujitsu.com
Firmenangaben Fujitsu Services 
GmbH

[cid:image003.png@01DA4F9D.4F652760]
  [cid:image004.png@01DA4F9D.4F652760]    
[cid:image005.png@01DA4F9D.4F652760]    
[cid:image006.png@01DA4F9D.4F652760] 
   
[cid:image007.png@01DA4F9D.4F652760] 



Working Hours (normal case):
- 05:00am to 2:30pm CET

OnCall Duty:
-

Next planned absence:
-

Allgemeine Informationen zur Datenverarbeitung im Rahmen unserer allgemeinen 
Geschäftstätigkeit in Deutschland sind 
hier
 abrufbar.