subject:"RE\: question"

Re: Question on the ErrorReportValve

2024-04-18 Thread Christopher Schultz


Jon,

On 4/17/24 13:26, Mcalexander, Jon J. wrote:

Thank you. The documentation makes it somewhat confusing because it
starts out that a Valve can exist in Engine, Host, and Context
Containers, and then in the subsequent valve list is the
ErrorReportValve, but it doesn’t make it clear as to where it can go.
If we put one in the Engine container, does it then also cover the
Host containers since If you are willing to write-up a documentation patch, we can commit it 
for you.


-chris


From: Konstantin Kolinko 
Sent: Wednesday, April 17, 2024 10:44 AM
To: Tomcat Users List 
Subject: Re: Question on the ErrorReportValve

пн, 15 апр. 2024 г. в 19: 37, Mcalexander, Jon J. : > > Hi all! > Quick question on the ErrorReportValve and location within 
the server. xml file. I know that typically this would be inside


пн, 15 апр. 2024 г. в 19:37, Mcalexander, Jon J.

mailto:jonmcalexan...@wellsfargo.com.invalid>>:






Hi all!



Quick question on the ErrorReportValve and location within the server.xml file. I know that 
typically this would be inside the  element, but if you have Multiple 
 elements, do you add the valve to each Host section, or can it be placed at the 
Engine or even Server level?




Unlikely.



A Valve is expected to be in a certain place on the request processing pipeline.



Note that a Host has an attribute named errorReportValveClass. If you

do not specify a Valve explicitly, a default one will be created.



Best regards,

Konstantin Kolinko



-

To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org>

For additional commands, e-mail: 
users-h...@tomcat.apache.org<mailto: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: Question on the ErrorReportValve

2024-04-17 Thread Mcalexander, Jon J.

Thank you. The documentation makes it somewhat confusing because it starts out 
that a Valve can exist in Engine, Host, and Context Containers, and then in the 
subsequent valve list is the ErrorReportValve, but it doesn’t make it clear as 
to where it can go. If we put one in the Engine container, does it then also 
cover the Host containers since mailto:jonmcalexan...@wellsfargo.com>
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

From: Konstantin Kolinko 
Sent: Wednesday, April 17, 2024 10:44 AM
To: Tomcat Users List 
Subject: Re: Question on the ErrorReportValve

пн, 15 апр. 2024 г. в 19: 37, Mcalexander, Jon J. : > > Hi all! > Quick question on the ErrorReportValve and 
location within the server. xml file. I know that typically this would be inside


пн, 15 апр. 2024 г. в 19:37, Mcalexander, Jon J.

mailto:jonmcalexan...@wellsfargo.com.invalid>>:

>

> Hi all!

> Quick question on the ErrorReportValve and location within the server.xml 
> file. I know that typically this would be inside the  
> element, but if you have Multiple  elements, do you add the valve to 
> each Host section, or can it be placed at the Engine or even Server level?



Unlikely.



A Valve is expected to be in a certain place on the request processing pipeline.



Note that a Host has an attribute named errorReportValveClass. If you

do not specify a Valve explicitly, a default one will be created.



Best regards,

Konstantin Kolinko



-

To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org>

For additional commands, e-mail: 
users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>

Re: Question on the ErrorReportValve

2024-04-17 Thread Konstantin Kolinko

пн, 15 апр. 2024 г. в 19:37, Mcalexander, Jon J.
:
>
> Hi all!
> Quick question on the ErrorReportValve and location within the server.xml 
> file. I know that typically this would be inside the  
> element, but if you have Multiple  elements, do you add the valve to 
> each Host section, or can it be placed at the Engine or even Server level?

Unlikely.

A Valve is expected to be in a certain place on the request processing pipeline.

Note that a Host has an attribute named errorReportValveClass. If you
do not specify a Valve explicitly, a default one will be created.

Best regards,
Konstantin Kolinko

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

RE: Question on the ErrorReportValve

2024-04-15 Thread Mcalexander, Jon J.

Thanks Chris.

Yes, it’s probably academic, but I was mainly looking for opinions from the 
true “experts” out there. 

When I get free time to do so, I’ll play around with it.

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

From: Christopher Schultz 
Sent: Monday, April 15, 2024 12:26 PM
To: Tomcat Users List ; Mcalexander, Jon J. 

Subject: Re: Question on the ErrorReportValve

Jon, On 4/15/24 12: 36, Mcalexander, Jon J. wrote: > Quick question on the 
ErrorReportValve and location within the server. xml file. I know that 
typically this would be inside the  element, but if you have 
Multiple

Jon,

On 4/15/24 12:36, Mcalexander, Jon J. wrote:

> Quick question on the ErrorReportValve and location within the server.xml 
> file. I know that typically this would be inside the  
> element, but if you have Multiple  elements, do you add the valve to 
> each Host section, or can it be placed at the Engine or even Server level?

The configuration reference doesn't specify, but the Javadoc says it

"should be" used in  but "should work in ".

I would think you'd want to separately configure them for each ,

anyway.

Is this an academic question? It seems like a very easy think to just

try out and see what happens. :)

-chris

-

To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org>

For additional commands, e-mail: 
users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>

Re: Question on the ErrorReportValve

2024-04-15 Thread Christopher Schultz


Jon,

On 4/15/24 12:36, Mcalexander, Jon J. wrote:

Quick question on the ErrorReportValve and location within the server.xml file. I know that 
typically this would be inside the  element, but if you have Multiple 
 elements, do you add the valve to each Host section, or can it be placed at the 
Engine or even Server level?


The configuration reference doesn't specify, but the Javadoc says it 
"should be" used in  but "should work in ".


I would think you'd want to separately configure them for each , 
anyway.


Is this an academic question? It seems like a very easy think to just 
try out and see what happens. :)


-chris

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

Re: Question about releases available for download

2023-10-19 Thread Christopher Schultz


Jon,

On 10/19/23 11:33, Mcalexander, Jon J. wrote:

Ding Ding Ding. Chris wins! Yes, that was the word.


https://www.youtube.com/watch?v=NtfVgzXTp7Q

-chris


-Original Message-
From: Christopher Schultz 
Sent: Wednesday, October 18, 2023 9:42 PM
To: users@tomcat.apache.org
Subject: Re: Question about releases available for download

Jon,

On 10/18/23 15:39, Mcalexander, Jon J. wrote:

Thanks Mark. I'm sorry if I stated it incorrectly. I meant the issue
with JDBC being broken, etc. the stuff that prompted the immediate new
releases.

I think the word you were looking for was "regression", not "recursion" ;)

-chris


-Original Message-
From: Mark Thomas 
Sent: Wednesday, October 18, 2023 2:04 PM
To: users@tomcat.apache.org
Subject: Re: Question about releases available for download

On 18/10/2023 18:29, Mcalexander, Jon J. wrote:

Hi Mark, et-al,

With the recursion error with these releases in mind, should 8.5.94,
9.0.81,

and 10.1.15 be available for download via the archives? Should they
not be removed and a not placed in the location that they have been
removed due to introduced issues?

Recursion error?

Regardless, all ASF releases will always be available from the ASF archives.
That is ASF policv and I don't see it changing.

Yes, old releases have bugs and/or security issues. Yes, some of
those bugs / security issues are quite nasty. That is why we always
recommend using the latest release of a current supported major version.

Maven Central has a similar policy. Once a release is published to
Maven Central it is pretty much impossible to get it removed.

Mark



Just asking,

Thanks.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508





jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>

This message may contain confidential and/or privileged information.
If you

are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply
e-mail and delete this message. Thank you for your cooperation.





-
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



-
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



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

RE: Question about releases available for download

2023-10-19 Thread Mcalexander, Jon J.

Ding Ding Ding. Chris wins! Yes, that was the word.

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Christopher Schultz 
> Sent: Wednesday, October 18, 2023 9:42 PM
> To: users@tomcat.apache.org
> Subject: Re: Question about releases available for download
> 
> Jon,
> 
> On 10/18/23 15:39, Mcalexander, Jon J. wrote:
> > Thanks Mark. I'm sorry if I stated it incorrectly. I meant the issue
> > with JDBC being broken, etc. the stuff that prompted the immediate new
> > releases.
> I think the word you were looking for was "regression", not "recursion" ;)
> 
> -chris
> 
> >> -Original Message-
> >> From: Mark Thomas 
> >> Sent: Wednesday, October 18, 2023 2:04 PM
> >> To: users@tomcat.apache.org
> >> Subject: Re: Question about releases available for download
> >>
> >> On 18/10/2023 18:29, Mcalexander, Jon J. wrote:
> >>> Hi Mark, et-al,
> >>>
> >>> With the recursion error with these releases in mind, should 8.5.94,
> >>> 9.0.81,
> >> and 10.1.15 be available for download via the archives? Should they
> >> not be removed and a not placed in the location that they have been
> >> removed due to introduced issues?
> >>
> >> Recursion error?
> >>
> >> Regardless, all ASF releases will always be available from the ASF 
> >> archives.
> >> That is ASF policv and I don't see it changing.
> >>
> >> Yes, old releases have bugs and/or security issues. Yes, some of
> >> those bugs / security issues are quite nasty. That is why we always
> >> recommend using the latest release of a current supported major version.
> >>
> >> Maven Central has a similar policy. Once a release is published to
> >> Maven Central it is pretty much impossible to get it removed.
> >>
> >> Mark
> >>
> >>>
> >>> Just asking,
> >>>
> >>> Thanks.
> >>>
> >>> Dream * Excel * Explore * Inspire
> >>> Jon McAlexander
> >>> Senior Infrastructure Engineer
> >>> Asst. Vice President
> >>> He/His
> >>>
> >>> Middleware Product Engineering
> >>> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >>>
> >>> 8080 Cobblestone Rd | Urbandale, IA 50322
> >>> MAC: F4469-010
> >>> Tel 515-988-2508 | Cell 515-988-2508
> >>>
> >>>
> >>
> jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
> >>> This message may contain confidential and/or privileged information.
> >>> If you
> >> are not the addressee or authorized to receive this for the
> >> addressee, you must not use, copy, disclose, or take any action based
> >> on this message or any information herein. If you have received this
> >> message in error, please advise the sender immediately by reply
> >> e-mail and delete this message. Thank you for your cooperation.
> >>>
> >>>
> >>
> >> -
> >> 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
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Question about releases available for download

2023-10-18 Thread Christopher Schultz


Jon,

On 10/18/23 15:39, Mcalexander, Jon J. wrote:

Thanks Mark. I'm sorry if I stated it incorrectly. I meant the issue
with JDBC being broken, etc. the stuff that prompted the immediate
new releases.

I think the word you were looking for was "regression", not "recursion" ;)

-chris


-Original Message-
From: Mark Thomas 
Sent: Wednesday, October 18, 2023 2:04 PM
To: users@tomcat.apache.org
Subject: Re: Question about releases available for download

On 18/10/2023 18:29, Mcalexander, Jon J. wrote:

Hi Mark, et-al,

With the recursion error with these releases in mind, should 8.5.94, 9.0.81,

and 10.1.15 be available for download via the archives? Should they not be
removed and a not placed in the location that they have been removed due
to introduced issues?

Recursion error?

Regardless, all ASF releases will always be available from the ASF archives.
That is ASF policv and I don't see it changing.

Yes, old releases have bugs and/or security issues. Yes, some of those bugs /
security issues are quite nasty. That is why we always recommend using the
latest release of a current supported major version.

Maven Central has a similar policy. Once a release is published to Maven
Central it is pretty much impossible to get it removed.

Mark



Just asking,

Thanks.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508



jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>

This message may contain confidential and/or privileged information. If you

are not the addressee or authorized to receive this for the addressee, you
must not use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you
for your cooperation.





-
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



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

RE: Question about releases available for download

2023-10-18 Thread Mcalexander, Jon J.

Thanks Mark. I'm sorry if I stated it incorrectly. I meant the issue with JDBC 
being broken, etc. the stuff that prompted the immediate new releases.

Thank you!

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.

> -Original Message-
> From: Mark Thomas 
> Sent: Wednesday, October 18, 2023 2:04 PM
> To: users@tomcat.apache.org
> Subject: Re: Question about releases available for download
> 
> On 18/10/2023 18:29, Mcalexander, Jon J. wrote:
> > Hi Mark, et-al,
> >
> > With the recursion error with these releases in mind, should 8.5.94, 9.0.81,
> and 10.1.15 be available for download via the archives? Should they not be
> removed and a not placed in the location that they have been removed due
> to introduced issues?
> 
> Recursion error?
> 
> Regardless, all ASF releases will always be available from the ASF archives.
> That is ASF policv and I don't see it changing.
> 
> Yes, old releases have bugs and/or security issues. Yes, some of those bugs /
> security issues are quite nasty. That is why we always recommend using the
> latest release of a current supported major version.
> 
> Maven Central has a similar policy. Once a release is published to Maven
> Central it is pretty much impossible to get it removed.
> 
> Mark
> 
> >
> > Just asking,
> >
> > Thanks.
> >
> > Dream * Excel * Explore * Inspire
> > Jon McAlexander
> > Senior Infrastructure Engineer
> > Asst. Vice President
> > He/His
> >
> > Middleware Product Engineering
> > Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >
> > 8080 Cobblestone Rd | Urbandale, IA 50322
> > MAC: F4469-010
> > Tel 515-988-2508 | Cell 515-988-2508
> >
> >
> jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com>
> > This message may contain confidential and/or privileged information. If you
> are not the addressee or authorized to receive this for the addressee, you
> must not use, copy, disclose, or take any action based on this message or any
> information herein. If you have received this message in error, please advise
> the sender immediately by reply e-mail and delete this message. Thank you
> for your cooperation.
> >
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Question about releases available for download

2023-10-18 Thread Mark Thomas


On 18/10/2023 18:29, Mcalexander, Jon J. wrote:

Hi Mark, et-al,

With the recursion error with these releases in mind, should 8.5.94, 9.0.81, 
and 10.1.15 be available for download via the archives? Should they not be 
removed and a not placed in the location that they have been removed due to 
introduced issues?


Recursion error?

Regardless, all ASF releases will always be available from the ASF 
archives. That is ASF policv and I don't see it changing.


Yes, old releases have bugs and/or security issues. Yes, some of those 
bugs / security issues are quite nasty. That is why we always recommend 
using the latest release of a current supported major version.


Maven Central has a similar policy. Once a release is published to Maven 
Central it is pretty much impossible to get it removed.


Mark



Just asking,

Thanks.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.




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

Re: question about tomcat manager Server Status page

2023-09-08 Thread Ivano Luberti


Thanks Christopher

Il 08/09/2023 17:51, Christopher Schultz ha scritto:

Ivano,

On 9/8/23 11:17, Ivano Luberti wrote:

Hi, looking at Server Status and Complete Server Status Page

I can see the following line:

Max threads: 200 Current thread count: 11 Current threads busy: 1 
Keep alive sockets count: 1


But looking at the thread list under the line I can count 24 lines.

So what is the number of thread currently instantiated by tomcat? 11 
or 24?


This is a good question. When I check my localhost Manager running 
8.5.x, I see this:


Max threads: -1 Current thread count: 4 Current threads busy: 1 Keep 
alive sockets count: 1


The number of threads shown in the http-nio-host-port section shows 5 
threads, 4 in the R state and one in the S state.


When running jstack against my JVM, I can see that there are only 4 
exec threads running.


So I think the claim that there are only 11 threads in your JVM is 
correct. I believe the 24 lines you are seeing are something buggy in 
the Manager's view. I'll see if I can play around with it a little bit 
to see what's happening.


-chris

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


--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

Re: question about tomcat manager Server Status page

2023-09-08 Thread Christopher Schultz


Ivano,

On 9/8/23 11:17, Ivano Luberti wrote:

Hi, looking at Server Status and Complete Server Status Page

I can see the following line:

Max threads: 200 Current thread count: 11 Current threads busy: 1 Keep 
alive sockets count: 1


But looking at the thread list under the line I can count 24 lines.

So what is the number of thread currently instantiated by tomcat? 11 or 24?


This is a good question. When I check my localhost Manager running 
8.5.x, I see this:


Max threads: -1 Current thread count: 4 Current threads busy: 1 Keep 
alive sockets count: 1


The number of threads shown in the http-nio-host-port section shows 5 
threads, 4 in the R state and one in the S state.


When running jstack against my JVM, I can see that there are only 4 exec 
threads running.


So I think the claim that there are only 11 threads in your JVM is 
correct. I believe the 24 lines you are seeing are something buggy in 
the Manager's view. I'll see if I can play around with it a little bit 
to see what's happening.


-chris

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

Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"

2023-05-09 Thread Mark Thomas


On 08/05/2023 22:04, Christopher Schultz wrote:

On 5/8/23 10:39, Mark Thomas wrote:




The port the client connects to is irrelevant. All that matters is the 
host in the request line and the host header.


1. The host header MUST be present
2. If a host is present in the request line it MUST be identical (host 
and port) to the host header.


nb the spec says that the URL takes precedence if there is a mismatch, 
but when setting allowHostHeaderMismatch="false" (the current default), 
then Tomcat is being stricter than the spec.


That is not correct. The two requirements stated above have been RFC 
"MUST" requirements since 2014.


RFC 2616 (June 1999) stated that any host in the request line takes 
precedence.


RFC 7230 (June 2014) stated that any host in the request line MUST match 
the host header although there is also language that suggests they might 
be different.


RFC 9112 (June 2022) states that any host in the request line MUST match 
the host header.


Mark

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

RE: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"

2023-05-08 Thread Alvaro Garay

Hi,

This makes sense now. Thank you for clarifying.

Best,
Alvaro

From: Christopher Schultz 
Sent: Monday, May 8, 2023 5:04 PM
To: users@tomcat.apache.org 
Subject: [EXTERNAL] Re: Question in regards to the Connector 
allowHostHeaderMismatch when it is set to "false"

Alvaro,

On 5/8/23 10:39, Mark Thomas wrote:
> On 08/05/2023 13:52, Alvaro Garay wrote:
>> Hi Mark,
>>
>> In the example above...the port remains the same (8143). How is it
>> different?
>
> GET http://myhostname.company.com/api/v1/endpoint   HTTP/1.1
>
> The host is "myhostname.company.com"
>
> Host: myhostname.company.com:8143
>
> The host is "myhostname.company.com:8143"
>
> "myhostname.company.com" != "myhostname.company.com:8143"
>
> The port the client connects to is irrelevant. All that matters is the
> host in the request line and the host header.
>
> 1. The host header MUST be present
> 2. If a host is present in the request line it MUST be identical (host
> and port) to the host header.

nb the spec says that the URL takes precedence if there is a mismatch,
but when setting allowHostHeaderMismatch="false" (the current default),
then Tomcat is being stricter than the spec.

The reason Tomcat is being stricter than the spec by default is because
usually Host <> URL host mismatch is an indication that the client is
doing something it should not be doing.

-chris

>> From: Mark Thomas 
>> Sent: Friday, May 5, 2023 4:56 PM
>> To: Tomcat Users List 
>> Subject: [EXTERNAL] Re: Question in regards to the Connector
>> allowHostHeaderMismatch when it is set to "false"
>>
>>
>> 5 May 2023 18:21:02 Alvaro Garay :
>>
>>> Hi,
>>>
>>>
>>> Tomcat version: 9.0.73
>>>
>>> Operating system: Unix z/OS System
>>>
>>>
>>>
>>> I have a question in regard to the Connector attribute
>>> allowHostHeaderMismatch=false which checks the request line is
>>> consistent with the Host Header.
>>>
>>> So in this scenario, I have the request line using the absolute path
>>> with a conflicting host header. The response is 400 Bad Request from
>>> Tomcat, which makes sense.
>>>
>>> telnet myhostname.company.com 8143
>>> GET http://myhostname.company.com/api/v1/endpoint   HTTP/1.1
>>> Host: facebook.com
>>>
>>>
>>> If I define a valid host header now, then the request is a success. So
>>> all is good.
>>>
>>> telnet myhostname.company.com 8143
>>> GET http://myhostname.company.com/api/v1/endpoint   HTTP/1.1
>>> Host: myhostname.company.com
>>>
>>> telnet 1.1.1.1 8143
>>> GET http://1.1.1.1/api/v1/endpoint   HTTP/1.1
>>> Host: 1.1.1.1
>>>
>>> However, as soon as I define a port number in the host header with
>>> syntax : then I get 400 Bad Request from Tomcat.
>>>
>>> telnet myhostname.company.com 8143
>>> GET http://myhostname.company.com/api/v1/endpoint   HTTP/1.1
>>> Host: myhostname.company.com:8143
>>>
>>> HTTP/1.1 400
>>> Content-Type: text/html;charset=utf-8
>>> Content-Language: en
>>> Content-Length: 762
>>> Date: Fri, 05 May 2023 15:27:09 GMT
>>> Connection: close
>>>
>>> HTTP Status 400 \u2013 Bad
>>> Requestbody
>>> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
>>> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
>>> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
>>> {color:black;} .line
>>> {height:1px;background-color:#525D76;border:none;}HTTP
>>> Status 400 \u2013 Bad RequestType
>>> Status ReportDescription The server cannot or will not
>>> process the request due to something that is perceived to be a client
>>> error (e.g., malformed request syntax, invalid request message framing,
>>> or deceptive request routing).Apache
>>> Tomcat/9.0.73
>>>
>>> This request should be allowed right?
>>
>> No. Different port means a different host so Tomcat correctly rejects the
>> request.
>>
>> 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
>

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

Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"

2023-05-08 Thread Christopher Schultz


Alvaro,

On 5/8/23 10:39, Mark Thomas wrote:

On 08/05/2023 13:52, Alvaro Garay wrote:

Hi Mark,

In the example above...the port remains the same (8143). How is it 
different?


GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1

The host is "myhostname.company.com"

Host: myhostname.company.com:8143

The host is "myhostname.company.com:8143"

"myhostname.company.com" != "myhostname.company.com:8143"

The port the client connects to is irrelevant. All that matters is the 
host in the request line and the host header.


1. The host header MUST be present
2. If a host is present in the request line it MUST be identical (host 
and port) to the host header.


nb the spec says that the URL takes precedence if there is a mismatch, 
but when setting allowHostHeaderMismatch="false" (the current default), 
then Tomcat is being stricter than the spec.


The reason Tomcat is being stricter than the spec by default is because 
usually Host <> URL host mismatch is an indication that the client is 
doing something it should not be doing.


-chris


From: Mark Thomas 
Sent: Friday, May 5, 2023 4:56 PM
To: Tomcat Users List 
Subject: [EXTERNAL] Re: Question in regards to the Connector 
allowHostHeaderMismatch when it is set to "false"



5 May 2023 18:21:02 Alvaro Garay :


Hi,


Tomcat version: 9.0.73

Operating system: Unix z/OS System



I have a question in regard to the Connector attribute
allowHostHeaderMismatch=false which checks the request line is
consistent with the Host Header.

So in this scenario, I have the request line using the absolute path
with a conflicting host header. The response is 400 Bad Request from
Tomcat, which makes sense.

telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
Host: facebook.com


If I define a valid host header now, then the request is a success. So
all is good.

telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
Host: myhostname.company.com

telnet 1.1.1.1 8143
GET http://1.1.1.1/api/v1/endpoint  HTTP/1.1
Host: 1.1.1.1

However, as soon as I define a port number in the host header with
syntax : then I get 400 Bad Request from Tomcat.

telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
Host: myhostname.company.com:8143

HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 762
Date: Fri, 05 May 2023 15:27:09 GMT
Connection: close

HTTP Status 400 \u2013 Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 \u2013 Bad RequestType
Status ReportDescription The server cannot or will not
process the request due to something that is perceived to be a client
error (e.g., malformed request syntax, invalid request message framing,
or deceptive request routing).Apache
Tomcat/9.0.73

This request should be allowed right?


No. Different port means a different host so Tomcat correctly rejects the
request.

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



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

Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"

2023-05-08 Thread Mark Thomas


On 08/05/2023 13:52, Alvaro Garay wrote:

Hi Mark,

In the example above...the port remains the same (8143). How is it different?


GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1

The host is "myhostname.company.com"

Host: myhostname.company.com:8143

The host is "myhostname.company.com:8143"

"myhostname.company.com" != "myhostname.company.com:8143"

The port the client connects to is irrelevant. All that matters is the 
host in the request line and the host header.


1. The host header MUST be present
2. If a host is present in the request line it MUST be identical (host 
and port) to the host header.


Mark




From: Mark Thomas 
Sent: Friday, May 5, 2023 4:56 PM
To: Tomcat Users List 
Subject: [EXTERNAL] Re: Question in regards to the Connector allowHostHeaderMismatch when 
it is set to "false"


5 May 2023 18:21:02 Alvaro Garay :


Hi,


Tomcat version: 9.0.73

Operating system: Unix z/OS System



I have a question in regard to the Connector attribute
allowHostHeaderMismatch=false which checks the request line is
consistent with the Host Header.

So in this scenario, I have the request line using the absolute path
with a conflicting host header. The response is 400 Bad Request from
Tomcat, which makes sense.

telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
Host: facebook.com


If I define a valid host header now, then the request is a success. So
all is good.

telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
Host: myhostname.company.com

telnet 1.1.1.1 8143
GET http://1.1.1.1/api/v1/endpoint  HTTP/1.1
Host: 1.1.1.1

However, as soon as I define a port number in the host header with
syntax : then I get 400 Bad Request from Tomcat.

telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
Host: myhostname.company.com:8143

HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 762
Date: Fri, 05 May 2023 15:27:09 GMT
Connection: close

HTTP Status 400 \u2013 Bad
Requestbody
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
{color:black;} .line
{height:1px;background-color:#525D76;border:none;}HTTP
Status 400 \u2013 Bad RequestType
Status ReportDescription The server cannot or will not
process the request due to something that is perceived to be a client
error (e.g., malformed request syntax, invalid request message framing,
or deceptive request routing).Apache
Tomcat/9.0.73

This request should be allowed right?


No. Different port means a different host so Tomcat correctly rejects the
request.

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: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"

2023-05-08 Thread Alvaro Garay

Hi Mark,

In the example above...the port remains the same (8143). How is it different?

From: Mark Thomas 
Sent: Friday, May 5, 2023 4:56 PM
To: Tomcat Users List 
Subject: [EXTERNAL] Re: Question in regards to the Connector 
allowHostHeaderMismatch when it is set to "false"


5 May 2023 18:21:02 Alvaro Garay :

> Hi,
>
>
> Tomcat version: 9.0.73
>
> Operating system: Unix z/OS System
>
>
>
> I have a question in regard to the Connector attribute
> allowHostHeaderMismatch=false which checks the request line is
> consistent with the Host Header.
>
> So in this scenario, I have the request line using the absolute path
> with a conflicting host header. The response is 400 Bad Request from
> Tomcat, which makes sense.
>
> telnet myhostname.company.com 8143
> GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
> Host: facebook.com
>
>
> If I define a valid host header now, then the request is a success. So
> all is good.
>
> telnet myhostname.company.com 8143
> GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
> Host: myhostname.company.com
>
> telnet 1.1.1.1 8143
> GET http://1.1.1.1/api/v1/endpoint  HTTP/1.1
> Host: 1.1.1.1
>
> However, as soon as I define a port number in the host header with
> syntax : then I get 400 Bad Request from Tomcat.
>
> telnet myhostname.company.com 8143
> GET http://myhostname.company.com/api/v1/endpoint  HTTP/1.1
> Host: myhostname.company.com:8143
>
> HTTP/1.1 400
> Content-Type: text/html;charset=utf-8
> Content-Language: en
> Content-Length: 762
> Date: Fri, 05 May 2023 15:27:09 GMT
> Connection: close
>
> HTTP Status 400 \u2013 Bad
> Requestbody
> {font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b
> {color:white;background-color:#525D76;} h1 {font-size:22px;} h2
> {font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a
> {color:black;} .line
> {height:1px;background-color:#525D76;border:none;}HTTP
> Status 400 \u2013 Bad RequestType
> Status ReportDescription The server cannot or will not
> process the request due to something that is perceived to be a client
> error (e.g., malformed request syntax, invalid request message framing,
> or deceptive request routing).Apache
> Tomcat/9.0.73
>
> This request should be allowed right?

No. Different port means a different host so Tomcat correctly rejects the
request.

Mark

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

Re: Question in regards to the Connector allowHostHeaderMismatch when it is set to "false"

2023-05-05 Thread Mark Thomas




5 May 2023 18:21:02 Alvaro Garay :


Hi,


Tomcat version: 9.0.73

Operating system: Unix z/OS System



I have a question in regard to the Connector attribute 
allowHostHeaderMismatch=false which checks the request line is 
consistent with the Host Header.


So in this scenario, I have the request line using the absolute path 
with a conflicting host header. The response is 400 Bad Request from 
Tomcat, which makes sense.


telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: facebook.com


If I define a valid host header now, then the request is a success. So 
all is good.


telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: myhostname.company.com

telnet 1.1.1.1 8143
GET http://1.1.1.1/api/v1/endpoint HTTP/1.1
Host: 1.1.1.1

However, as soon as I define a port number in the host header with 
syntax : then I get 400 Bad Request from Tomcat.


telnet myhostname.company.com 8143
GET http://myhostname.company.com/api/v1/endpoint HTTP/1.1
Host: myhostname.company.com:8143

HTTP/1.1 400
Content-Type: text/html;charset=utf-8
Content-Language: en
Content-Length: 762
Date: Fri, 05 May 2023 15:27:09 GMT
Connection: close

HTTP Status 400 \u2013 Bad 
Requestbody 
{font-family:Tahoma,Arial,sans-serif;} h1, h2, h3, b 
{color:white;background-color:#525D76;} h1 {font-size:22px;} h2 
{font-size:16px;} h3 {font-size:14px;} p {font-size:12px;} a 
{color:black;} .line 
{height:1px;background-color:#525D76;border:none;}HTTP 
Status 400 \u2013 Bad RequestType 
Status ReportDescription The server cannot or will not 
process the request due to something that is perceived to be a client 
error (e.g., malformed request syntax, invalid request message framing, 
or deceptive request routing).Apache 
Tomcat/9.0.73


This request should be allowed right?


No. Different port means a different host so Tomcat correctly rejects the 
request.


Mark

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

Re: Question regarding config.ini 'answer file' 2023-03-28 Thread Mark Thomas On 28/03/2023 20:49, Jason Murray | ROI Solutions wrote: Hello, Apologies if my this my first post is misdirected. It isn't. All is good but thanks for checking. In a nutshell: my goal is to automate Tomcat 8.5 upgrades on Windows Server as much as possible. More specifically, I have been looking to create a config.ini 'answer' file for installing Tomcat 8.5.x as a service on a Windows Server system. The installer Tomcat provides for Windows might not be the best way to do this. Splitting CATALINA_HOME and CATALINA_BASE (see "Advanced Configuration - Multiple Tomcat Instances" in RUNNING.txt) and using service.bat might be a simpler option. Specifically, the values I am looking to set are: * Server Shutdown Port * HTTP/1.1 Connector Port * Windows Service Name * Roles * Java path I couldn't locate them, are they listed anywhere? https://tomcat.apache.org/tomcat-8.5-doc/setup.html HTH, Mark The install path is also needed, but as I understand it, this is set with the /D flag while running the tomcat installer exe, eg: .\apache-tomcat-8.5.87.exe /S /D={install_directory} /C=config.ini Thanks for any guidance! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question regarding config.ini 'answer file' 2023-03-28 Thread Bill Stewart On Tue, Mar 28, 2023 at 1:50 PM Jason Murray | ROI Solutions wrote: In a nutshell: my goal is to automate Tomcat 8.5 upgrades on Windows Server > as much as possible. > Are you sure you need Tomcat 8.5? If you can use 9.x, my recommendation would be to install using this: https://github.com/Bill-Stewart/ApacheTomcatSetup It won't configure everything you're asking for, but it should get you most of the way there. The build process could be adjusted to accommodate 8.5, but I would think 9.x would be preferable. Re: Question about Redisson 2023-01-13 Thread Christopher Schultz Doug, On 1/12/23 15:51, Doug Whitfield wrote: Also, Chris's suggesiton to look at org.apache.catalina.connector.RECYCLE_FACADES is a good first step. Note that the value you need for that may not be what you expect. It needs to be "true" whereas I read the name and think it should be "false" to disable recycling. Thanks for coming back to this. This is actually exactly where I started, but I have not heard back, which is why I didn’t address it. BTW, can’t make any promises since not sure how far up things need to go, but my initial suggestions to marketing about changing that text on the landing page were met very positively. I’m OOO next week, so suspect it’ll be a while before you hear anything back, but this might get fixed next week. Thank you very much. We do appreciate it, since we really do try to provide decent community support here. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about Redisson 2023-01-12 Thread Doug Whitfield >Also, Chris's suggesiton to look at >org.apache.catalina.connector.RECYCLE_FACADES is a good first step. Note > that the value you need for that may not be what you expect. It needs to > be "true" whereas I read the name and think it should be "false" to > disable recycling. Thanks for coming back to this. This is actually exactly where I started, but I have not heard back, which is why I didn’t address it. BTW, can’t make any promises since not sure how far up things need to go, but my initial suggestions to marketing about changing that text on the landing page were met very positively. I’m OOO next week, so suspect it’ll be a while before you hear anything back, but this might get fixed next week. This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. Re: Question about Redisson 2023-01-10 Thread Mark Thomas Doug, There were a couple of questions in my original response it would be useful to get answers to. Also, Chris's suggesiton to look at org.apache.catalina.connector.RECYCLE_FACADES is a good first step. Note that the value you need for that may not be what you expect. It needs to be "true" whereas I read the name and think it should be "false" to disable recycling. Mark On 10/01/2023 19:09, Doug Whitfield wrote: First off, thanks for the link. I’m bringing this up with my manager who is much more likely to be able to make some headway with the marketing folks. There’s surely a marketing friendly way to say “Pay for SLA”. Are you able to reproduce the same problem with a non-Redisson-based segmented cluster, such as one using Tomcat's BackupManager? No. I told them this was going to be the answer. In fact, this was our answer, but customer really, really thinks it is a Tomcat issue. Maybe it is, but I haven’t personally seen the evidence. In any case, having the words in print rather than in prediction might help get us something more useful, like I think a heap dump might be. Thanks! This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about Redisson 2023-01-10 Thread Doug Whitfield First off, thanks for the link. I’m bringing this up with my manager who is much more likely to be able to make some headway with the marketing folks. There’s surely a marketing friendly way to say “Pay for SLA”. > Are you able to reproduce the same problem with a non-Redisson-based > segmented cluster, such as one using Tomcat's BackupManager? No. I told them this was going to be the answer. In fact, this was our answer, but customer really, really thinks it is a Tomcat issue. Maybe it is, but I haven’t personally seen the evidence. In any case, having the words in print rather than in prediction might help get us something more useful, like I think a heap dump might be. Thanks! This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. Re: Question about Redisson 2023-01-09 Thread Christopher Schultz Doug, On 1/9/23 15:48, Doug Whitfield wrote: Interesting. I’m not on the marketing team. What comments are you talking about? I can certainly try to get them removed. I think he's talking about this: "Don’t let your team waste another minute wading through outdated forums or online documentation to fix, secure, or maintain your mission-critical infrastructure. Get the technical support you need for the open source software you use — all in one place." [https://www.openlogic.com/] We don’t fork software which means when we find a bug we always work with upstream to get it fixed. The idea that we don’t work with the community when necessary is an insane for anything to put on our website (doesn’t mean I have any power to fix the copy though). Understood. I think Mark is mostly trying to make a point. He's obviously willing to engage on the actual question, as well, as you can see. One thing I wanted to make perfectly clear, which is something I was confused about when first encountering the term "recycling" when it comes to certain types of object (like request, response, etc.) in Tomcat. When the Tomcat documentation says these objects are "recycled" it really means that they are "re-used". That is, assuming a stable server where no weird errors occur and the number of connections is relatively constant, no new Request and Response objects will be created over time. Instead, they will have their various fields blanked-out for re-use with a subsequent request. This is a performance optimization to avoid GC churn, since request and response objects are usually short-lived. You can get an application to expose its misuse of request- or response-related objects by disabling this recycling in your configuration. The result is usually very obvious errors in the log file due to NPE or similar. The first step toward debugging IHMO would be to disable recycling and repeat your tests. I'm assuming given your STR that this is trivially reproducible? Are you able to reproduce the same problem with a non-Redisson-based segmented cluster, such as one using Tomcat's BackupManager? -chris From: Mark Thomas Date: Monday, January 9, 2023 at 12:12 To: users@tomcat.apache.org Subject: Re: Question about Redisson Given the disparaging comments OpenLogic makes about obtaining support for open source projects from a community forum, it is more than a tad ironic to see an OpenLogic Enterprise Architect asking for help here. I suggest that OpenLogic replace the text on their home page with something rather more honest that reflects that OpenLogic turns to the community forum when their Enterprise Architects need answers (which you'll find in-line below). On 09/01/2023 16:55, Doug Whitfield wrote: Hi Tomcat Community, We are seeing and issue that manifests as a cross session “bleeding” scenario. The issue is this: 1. User A make a new request and the request goes to pod A and gets Session1 2. User A's next request then gets redirected to pod B. The request is processed using Session1 3. User B now makes a new request and the request goes to pod B and instead of getting a new session, User B gets the same Session1 as User A We are using https://github.com/redisson/redisson for caching with Tomcat 9.0.58. Given the fixed bugs in the Tomcat changelog, I have suggested trying 9.0.66 or later. However, this suggestion has been met with resistance. Which bugs fixed between 9.0.58 and 9.0.66 do you believe are relevant to this issue? The only possibility I could see was "Improve the recycling of Processor objects to make it more robust" which is the fix for CVE-2021-43980. You will only hit that issue in specific circumstances that I do not wish to make public. If you can provide OS/Java version info and the Connector (and Executor if used) configuration from server.xml I can tell you if you are likely to be affected by that issue. For those unfamiliar with Redisson, I think the most important high-level piece from their docs is this: “Redisson's Tomcat Session Manager allows you to store sessions of Apache Tomcat in Redis. It empowers you to distribute requests across a cluster of Tomcat servers. This is all done in non-sticky session management backed by Redis.” I believe we could take a heap dump and get the answer, but at the moment that isn’t something we want to do. My question, at the moment, is pretty simple. How does this interact with Tomcat? Would the session management bugs in Tomcat apply? Almost certainly. There are lots of ways to trigger response mix-up. The primary cause is application bugs. This usually takes the form of the application retaining a reference to the request and/or response object beyond the end of processing for a single request/response. Tomcat recycles request and response objects so these objects can be being used for a new request while the application is still using them for the ol Re: Question about Redisson 2023-01-09 Thread Doug Whitfield Interesting. I’m not on the marketing team. What comments are you talking about? I can certainly try to get them removed. We don’t fork software which means when we find a bug we always work with upstream to get it fixed. The idea that we don’t work with the community when necessary is an insane for anything to put on our website (doesn’t mean I have any power to fix the copy though). Douglas Whitfield | Enterprise Architect, OpenLogic<https://www.openlogic.com/?utm_leadsource=email-signature_source=outlook-direct-email_medium=email_campaign=2019-common_content=email-signature-link> From: Mark Thomas Date: Monday, January 9, 2023 at 12:12 To: users@tomcat.apache.org Subject: Re: Question about Redisson Given the disparaging comments OpenLogic makes about obtaining support for open source projects from a community forum, it is more than a tad ironic to see an OpenLogic Enterprise Architect asking for help here. I suggest that OpenLogic replace the text on their home page with something rather more honest that reflects that OpenLogic turns to the community forum when their Enterprise Architects need answers (which you'll find in-line below). On 09/01/2023 16:55, Doug Whitfield wrote: > Hi Tomcat Community, > > We are seeing and issue that manifests as a cross session “bleeding” > scenario. The issue is this: > > 1. User A make a new request and the request goes to pod A and gets Session1 > 2. User A's next request then gets redirected to pod B. The request is > processed using Session1 > 3. User B now makes a new request and the request goes to pod B and instead > of getting a new session, User B gets the same Session1 as User A > > We are using https://github.com/redisson/redisson for caching with Tomcat > 9.0.58. Given the fixed bugs in the Tomcat changelog, I have suggested trying > 9.0.66 or later. However, this suggestion has been met with resistance. Which bugs fixed between 9.0.58 and 9.0.66 do you believe are relevant to this issue? The only possibility I could see was "Improve the recycling of Processor objects to make it more robust" which is the fix for CVE-2021-43980. You will only hit that issue in specific circumstances that I do not wish to make public. If you can provide OS/Java version info and the Connector (and Executor if used) configuration from server.xml I can tell you if you are likely to be affected by that issue. > For those unfamiliar with Redisson, I think the most important high-level > piece from their docs is this: > “Redisson's Tomcat Session Manager allows you to store sessions of Apache > Tomcat in Redis. It empowers you to distribute requests across a cluster of > Tomcat servers. This is all done in non-sticky session management backed by > Redis.” > > I believe we could take a heap dump and get the answer, but at the moment > that isn’t something we want to do. > > My question, at the moment, is pretty simple. How does this interact with > Tomcat? Would the session management bugs in Tomcat apply? Almost certainly. There are lots of ways to trigger response mix-up. The primary cause is application bugs. This usually takes the form of the application retaining a reference to the request and/or response object beyond the end of processing for a single request/response. Tomcat recycles request and response objects so these objects can be being used for a new request while the application is still using them for the old request. The next most frequent cause is Tomcat bugs. Generally, these take the form of the request/response objects not being recycled correctly and typically result in the same request and/or response object being used for multiple concurrent requests/responses. Any bug of this nature will be treated as a security issue so a CVE reference will be allocated and it will be listed on the security pages. Any session manager is going to susceptible to both types of bug described above. In theory, session mix-up could occur within a session manager but I don't recall ever seeing a bug like that either in the Tomcat provided managers or the various 3rd party managers like Redisson. HTH, Mark > > Best Regards, > > Douglas Whitfield | Enterprise Architect, > OpenLogic<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openlogic.com%2F%3Futm_leadsource%3Demail-signature%26utm_source%3Doutlook-direct-email%26utm_medium%3Demail%26utm_campaign%3D2019-common%26utm_content%3Demail-signature-link=05%7C01%7Cdwhitfield%40perforce.com%7Cd109a4f9f10441e5895c08daf26d103e%7C95b666d19a7549ab95a38969fbcdc08c%7C0%7C0%7C638088847521348881%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=KrMLo05t741I8SJsL24Fgu7gAR%2BUBfNVhbEVikiqZRU%3D=0> > Perforce > Software<http://www.perforce.com/?utm_leadsource=email-signature_source=outlook-direct-email_me Re: Question about Redisson 2023-01-09 Thread Mark Thomas Given the disparaging comments OpenLogic makes about obtaining support for open source projects from a community forum, it is more than a tad ironic to see an OpenLogic Enterprise Architect asking for help here. I suggest that OpenLogic replace the text on their home page with something rather more honest that reflects that OpenLogic turns to the community forum when their Enterprise Architects need answers (which you'll find in-line below). On 09/01/2023 16:55, Doug Whitfield wrote: Hi Tomcat Community, We are seeing and issue that manifests as a cross session “bleeding” scenario. The issue is this: 1. User A make a new request and the request goes to pod A and gets Session1 2. User A's next request then gets redirected to pod B. The request is processed using Session1 3. User B now makes a new request and the request goes to pod B and instead of getting a new session, User B gets the same Session1 as User A We are using https://github.com/redisson/redisson for caching with Tomcat 9.0.58. Given the fixed bugs in the Tomcat changelog, I have suggested trying 9.0.66 or later. However, this suggestion has been met with resistance. Which bugs fixed between 9.0.58 and 9.0.66 do you believe are relevant to this issue? The only possibility I could see was "Improve the recycling of Processor objects to make it more robust" which is the fix for CVE-2021-43980. You will only hit that issue in specific circumstances that I do not wish to make public. If you can provide OS/Java version info and the Connector (and Executor if used) configuration from server.xml I can tell you if you are likely to be affected by that issue. For those unfamiliar with Redisson, I think the most important high-level piece from their docs is this: “Redisson's Tomcat Session Manager allows you to store sessions of Apache Tomcat in Redis. It empowers you to distribute requests across a cluster of Tomcat servers. This is all done in non-sticky session management backed by Redis.” I believe we could take a heap dump and get the answer, but at the moment that isn’t something we want to do. My question, at the moment, is pretty simple. How does this interact with Tomcat? Would the session management bugs in Tomcat apply? Almost certainly. There are lots of ways to trigger response mix-up. The primary cause is application bugs. This usually takes the form of the application retaining a reference to the request and/or response object beyond the end of processing for a single request/response. Tomcat recycles request and response objects so these objects can be being used for a new request while the application is still using them for the old request. The next most frequent cause is Tomcat bugs. Generally, these take the form of the request/response objects not being recycled correctly and typically result in the same request and/or response object being used for multiple concurrent requests/responses. Any bug of this nature will be treated as a security issue so a CVE reference will be allocated and it will be listed on the security pages. Any session manager is going to susceptible to both types of bug described above. In theory, session mix-up could occur within a session manager but I don't recall ever seeing a bug like that either in the Tomcat provided managers or the various 3rd party managers like Redisson. HTH, Mark Best Regards, Douglas Whitfield | Enterprise Architect, OpenLogic Perforce Software P: +1 612.517.2100 Visit us on: LinkedIn | Twitter | Facebook | YouTube The Star Tribune recognizes Perforce as a Top Workplace in Minnesota. Read more > This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional Re: Question about upgrade from Tomcat 7 to Tomcat 9.0.67 2022-10-05 Thread Jason Wee i would normally do a diff between your current version and the next tomcat version you want to upgrade to and go through the diff slowly. it is better to be careful and note the changes than sorry later. On Wed, Oct 5, 2022 at 9:17 PM Mark Thomas wrote: > > > > On 05/10/2022 09:17, Terry ST SY/OGCIO wrote: > > Hi , > > > > we would like to upgrade Tomcat 7 to Tomcat 9.0.67. > > > > Check on the major changes on Tomcat 7 to Tomcat 9. (One of the major > > change we initially spotted is the BIO connector used in Tomcat 7 for > > connector setup was removed in Tomcat 9: > > https://tomcat.apache.org/migration-9.html#BIO_connector_removed) > > > > For your reference, Http11Protocol was used in Tomcat 7, but since Tomcat 9 > > removed it, we tried to Http11NioProtocol with same parameters in the > > tomcat config in “conf/server.xml. Is it a proper method for migrate the > > BIO connector ( Tomcat 7 ) to NIO connector ( Tomcat 9 ) ? > > Generally, I'd recommend the following: > > 1. Review the server.xml you use for Tomcat 7 and note each deviation > from the defaults > 2. Start with the default server.xml for 9.0.x and for each of the > additional/changed settings noted in step 1, determine if you still > need to apply it in Tomcat 9. > > The HttpNioProtocol is the default in 9.0.x. Generally, the settings > will translate from 7.0.x but you should still review them to ensure > they remain appropriate for your environment. > > 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: Question about upgrade from Tomcat 7 to Tomcat 9.0.67 2022-10-05 Thread Mark Thomas On 05/10/2022 09:17, Terry ST SY/OGCIO wrote: Hi , we would like to upgrade Tomcat 7 to Tomcat 9.0.67. Check on the major changes on Tomcat 7 to Tomcat 9. (One of the major change we initially spotted is the BIO connector used in Tomcat 7 for connector setup was removed in Tomcat 9: https://tomcat.apache.org/migration-9.html#BIO_connector_removed) For your reference, Http11Protocol was used in Tomcat 7, but since Tomcat 9 removed it, we tried to Http11NioProtocol with same parameters in the tomcat config in “conf/server.xml. Is it a proper method for migrate the BIO connector ( Tomcat 7 ) to NIO connector ( Tomcat 9 ) ? Generally, I'd recommend the following: 1. Review the server.xml you use for Tomcat 7 and note each deviation from the defaults 2. Start with the default server.xml for 9.0.x and for each of the additional/changed settings noted in step 1, determine if you still need to apply it in Tomcat 9. The HttpNioProtocol is the default in 9.0.x. Generally, the settings will translate from 7.0.x but you should still review them to ensure they remain appropriate for your environment. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about upgrade from Tomcat 7 to Tomcat 9.0.67 2022-10-05 Thread Suvendu Sekhar Mondal Hello Terry, On Wed, Oct 5, 2022, 1:47 PM Terry ST SY/OGCIO wrote: > Hi , > > we would like to upgrade Tomcat 7 to Tomcat 9.0.67. > > Check on the major changes on Tomcat 7 to Tomcat 9. (One of the major > change we initially spotted is the BIO connector used in Tomcat 7 for > connector setup was removed in Tomcat 9: > https://tomcat.apache.org/migration-9.html#BIO_connector_removed) > > For your reference, Http11Protocol was used in Tomcat 7, but since Tomcat > 9 removed it, we tried to Http11NioProtocol with same parameters in the > tomcat config in “conf/server.xml. Is it a proper method for migrate the > BIO connector ( Tomcat 7 ) to NIO connector ( Tomcat 9 ) ? > That is the way to switch to NIO connector. You need to change the value of protocol attribute of the connector tag like below: protocol="org.apache.coyote.http11.Http11NioProtocol" After that if you restart Tomcat, in startup log you'll see that NIO is initialized. Also in thread dump thread name changes and becomes something like "http-nio-*". > Regards, > Terry > > > Re: Question about windows servers support platform for Tomcat 7 and Tomcat 9 2022-09-21 Thread Mark Thomas On 21/09/2022 09:16, Terry ST SY/OGCIO wrote: Dear Mark, Many thanks for your reply. As there is some limitation/dependence on upgrade Tomcat 7, may I know Tomcat 7 the windows platform support status before Tomcat 7 end of support. Tomcat 7 was supported on any Windows platform supported by Microsoft. Mark Regards, Terry -Original Message- From: Mark Thomas Sent: Wednesday, September 21, 2022 4:10 PM To: users@tomcat.apache.org Subject: Re: Question about windows servers support platform for Tomcat 7 and Tomcat 9 On 21/09/2022 08:03, Terry ST SY/OGCIO wrote: Dear Support, We are using Tomcat 7 with Windows Server 2012 R2 at our servers and planned to upgrade tomcat and windows platform. Can you update us the windows support platform for Tomcat 7 and Tomcat 9 for our ease planning. Apache Tomcat 7 reached end of life 18 months ago and is no longer supported: https://tomcat.apache.org/tomcat-70-eol.html Apache Tomcat 9.0.x is currently supported and, based on support periods for previous versions, I'd expect that support to last for a further 4-5 years. The end of life date, when decided, will be announced with at least 12 months notice. Apache Tomcat 9 is a special case since it is the last version that implements Java EE (Tomcat 10 onwards implement Jakarta EE). The Tomcat community expects to provide support for Tomcat 9 for as long as there is a demand for a version of Tomcat that supports Java EE. The exact detail of how extended Tomcat 9 support will work is TBD but it will be something like once Tomcat 9.0.x reaches end of life, Tomcat 9.10.x will be released which will be Tomcat 10 but with Java EE support. Once Tomcat 10 reaches end of life, so will 9.10.x and 9.11.x will be released which will be Tomcat 11 but with Java EE support and so on. Apache Tomcat is supported on any Windows platform currently supported by Microsoft. 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: Question about windows servers support platform for Tomcat 7 and Tomcat 9 2022-09-21 Thread Terry ST SY/OGCIO Dear Mark, Many thanks for your reply. As there is some limitation/dependence on upgrade Tomcat 7, may I know Tomcat 7 the windows platform support status before Tomcat 7 end of support. Regards, Terry -Original Message- From: Mark Thomas Sent: Wednesday, September 21, 2022 4:10 PM To: users@tomcat.apache.org Subject: Re: Question about windows servers support platform for Tomcat 7 and Tomcat 9 On 21/09/2022 08:03, Terry ST SY/OGCIO wrote: > Dear Support, > > We are using Tomcat 7 with Windows Server 2012 R2 at our servers and planned > to upgrade tomcat and windows platform. > > Can you update us the windows support platform for Tomcat 7 and Tomcat 9 for > our ease planning. Apache Tomcat 7 reached end of life 18 months ago and is no longer supported: https://tomcat.apache.org/tomcat-70-eol.html Apache Tomcat 9.0.x is currently supported and, based on support periods for previous versions, I'd expect that support to last for a further 4-5 years. The end of life date, when decided, will be announced with at least 12 months notice. Apache Tomcat 9 is a special case since it is the last version that implements Java EE (Tomcat 10 onwards implement Jakarta EE). The Tomcat community expects to provide support for Tomcat 9 for as long as there is a demand for a version of Tomcat that supports Java EE. The exact detail of how extended Tomcat 9 support will work is TBD but it will be something like once Tomcat 9.0.x reaches end of life, Tomcat 9.10.x will be released which will be Tomcat 10 but with Java EE support. Once Tomcat 10 reaches end of life, so will 9.10.x and 9.11.x will be released which will be Tomcat 11 but with Java EE support and so on. Apache Tomcat is supported on any Windows platform currently supported by Microsoft. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about windows servers support platform for Tomcat 7 and Tomcat 9 2022-09-21 Thread Mark Thomas On 21/09/2022 08:03, Terry ST SY/OGCIO wrote: Dear Support, We are using Tomcat 7 with Windows Server 2012 R2 at our servers and planned to upgrade tomcat and windows platform. Can you update us the windows support platform for Tomcat 7 and Tomcat 9 for our ease planning. Apache Tomcat 7 reached end of life 18 months ago and is no longer supported: https://tomcat.apache.org/tomcat-70-eol.html Apache Tomcat 9.0.x is currently supported and, based on support periods for previous versions, I'd expect that support to last for a further 4-5 years. The end of life date, when decided, will be announced with at least 12 months notice. Apache Tomcat 9 is a special case since it is the last version that implements Java EE (Tomcat 10 onwards implement Jakarta EE). The Tomcat community expects to provide support for Tomcat 9 for as long as there is a demand for a version of Tomcat that supports Java EE. The exact detail of how extended Tomcat 9 support will work is TBD but it will be something like once Tomcat 9.0.x reaches end of life, Tomcat 9.10.x will be released which will be Tomcat 10 but with Java EE support. Once Tomcat 10 reaches end of life, so will 9.10.x and 9.11.x will be released which will be Tomcat 11 but with Java EE support and so on. Apache Tomcat is supported on any Windows platform currently supported by Microsoft. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question ad 2021 presentation videos 2022-06-28 Thread Rony G. Flatscher (Apache) Hi Chris, On 28.06.2022 15:31, Christopher Schultz wrote: On 6/28/22 05:44, Rony G. Flatscher (Apache) wrote: Is there a link for the 2021 Tomcat presentation videos, if any? Oh, I'm sorry. I was working on getting those onto the Presentations page and I got distracted and didn't finish. I'll try to get back to that, today. Thank you! ---rony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question ad 2021 presentation videos 2022-06-28 Thread Rony G. Flatscher (Apache) Hi Coty, On 28.06.2022 15:07, Coty Sutherland wrote: On Tue, Jun 28, 2022 at 5:44 AM Rony G. Flatscher (Apache) wrote: Is there a link for the 2021 Tomcat presentation videos, if any? Is the playlist at https://www.youtube.com/playlist?list=PLU2OcwpQkYCyq45LTYr07svnrCGarSWs7 what you're looking for? thank you very much that helps already a lot! I have been asked a couple of times about the presentation "Apache Tomcat: Enabling Scripting Languages in JSPs" as it demonstrates how to use Groovy, JavaScript, Jython, ooRexx and PHP in JSPs (and for that matter any Java scripting language, i.e. any scripting language that implements javax.script.ScriptEngine). Your link allows one to pick that presentation right away! Thank you very much! ---rony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question ad 2021 presentation videos 2022-06-28 Thread Christopher Schultz Rony, On 6/28/22 05:44, Rony G. Flatscher (Apache) wrote: Is there a link for the 2021 Tomcat presentation videos, if any? Oh, I'm sorry. I was working on getting those onto the Presentations page and I got distracted and didn't finish. I'll try to get back to that, today. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question ad 2021 presentation videos 2022-06-28 Thread Coty Sutherland On Tue, Jun 28, 2022 at 5:44 AM Rony G. Flatscher (Apache) wrote: > Is there a link for the 2021 Tomcat presentation videos, if any? > Is the playlist at https://www.youtube.com/playlist?list=PLU2OcwpQkYCyq45LTYr07svnrCGarSWs7 what you're looking for? > ---rony > > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > RE: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] 2022-06-03 Thread jonmcalexander Thank you as always Mark and all! Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: Mark Thomas > Sent: Friday, June 3, 2022 4:19 AM > To: users@tomcat.apache.org > Subject: Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over > SSL [EXTERNAL] > > Jon, > > If you want to secure the httpd <-> Tomcat link with mutually authenticated > TLS then I believe it is possible based on reading the docs but a) haven't > tested it and b) you are going to need to be careful to ensure Tomcat doesn't > get confused about whether it is the actual client or the reverse proxy that > is > authenticated. > > The following are some pointers that should help. This is how I would go > about things if I was doing this. > > 1. Set up mod_proxy_http and get it working over http. > > 2. Create and configure a server certificate for Tomcat. > > 3. Switch to proxy over https. > > 4. Use SSLProxyCACertifcate[File|Path] to configure httpd to authenticate > Tomcat. > > 5. Check you got 4 right by changing the Tomcat cert to a self-signed one and > looking for the proxy connection to fail. > > 6. Create a client cert for httpd. > > 7. Configure Tomcat to require client cert authentication. > > 8. Configure httpd using SSLProxyMachineCertificate[File|Path] to provide > the certificate. > > 9. Check you got 8 right by: > a) using a JSP to view the presented certificate > b) changing httpd to use a self-signed cert and check it fails > > > The problem you have now is that Tomcat sees httpd as a TLS authenticated > client and you really want Tomcat to see the authentication status of the real > client. > > I've looked at the SSLValve and it only sets request attributes if the > relevant > headers from httpd are present. You would need to write an additional Valve > that ran earlier in the pipeline and cleared those headers. > > HTH, > > Mark > > > On 03/06/2022 00:13, jonmcalexan...@wellsfargo.com.INVALID wrote: > > Ok, so in short ots not possible to mutually authenticate the > > mod-proxy and a tomcat connector, correct? > > > > I'm needing to convert an ajp configuration to mod-proxy, but a security > architect wants the other as well. > > > > > > Thanks, > > > > > > Sent with BlackBerry Work > > > (https://urldefense.com/v3/__http://www.blackberry.com__;!!F9svGWnIa > VP > > GSwU!oOENK5nJ9Bjo27NDwzO08hd73vpTk3jdwxUjQI6v10Xcd3-p- > MGYhMB5ZZjpooe5o > > iwCi-AthWdFVKAJcCg8cQ$ ) > > From: Christopher Schultz > > Sent: Jun 2, 2022 5:05 PM > > To: users@tomcat.apache.org > > Subject: Re: Question regarding Tomcat and Apache HTTPD Mod-proxy > over > > SSL [EXTERNAL] > > > > On 6/2/22 14:38, Beard, Shawn wrote: > > > I've never done this. But I think it would go something like this: > > > To make tomcat take advantages of Client Authentication, require three > > > certificates. i.e A Server Certificate for Tomcat, Client Certificate > > > for the browser/Apache and Certificate of the CA which will sign both > > > the above mentioned certificates. > > > > Stop. John: if you aren't using client TLS certs with your end-users, > > then this is a rathole you don't want to go down. > > > > If you *do* need to use client-TLS-auth, then this is correct. > > > > -chris > > > > - > > 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: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] 2022-06-03 Thread Mark Thomas Jon, If you want to secure the httpd <-> Tomcat link with mutually authenticated TLS then I believe it is possible based on reading the docs but a) haven't tested it and b) you are going to need to be careful to ensure Tomcat doesn't get confused about whether it is the actual client or the reverse proxy that is authenticated. The following are some pointers that should help. This is how I would go about things if I was doing this. 1. Set up mod_proxy_http and get it working over http. 2. Create and configure a server certificate for Tomcat. 3. Switch to proxy over https. 4. Use SSLProxyCACertifcate[File|Path] to configure httpd to authenticate Tomcat. 5. Check you got 4 right by changing the Tomcat cert to a self-signed one and looking for the proxy connection to fail. 6. Create a client cert for httpd. 7. Configure Tomcat to require client cert authentication. 8. Configure httpd using SSLProxyMachineCertificate[File|Path] to provide the certificate. 9. Check you got 8 right by: a) using a JSP to view the presented certificate b) changing httpd to use a self-signed cert and check it fails The problem you have now is that Tomcat sees httpd as a TLS authenticated client and you really want Tomcat to see the authentication status of the real client. I've looked at the SSLValve and it only sets request attributes if the relevant headers from httpd are present. You would need to write an additional Valve that ran earlier in the pipeline and cleared those headers. HTH, Mark On 03/06/2022 00:13, jonmcalexan...@wellsfargo.com.INVALID wrote: Ok, so in short ots not possible to mutually authenticate the mod-proxy and a tomcat connector, correct? I'm needing to convert an ajp configuration to mod-proxy, but a security architect wants the other as well. Thanks, Sent with BlackBerry Work (www.blackberry.com) From: Christopher Schultz Sent: Jun 2, 2022 5:05 PM To: users@tomcat.apache.org Subject: Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] On 6/2/22 14:38, Beard, Shawn wrote: > I've never done this. But I think it would go something like this: > To make tomcat take advantages of Client Authentication, require three > certificates. i.e A Server Certificate for Tomcat, Client Certificate > for the browser/Apache and Certificate of the CA which will sign both > the above mentioned certificates. Stop. John: if you aren't using client TLS certs with your end-users, then this is a rathole you don't want to go down. If you *do* need to use client-TLS-auth, then this is correct. -chris - 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: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] 2022-06-02 Thread jonmcalexander Ok, so in short ots not possible to mutually authenticate the mod-proxy and a tomcat connector, correct? I'm needing to convert an ajp configuration to mod-proxy, but a security architect wants the other as well. Thanks, Sent with BlackBerry Work (www.blackberry.com) From: Christopher Schultz Sent: Jun 2, 2022 5:05 PM To: users@tomcat.apache.org Subject: Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] On 6/2/22 14:38, Beard, Shawn wrote: > I've never done this. But I think it would go something like this: > To make tomcat take advantages of Client Authentication, require three > certificates. i.e A Server Certificate for Tomcat, Client Certificate > for the browser/Apache and Certificate of the CA which will sign both > the above mentioned certificates. Stop. John: if you aren't using client TLS certs with your end-users, then this is a rathole you don't want to go down. If you *do* need to use client-TLS-auth, then this is correct. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] 2022-06-02 Thread Christopher Schultz On 6/2/22 14:38, Beard, Shawn wrote: > I've never done this. But I think it would go something like this: > To make tomcat take advantages of Client Authentication, require three > certificates. i.e A Server Certificate for Tomcat, Client Certificate > for the browser/Apache and Certificate of the CA which will sign both > the above mentioned certificates. Stop. John: if you aren't using client TLS certs with your end-users, then this is a rathole you don't want to go down. If you *do* need to use client-TLS-auth, then this is correct. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL 2022-06-02 Thread Christopher Schultz Jon, On 6/2/22 14:20, jonmcalexan...@wellsfargo.com.INVALID wrote: I'm trying to figure out if there is a way to use certificates between Tomcat and Apache for mutual authentication of the mod-proxy connection to Tomcat. This would be similar as to how you can setup the WebSphere plugin to communicate with WebSphere over a mutually secured connection. Is this possible with Apache HTTPD and Tomcat over mod-proxy? Definitely. What do you have working so far? Just httpd mod_proxy -> Tomcat where you only authenticate the Tomcat server -- and you now want to have Tomcat authenticate the client as well? I just want to know where to pick-up in your process. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org RE: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] 2022-06-02 Thread jonmcalexander That was my thought also, but wouldn’t that then require the end-users to also have certificates? Or would it just be Apache HTTPD? Basically the end users connection terminates at the proxy, and the proxy uses its own connection to pass it thru. Is that right? Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com> This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From: Beard, Shawn Sent: Thursday, June 2, 2022 1:39 PM To: Tomcat Users List Subject: RE: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] I've never done this. But I think it would go something like this: To make tomcat take advantages of Client Authentication, require three certificates. i.e A Server Certificate for Tomcat, Client Certificate for the browser/Apache and Certificate of the CA which will sign both the above mentioned certificates. Then you might need to import these into each others trust/keystore Tomcat connector config would need to have something like this, note the cleintAuth="true" Shawn Beard • Sr. Systems Engineer Middleware Engineering [cid:image673978.png@4BD479EE.2F6A6ED7] 3840 109th Street , Urbandale , IA 50322 Phone: +1-515-564-2528 Email: sbe...@wrberkley.com<mailto:sbe...@wrberkley.com> Website: https://berkleytechnologyservices.com/ [cid:image749241.jpg@C8087C5D.3210F22C] Technology Leadership Unleashing Business Potential -Original Message- From: jonmcalexan...@wellsfargo.com.INVALID<mailto:jonmcalexan...@wellsfargo.com.INVALID> mailto:jonmcalexan...@wellsfargo.com.INVALID>> Sent: Thursday, June 2, 2022 1:21 PM To: users@tomcat.apache.org<mailto:users@tomcat.apache.org> Subject: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] ** CAUTION: External message I'm trying to figure out if there is a way to use certificates between Tomcat and Apache for mutual authentication of the mod-proxy connection to Tomcat. This would be similar as to how you can setup the WebSphere plugin to communicate with WebSphere over a mutually secured connection. Is this possible with Apache HTTPD and Tomcat over mod-proxy? Thanks, Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com%3cmailto:jonmcalexan...@wellsfargo.com>> This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain private, privileged and confidential information belonging to the sender. The information therein is solely for the use of the addressee. If your receipt of this transmission has occurred as the result of an error, please immediately notify us so we can arrange for the return of the documents. In such circumstances, you are advised that you may not disclose, copy, distribute or take any other action in reliance on the information transmitted. RE: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] 2022-06-02 Thread Beard, Shawn I've never done this. But I think it would go something like this: To make tomcat take advantages of Client Authentication, require three certificates. i.e A Server Certificate for Tomcat, Client Certificate for the browser/Apache and Certificate of the CA which will sign both the above mentioned certificates. Then you might need to import these into each others trust/keystore Tomcat connector config would need to have something like this, note the cleintAuth="true" Shawn Beard• Sr. Systems Engineer Middleware Engineering [cid:image673978.png@4BD479EE.2F6A6ED7] 3840 109th Street , Urbandale , IA 50322 Phone: +1-515-564-2528 Email: sbe...@wrberkley.com Website: https://berkleytechnologyservices.com/ [cid:image749241.jpg@C8087C5D.3210F22C] Technology Leadership Unleashing Business Potential -Original Message- From: jonmcalexan...@wellsfargo.com.INVALID Sent: Thursday, June 2, 2022 1:21 PM To: users@tomcat.apache.org Subject: Question regarding Tomcat and Apache HTTPD Mod-proxy over SSL [EXTERNAL] ** CAUTION: External message I'm trying to figure out if there is a way to use certificates between Tomcat and Apache for mutual authentication of the mod-proxy connection to Tomcat. This would be similar as to how you can setup the WebSphere plugin to communicate with WebSphere over a mutually secured connection. Is this possible with Apache HTTPD and Tomcat over mod-proxy? Thanks, Dream * Excel * Explore * Inspire Jon McAlexander Senior Infrastructure Engineer Asst. Vice President He/His Middleware Product Engineering Enterprise CIO | EAS | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain private, privileged and confidential information belonging to the sender. The information therein is solely for the use of the addressee. If your receipt of this transmission has occurred as the result of an error, please immediately notify us so we can arrange for the return of the documents. In such circumstances, you are advised that you may not disclose, copy, distribute or take any other action in reliance on the information transmitted. Re: Question about ssl 2022-03-31 Thread Christopher Schultz John, On 3/31/22 10:50, John Dale (DB2DOM) wrote: Hi Chris; I'm measuring the time taken to process a request as reported by inspector-network in brave. SSL time to process through tomcat is 11ms. Same request for a smaller file using a java SSL socket is taking 50ms .. like this: public static SSLServerSocket getServerSocketWithCert(int port, InputStream pathToCert, String passwordFromCert, ServerSecureType type) throws IOException, KeyManagementException, NoSuchAlgorithmException, CertificateException, KeyStoreException, UnrecoverableKeyException { X509TrustManager[] tmm; X509KeyManager[] kmm; KeyStore ks = KeyStore.getInstance(instance); ks.load(pathToCert, passwordFromCert.toCharArray()); tmm=tm(ks); kmm=km(ks, passwordFromCert); SSLContext ctx = SSLContext.getInstance(type.getType()); ctx.init(kmm, tmm, null); SSLServerSocketFactory socketFactory = (SSLServerSocketFactory) ctx.getServerSocketFactory(); SSLServerSocket ssocket = (SSLServerSocket) socketFactory.createServerSocket(port); return ssocket; } I'm using the cert at https://db2dom.com It's still a tenth of a second to process the request with this "hand rolled" method, but it's several orders of magnitude slower, and I'm trying to figure out why (I'm obsessive with response times). So you have a hand-rolled TLS server (selected code above) and you are comparing it to Tomcat? It all depends upon what you are doing with that code above. Tomcat is doing something like the above basically once and then re-using the same Socket for a long time. Are you re-initializing your Socket for each request perhaps? Are you using exactly the same trust store and key store between your hand-rolled code and Tomcat? The client is negotiating the exaxt same cipher suite, etc.? How many requests are you running your code through -- like after JVM startup? Just one? Many? How many? Same questions for Tomcat. It's always hard to set up a fair comparison, and you aren't giving us very much information. -chris On 3/28/22, Christopher Schultz wrote: John, On 3/26/22 22:29, John Dale (DB2DOM) wrote: Can you help me understand why Tomcat's SSL handling is so much faster than hand rolling it on a regular socket? I think you'll need to define some terms. For example, what do you mean when you say "faster", and how are you measuring that? What do you mean when you say "hand-rolling" your SSL and what is a "regular socket"? -chris - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about ssl 2022-03-31 Thread John Dale (DB2DOM) Hi Chris; I'm measuring the time taken to process a request as reported by inspector-network in brave. SSL time to process through tomcat is 11ms. Same request for a smaller file using a java SSL socket is taking 50ms .. like this: public static SSLServerSocket getServerSocketWithCert(int port, InputStream pathToCert, String passwordFromCert, ServerSecureType type) throws IOException, KeyManagementException, NoSuchAlgorithmException, CertificateException, KeyStoreException, UnrecoverableKeyException { X509TrustManager[] tmm; X509KeyManager[] kmm; KeyStore ks = KeyStore.getInstance(instance); ks.load(pathToCert, passwordFromCert.toCharArray()); tmm=tm(ks); kmm=km(ks, passwordFromCert); SSLContext ctx = SSLContext.getInstance(type.getType()); ctx.init(kmm, tmm, null); SSLServerSocketFactory socketFactory = (SSLServerSocketFactory) ctx.getServerSocketFactory(); SSLServerSocket ssocket = (SSLServerSocket) socketFactory.createServerSocket(port); return ssocket; } I'm using the cert at https://db2dom.com It's still a tenth of a second to process the request with this "hand rolled" method, but it's several orders of magnitude slower, and I'm trying to figure out why (I'm obsessive with response times). Sincerely, John On 3/28/22, Christopher Schultz wrote: > John, > > On 3/26/22 22:29, John Dale (DB2DOM) wrote: >> Can you help me understand why Tomcat's SSL handling is so much faster >> than hand rolling it on a regular socket? > > I think you'll need to define some terms. > > For example, what do you mean when you say "faster", and how are you > measuring that? > > What do you mean when you say "hand-rolling" your SSL and what is a > "regular socket"? > > -chris > > - > 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: Question about ssl 2022-03-28 Thread Christopher Schultz John, On 3/26/22 22:29, John Dale (DB2DOM) wrote: Can you help me understand why Tomcat's SSL handling is so much faster than hand rolling it on a regular socket? I think you'll need to define some terms. For example, what do you mean when you say "faster", and how are you measuring that? What do you mean when you say "hand-rolling" your SSL and what is a "regular socket"? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question to possible memory leak by Threadlocal variable 2022-03-24 Thread Mark Thomas On 24/03/2022 07:57, Thomas Hoffmann (Speed4Trade GmbH) wrote: Is it correct, that every spawned thread must call tl.remove() to cleanup all the references to prevent the logged warning (and not only the main thread)? Yes. Or the threads need to exit. Second question is: How might it cause a memory leak? The threads are terminated and hold a reference to this static variable. But on the other side, that class A is also eligible for garbage collection after undeployment. So both, the thread class and the class A are ready to get garbage collected. Maybe I missed something (?) It sounds as if the clean-up is happening too late. Tomcat expects clean-up to be completed once contextDestroyed() has returned for all ServLetContextListeners. If the clean-up is happening asynchronously (e.g. the call is made to stop the threads but doesn't wait until the threads have stopped) you could see this message. In this case it sounds as if you aren't going to get a memory leak but Tomcat can't tell that at the point it checks. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about Tomcat 8.5.77 and CVE-2022-0778 2022-03-21 Thread Mark Thomas On 21/03/2022 16:26, Matthew Mellon wrote: Tomcat 8.5.77 was published on March 17. The Windows distribution contains tcnative-1.dll, version 1.2.31. Tcnative-1.dll appears to be statically linked to OpenSSL, and was built in 2021, prior to the fix for CVE-2022-0778 being published by OpenSSL. The tcnative source tree was updated to “recommend” a new version of OpenSSL six days ago, but the DLL in the 8.5.77 release doesn’t appear to have been built with this change. I believe this means that if an APR connector is enabled, that the Windows distribution of Tomcat 8.5.77 is exposed to a pretty severe DOS attack vector. I emailed secur...@tomcat.apache.org about this, believing that that was the responsible way to bring this to light, but received a pretty nasty email in response that told me that this mailing list was the correct forum. CVE-2022-0778 is public. You posted a question to the Apache Tomcat security team that did not concern an undisclosed security vulnerability in Apache Tomcat. This happens sufficiently often that we have a canned response for when this happens. For the record this is the content of that canned response: To whom it may concern, You recently contacted the Apache Tomcat security team. As explained in [1], the e-mail address you used should only be used for reporting undisclosed security vulnerabilities in Apache Tomcat and managing the process of fixing such vulnerabilities. Your e-mail does not meet that criteria. You may wish read some information on how the ASF works [2] before proceeding with your enquiry via the appropriate channel which will almost certainly be the Apache Tomcat users mailing list. [3] The Apache Tomcat security team [1] http://tomcat.apache.org/security.html [2] http://apache.org/foundation/how-it-works.html [3] https://tomcat.apache.org/lists.html#tomcat-users Would it be possible to get a canonical version of Tomcat (e.g. 8.5.78) built that contains the remediation for CVE-2022-0778? There is a Tomcat Native 1.2.32 release in progress at the moment that includes convenience Windows binaries built with OpenSSL 1.1.1n. That release vote looks like it is going to pass so that release should be available on the download pages sometime tomorrow. Tomcat releases are usually monthly with the process starting at the beginning of the month. I'd therefore expect to see an 8.5.78 release roughly around the second week of April that included the Tomcat Native 1.2.32 release. Is there anything I can do to help? Test the Tomcat Native 1.2.32 release. Details on the dev@ list. The changes since 1.2.31 are minor and don't include any code changes so the likelihood of a regression is low. However, the more people that test a release and VOTE on it the better. Test the 8.5.78 release when it happens. Watch the dev@ list for details. Some other options: Disable the APR/Native library so Tomcat uses NIO+JSSE instead. Update to Tomcat Native 1.2.32 once released (single DLL for Windows that is a drop-in replacement). Build 1.2.31 from source using OpenSSL 1.1.1n. The build process we use is documented at [1]. The hoop jumping is mainly to ensure that the resulting binaries will run on all currently supported Windows versions without requiring that additional run times etc are installed. Given that 1.2.32 is so close to release, it may not be worth the time required to follow this option. Mark [1] https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows *Matthew Mellon **CISSP** */Chief Information Security Officer/ 828.265.2907 ext 5058 | www.ecrs.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about serving a 404 2021-09-10 Thread Mark Thomas On 10/09/2021 16:44, James H. H. Lampert wrote: Our Tomcat team has been struggling with this issue for a few days: If a request comes in for https://foo.com/bar.html, which doesn't exist, then a 404 is returned, and we see a standard Tomcat 404 page. But if a request comes in for https://foo.com/bar.jsp, which also doesn't exist, then our webapp takes control, and returns a 200 with a redirect to a "you are not signed on" page. In the most recent attempt to correct this, they now return a 404 page of their own design for both of the above scenarios. Unfortunately, if the webapp context we're trying to reach is installed as something other than ROOT (i.e., if we call it "baz," then https://foo.com/baz), then even a correct URL still returns a 404 page. Seems to me that there's something wrong with this picture. Seems to me that a request for a nonexistent "bar.jsp" should behave the same as one for a nonexistent "bar.html." Is there something I can pass along to the Tomcat team? Sounds like whatever is responding *.jsp requests is a little over eager. Depending on exactly what that is (Tomcat's JSP Servlet, custom Servlet, Filter) there are different things that might be able to help. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question for verification 2021-08-06 Thread Mark Thomas On August 6, 2021 2:24:13 PM UTC, jonmcalexan...@wellsfargo.com.INVALID wrote: >Verifying an assumption. > >All modern versions of Tomcat (8.5 and above) are compatible with Java >11. Yes. We regularly test Tomcat with the early access versions of each Java release. We also have CI systems that test 8, 11 and latest. Mark > >Thanks in advance > >Dream * Excel * Explore * Inspire >Jon McAlexander >Infrastructure Engineer >Asst Vice President > >Middleware Product Engineering >Enterprise CIO | Platform Services | Middleware | Infrastructure >Solutions > >8080 Cobblestone Rd | Urbandale, IA 50322 >MAC: F4469-010 >Tel 515-988-2508 | Cell 515-988-2508 > >jonmcalexan...@wellsfargo.com > >Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, >11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, >12/29/2020, 12/30/2020, 12/31/2020 >This message may contain confidential and/or privileged information. If >you are not the addressee or authorized to receive this for the >addressee, you must not use, copy, disclose, or take any action based >on this message or any information herein. If you have received this >message in error, please advise the sender immediately by reply e-mail >and delete this message. Thank you for your cooperation. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org RE: Question for verification 2021-08-06 Thread jonmcalexander Doh Thanks! Dream * Excel * Explore * Inspire Jon McAlexander Infrastructure Engineer Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 12/30/2020, 12/31/2020 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: calder > Sent: Friday, August 6, 2021 9:45 AM > To: Tomcat Users List > Subject: Re: Question for verification > > On Fri, Aug 6, 2021, 09:31 wrote: > > > Verifying an assumption. > > > > All modern versions of Tomcat (8.5 and above) are compatible with Java 11. > > > > GIYF > > https://urldefense.com/v3/__https://tomcat.apache.org/whichversion.html > __;!!F9svGWnIaVPGSwU!5OACMZ6S7VZsWNYMAuLJ- > v0iUP2_CFdYOeHUf01bhLejkLIIgrlwgUt2wyjXaqPnsNkjYP8$ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question for verification 2021-08-06 Thread calder On Fri, Aug 6, 2021, 09:31 wrote: > Verifying an assumption. > > All modern versions of Tomcat (8.5 and above) are compatible with Java 11. > GIYF https://tomcat.apache.org/whichversion.html Re: Question about directory listing sorting .. 2021-07-02 Thread Christopher Schultz Konstantin, On 7/2/21 05:28, Konstantin Kolinko wrote: пт, 2 июл. 2021 г. в 04:04, John Dale (DB2DOM) : Doesn't seem to work for me on 9.0.41 (it's an older development box). I found these interesting: ow with patch v3: 1. "s=NA" name=asc 2. "s=ND" name=dsc 3. "s=SA" size=asc 4. "s=SD" size=dsc 5. "s=MA" modify=asc 6. "s=MD" modify=dsc From here: https://bz.apache.org/bugzilla/show_bug.cgi?id=57287 Before I get too far down the road, I thought I would reach out. Params don't seem to affect listing sort order. It is off by default. I updated the BZ issue to point this out. https://bz.apache.org/bugzilla/show_bug.cgi?id=57287#c12 Parameter names are a bit different. E.g. with 9.0.50 (I modified DefaultServer configuration, and using the examples web app): http://localhost:8080/examples/jsp/cal/?C=N;O=A http://localhost:8080/examples/jsp/cal/?C=N;O=D My first thought was "holy crap, someone cares about this feature?" :) John, you're just made my trip to Brussels entirely worth it. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about directory listing sorting .. 2021-07-02 Thread Konstantin Kolinko пт, 2 июл. 2021 г. в 04:04, John Dale (DB2DOM) : > > Doesn't seem to work for me on 9.0.41 (it's an older development box). > > I found these interesting: > ow with patch v3: > 1. "s=NA" name=asc > 2. "s=ND" name=dsc > 3. "s=SA" size=asc > 4. "s=SD" size=dsc > 5. "s=MA" modify=asc > 6. "s=MD" modify=dsc > > From here: > https://bz.apache.org/bugzilla/show_bug.cgi?id=57287 > > Before I get too far down the road, I thought I would reach out. > Params don't seem to affect listing sort order. It is off by default. I updated the BZ issue to point this out. https://bz.apache.org/bugzilla/show_bug.cgi?id=57287#c12 Parameter names are a bit different. E.g. with 9.0.50 (I modified DefaultServer configuration, and using the examples web app): http://localhost:8080/examples/jsp/cal/?C=N;O=A http://localhost:8080/examples/jsp/cal/?C=N;O=D Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-06-07 Thread Christopher Schultz xcorpius, On 6/7/21 06:44, xcorpius wrote: Just one more thing. I understand my mistake with the difference between encryption and digest. Fortunately, the Tomcat committers have a sufficiently sound understanding of both basic logic and basic cryptography not to waste their time on such an exercise. Ok, but the question is: Why can Weblogic encrypt the password and Tomcat can't? https://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#JDBCA477 context.xml: ... password="passwordfile=secret.txt;NRFCIWRNFUGUWRMWUOGRXGRHOWRZFGWHFEO" /> ... secret.txt password=tiger This is the level of security JBoss provides. If it's more complicated than that, it just degrades to this solution. I cannot fathom why "configuration files must not contain plaintext credentials" somehow doesn't cover secret.txt. Maybe context.xml counts as a "configuration file" but secret.txt counts as a "password file". I dunno. If you use the Tomcat Vault, you still have to have the vault password somewhere. That's why we say it's "moving the goalposts": it doesn't actually solve the problem: it just moves the problem elsewhere. We have tried to make everything we've said in this thread abundantly clear in the FAQ. If you think something isn't very clear, please let us know how we can improve it. -chris ‐‐‐ Original Message ‐‐‐ On Monday, 7 de June de 2021 11:42, Mark Thomas wrote: On 07/06/2021 09:56, xcorpius wrote: Hello again! Checking the documentation ... Tomcat can create an encrypted password with the "digest.sh" tool for application passwords. But you cannot create an encrypted password for the DB in the context.xml file. The only solution without adding anything is to give restrictive permissions to the context.xml file. Wouldn't it be the same problem? No. Why can't I generate an encrypted password for the database with the "digest.sh" tool instead of having to use a customized "factory"? Digesting != encrypting. Digests are one-way functions. A digested password is no use to a client that needs to authenticate itself to a server. I think people who develop Tomcat should consider this option. Fortunately, the Tomcat committers have a sufficiently sound understanding of both basic logic and basic cryptography not to waste their time on such an exercise. Mark Thank you very much to all. Xcorpius Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 30 de April de 2021 11:21, xcorpius xcorp...@protonmail.com wrote: :-) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 26 de April de 2021 19:03, jonmcalexan...@wellsfargo.com wrote: And when that isn't good enough for your senior management, take a look at the Tomcat Vault in GITHUB. :-) Dream * Excel * Explore * Inspire Jon McAlexander Infrastructure Engineer Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 12/30/2020, 12/31/2020 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: xcorpius xcorp...@protonmail.com.INVALID Sent: Monday, April 26, 2021 8:36 AM To: users@tomcat.apache.org Subject: Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 Thanks Olaf Mensaje original On 26 abr. 2021 14:02, Olaf Kock escribió: On 26.04.21 13:10, xcorpius wrote: Hi, I wanted to ask about how to encrypt database passwords in the context.xml file in Tomcat 9. Hi, please check this article: https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/ TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ It covers the topic once and for all... Olaf 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 -- 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 Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-06-07 Thread xcorpius Thanks Mark, This answer clears all my doubts. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 7 de June de 2021 13:19, Mark Thomas wrote: > On 07/06/2021 11:44, xcorpius wrote: > > > Just one more thing. > > I understand my mistake with the difference between encryption and digest. > > > > > Fortunately, the Tomcat committers have a sufficiently sound > > > understanding of both basic logic and basic cryptography not to waste > > > their time on such an exercise. > > > > Ok, but the question is: Why can Weblogic encrypt the password and Tomcat > > can't? > > It can't. > > All Weblogic is doing is moving the goalposts. The database password may > be encrypted that just means the decryption key needs to be provided in > plain text instead. No matter how many levels of indirection (or perhaps > that should be misdirection) are applied, ultimately the application > server process needs access to a secret in plain text. > > However complex the window dressing, it will come down to the operating > system limiting access to the plain text secret to one or more users. > This is fundamentally no different to the Tomcat recommendation to use > OS file permissions to limit access to the configuration file where the > secret is stored to the user used by Tomcat and root (or equivalent). > > If you want to allow more general read access to configuration files > then there are simple ways to move the secrets to a separate, more > tightly controlled file. > > Mark > > > https://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#JDBCA477 > > Thanks, > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Monday, 7 de June de 2021 11:42, Mark Thomas ma...@apache.org wrote: > > > > > On 07/06/2021 09:56, xcorpius wrote: > > > > > > > Hello again! > > > > Checking the documentation ... Tomcat can create an encrypted password > > > > with the "digest.sh" tool for application passwords. > > > > But you cannot create an encrypted password for the DB in the > > > > context.xml file. The only solution without adding anything is to give > > > > restrictive permissions to the context.xml file. > > > > Wouldn't it be the same problem? > > > > > > No. > > > > > > > Why can't I generate an encrypted password for the database with the > > > > "digest.sh" tool instead of having to use a customized "factory"? > > > > > > Digesting != encrypting. > > > Digests are one-way functions. A digested password is no use to a client > > > that needs to authenticate itself to a server. > > > > > > > I think people who develop Tomcat should consider this option. > > > > > > Fortunately, the Tomcat committers have a sufficiently sound > > > understanding of both basic logic and basic cryptography not to waste > > > their time on such an exercise. > > > Mark > > > > > > > Thank you very much to all. > > > > Xcorpius > > > > Sent with ProtonMail Secure Email. > > > > ‐‐‐ Original Message ‐‐‐ > > > > On Friday, 30 de April de 2021 11:21, xcorpius xcorp...@protonmail.com > > > > wrote: > > > > > > > > > :-) > > > > > Sent with ProtonMail Secure Email. > > > > > ‐‐‐ Original Message ‐‐‐ > > > > > On Monday, 26 de April de 2021 19:03, jonmcalexan...@wellsfargo.com > > > > > wrote: > > > > > > > > > > > And when that isn't good enough for your senior management, take a > > > > > > look at the Tomcat Vault in GITHUB. :-) > > > > > > Dream * Excel * Explore * Inspire > > > > > > Jon McAlexander > > > > > > Infrastructure Engineer > > > > > > Asst Vice President > > > > > > Middleware Product Engineering > > > > > > Enterprise CIO | Platform Services | Middleware | Infrastructure > > > > > > Solutions > > > > > > 8080 Cobblestone Rd | Urbandale, IA 50322 > > > > > > MAC: F4469-010 > > > > > > Tel 515-988-2508 | Cell 515-988-2508 > > > > > > jonmcalexan...@wellsfargo.com > > > > > > Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, > > > > > > 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, > > > > > > 12/28/2020, 1 Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-06-07 Thread Mark Thomas On 07/06/2021 11:44, xcorpius wrote: Just one more thing. I understand my mistake with the difference between encryption and digest. Fortunately, the Tomcat committers have a sufficiently sound understanding of both basic logic and basic cryptography not to waste their time on such an exercise. Ok, but the question is: Why can Weblogic encrypt the password and Tomcat can't? It can't. All Weblogic is doing is moving the goalposts. The database password may be encrypted that just means the decryption key needs to be provided in plain text instead. No matter how many levels of indirection (or perhaps that should be misdirection) are applied, ultimately the application server process needs access to a secret in plain text. However complex the window dressing, it will come down to the operating system limiting access to the plain text secret to one or more users. This is fundamentally no different to the Tomcat recommendation to use OS file permissions to limit access to the configuration file where the secret is stored to the user used by Tomcat and root (or equivalent). If you want to allow more general read access to configuration files then there are simple ways to move the secrets to a separate, more tightly controlled file. Mark https://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#JDBCA477 Thanks, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 7 de June de 2021 11:42, Mark Thomas wrote: On 07/06/2021 09:56, xcorpius wrote: Hello again! Checking the documentation ... Tomcat can create an encrypted password with the "digest.sh" tool for application passwords. But you cannot create an encrypted password for the DB in the context.xml file. The only solution without adding anything is to give restrictive permissions to the context.xml file. Wouldn't it be the same problem? No. Why can't I generate an encrypted password for the database with the "digest.sh" tool instead of having to use a customized "factory"? Digesting != encrypting. Digests are one-way functions. A digested password is no use to a client that needs to authenticate itself to a server. I think people who develop Tomcat should consider this option. Fortunately, the Tomcat committers have a sufficiently sound understanding of both basic logic and basic cryptography not to waste their time on such an exercise. Mark Thank you very much to all. Xcorpius Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 30 de April de 2021 11:21, xcorpius xcorp...@protonmail.com wrote: :-) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 26 de April de 2021 19:03, jonmcalexan...@wellsfargo.com wrote: And when that isn't good enough for your senior management, take a look at the Tomcat Vault in GITHUB. :-) Dream * Excel * Explore * Inspire Jon McAlexander Infrastructure Engineer Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 12/30/2020, 12/31/2020 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: xcorpius xcorp...@protonmail.com.INVALID Sent: Monday, April 26, 2021 8:36 AM To: users@tomcat.apache.org Subject: Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 Thanks Olaf Mensaje original On 26 abr. 2021 14:02, Olaf Kock escribió: On 26.04.21 13:10, xcorpius wrote: Hi, I wanted to ask about how to encrypt database passwords in the context.xml file in Tomcat 9. Hi, please check this article: https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/ TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ It covers the topic once and for all... Olaf 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 -- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-06-07 Thread xcorpius Just one more thing. I understand my mistake with the difference between encryption and digest. > Fortunately, the Tomcat committers have a sufficiently sound > understanding of both basic logic and basic cryptography not to waste > their time on such an exercise. Ok, but the question is: Why can Weblogic encrypt the password and Tomcat can't? https://docs.oracle.com/middleware/1213/wls/JDBCA/ds_security.htm#JDBCA477 Thanks, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 7 de June de 2021 11:42, Mark Thomas wrote: > On 07/06/2021 09:56, xcorpius wrote: > > > Hello again! > > Checking the documentation ... Tomcat can create an encrypted password with > > the "digest.sh" tool for application passwords. > > But you cannot create an encrypted password for the DB in the context.xml > > file. The only solution without adding anything is to give restrictive > > permissions to the context.xml file. > > Wouldn't it be the same problem? > > No. > > > Why can't I generate an encrypted password for the database with the > > "digest.sh" tool instead of having to use a customized "factory"? > > Digesting != encrypting. > > Digests are one-way functions. A digested password is no use to a client > that needs to authenticate itself to a server. > > > I think people who develop Tomcat should consider this option. > > Fortunately, the Tomcat committers have a sufficiently sound > understanding of both basic logic and basic cryptography not to waste > their time on such an exercise. > > Mark > > > Thank you very much to all. > > Xcorpius > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Friday, 30 de April de 2021 11:21, xcorpius xcorp...@protonmail.com > > wrote: > > > > > :-) > > > Sent with ProtonMail Secure Email. > > > ‐‐‐ Original Message ‐‐‐ > > > On Monday, 26 de April de 2021 19:03, jonmcalexan...@wellsfargo.com wrote: > > > > > > > And when that isn't good enough for your senior management, take a look > > > > at the Tomcat Vault in GITHUB. :-) > > > > Dream * Excel * Explore * Inspire > > > > Jon McAlexander > > > > Infrastructure Engineer > > > > Asst Vice President > > > > Middleware Product Engineering > > > > Enterprise CIO | Platform Services | Middleware | Infrastructure > > > > Solutions > > > > 8080 Cobblestone Rd | Urbandale, IA 50322 > > > > MAC: F4469-010 > > > > Tel 515-988-2508 | Cell 515-988-2508 > > > > jonmcalexan...@wellsfargo.com > > > > Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, > > > > 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, > > > > 12/29/2020, 12/30/2020, 12/31/2020 > > > > This message may contain confidential and/or privileged information. If > > > > you are not the addressee or authorized to receive this for the > > > > addressee, you must not use, copy, disclose, or take any action based > > > > on this message or any information herein. If you have received this > > > > message in error, please advise the sender immediately by reply e-mail > > > > and delete this message. Thank you for your cooperation. > > > > > > > > > -Original Message- > > > > > From: xcorpius xcorp...@protonmail.com.INVALID > > > > > Sent: Monday, April 26, 2021 8:36 AM > > > > > To: users@tomcat.apache.org > > > > > Subject: Re: Question about encrypting database passwords in the > > > > > context.xml file - Tomcat 9 > > > > > Thanks Olaf > > > > > Mensaje original > > > > > On 26 abr. 2021 14:02, Olaf Kock escribió: > > > > > > > > > > > On 26.04.21 13:10, xcorpius wrote: > > > > > > > > > > > > > Hi, > > > > > > > I wanted to ask about how to encrypt database passwords in the > > > > > > > context.xml file in Tomcat 9. > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > please check this article: > > > > > > > > > > https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/ > > > > > TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ > > > > > > > > > > > It covers the topic once and for all... > > > > > > Olaf > > > > > > 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 > > -- > > 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: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-06-07 Thread xcorpius Thanks Mark for your clarifications. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 7 de June de 2021 11:42, Mark Thomas wrote: > On 07/06/2021 09:56, xcorpius wrote: > > > Hello again! > > Checking the documentation ... Tomcat can create an encrypted password with > > the "digest.sh" tool for application passwords. > > But you cannot create an encrypted password for the DB in the context.xml > > file. The only solution without adding anything is to give restrictive > > permissions to the context.xml file. > > Wouldn't it be the same problem? > > No. > > > Why can't I generate an encrypted password for the database with the > > "digest.sh" tool instead of having to use a customized "factory"? > > Digesting != encrypting. > > Digests are one-way functions. A digested password is no use to a client > that needs to authenticate itself to a server. > > > I think people who develop Tomcat should consider this option. > > Fortunately, the Tomcat committers have a sufficiently sound > understanding of both basic logic and basic cryptography not to waste > their time on such an exercise. > > Mark > > > Thank you very much to all. > > Xcorpius > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Friday, 30 de April de 2021 11:21, xcorpius xcorp...@protonmail.com > > wrote: > > > > > :-) > > > Sent with ProtonMail Secure Email. > > > ‐‐‐ Original Message ‐‐‐ > > > On Monday, 26 de April de 2021 19:03, jonmcalexan...@wellsfargo.com wrote: > > > > > > > And when that isn't good enough for your senior management, take a look > > > > at the Tomcat Vault in GITHUB. :-) > > > > Dream * Excel * Explore * Inspire > > > > Jon McAlexander > > > > Infrastructure Engineer > > > > Asst Vice President > > > > Middleware Product Engineering > > > > Enterprise CIO | Platform Services | Middleware | Infrastructure > > > > Solutions > > > > 8080 Cobblestone Rd | Urbandale, IA 50322 > > > > MAC: F4469-010 > > > > Tel 515-988-2508 | Cell 515-988-2508 > > > > jonmcalexan...@wellsfargo.com > > > > Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, > > > > 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, > > > > 12/29/2020, 12/30/2020, 12/31/2020 > > > > This message may contain confidential and/or privileged information. If > > > > you are not the addressee or authorized to receive this for the > > > > addressee, you must not use, copy, disclose, or take any action based > > > > on this message or any information herein. If you have received this > > > > message in error, please advise the sender immediately by reply e-mail > > > > and delete this message. Thank you for your cooperation. > > > > > > > > > -Original Message- > > > > > From: xcorpius xcorp...@protonmail.com.INVALID > > > > > Sent: Monday, April 26, 2021 8:36 AM > > > > > To: users@tomcat.apache.org > > > > > Subject: Re: Question about encrypting database passwords in the > > > > > context.xml file - Tomcat 9 > > > > > Thanks Olaf > > > > > Mensaje original > > > > > On 26 abr. 2021 14:02, Olaf Kock escribió: > > > > > > > > > > > On 26.04.21 13:10, xcorpius wrote: > > > > > > > > > > > > > Hi, > > > > > > > I wanted to ask about how to encrypt database passwords in the > > > > > > > context.xml file in Tomcat 9. > > > > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > please check this article: > > > > > > > > > > https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/ > > > > > TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ > > > > > > > > > > > It covers the topic once and for all... > > > > > > Olaf > > > > > > 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 > > -- > > 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: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-06-07 Thread Mark Thomas On 07/06/2021 09:56, xcorpius wrote: Hello again! Checking the documentation ... Tomcat can create an encrypted password with the "digest.sh" tool for application passwords. But you cannot create an encrypted password for the DB in the context.xml file. The only solution without adding anything is to give restrictive permissions to the context.xml file. Wouldn't it be the same problem? No. Why can't I generate an encrypted password for the database with the "digest.sh" tool instead of having to use a customized "factory"? Digesting != encrypting. Digests are one-way functions. A digested password is no use to a client that needs to authenticate itself to a server. I think people who develop Tomcat should consider this option. Fortunately, the Tomcat committers have a sufficiently sound understanding of both basic logic and basic cryptography not to waste their time on such an exercise. Mark Thank you very much to all. Xcorpius Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 30 de April de 2021 11:21, xcorpius wrote: :-) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 26 de April de 2021 19:03, jonmcalexan...@wellsfargo.com wrote: And when that isn't good enough for your senior management, take a look at the Tomcat Vault in GITHUB. :-) Dream * Excel * Explore * Inspire Jon McAlexander Infrastructure Engineer Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 12/30/2020, 12/31/2020 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: xcorpius xcorp...@protonmail.com.INVALID Sent: Monday, April 26, 2021 8:36 AM To: users@tomcat.apache.org Subject: Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 Thanks Olaf Mensaje original On 26 abr. 2021 14:02, Olaf Kock escribió: On 26.04.21 13:10, xcorpius wrote: Hi, I wanted to ask about how to encrypt database passwords in the context.xml file in Tomcat 9. Hi, please check this article: https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/ TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ It covers the topic once and for all... Olaf 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-06-07 Thread xcorpius Ok, thank you very much Olaf. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 7 de June de 2021 11:36, Olaf Kock wrote: > On 07.06.21 10:56, xcorpius wrote: > > > Hello again! > > Checking the documentation ... Tomcat can create an encrypted password with > > the "digest.sh" tool for application passwords. > > But you cannot create an encrypted password for the DB in the context.xml > > file. The only solution without adding anything is to give restrictive > > permissions to the context.xml file. > > Wouldn't it be the same problem? Why can't I generate an encrypted password > > for the database with the "digest.sh" tool instead of having to use a > > customized "factory"? > > I think people who develop Tomcat should consider this option. > > Thank you very much to all. > > Sorry, those are not the same: Digested passwords cannot be undigested, > but any digestion of the same password reveals the same digested result, > so that they can be compared. (read about the difference between hashing > and encryption) > > For a database connection, you'll need to undigest (e.g. unencrypt) the > password and get it in clear text. And that's precisely what the FAQ > answers as impossible to do securely (without requiring manual input of > keys at each startup) > > There's nothing here to consider that hasn't been considered before. > > Olaf > > > > > > > > Hi, > > > > > > > I wanted to ask about how to encrypt database passwords in the > > > > > > > context.xml file in Tomcat 9. > > > > > > > Hi, > > > > > > > please check this article: > > > > > > > https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/ > > > > > > > TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ > > > > > > > > > > > It covers the topic once and for all... > > > > > > Olaf > > -- > > 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: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-06-07 Thread Olaf Kock On 07.06.21 10:56, xcorpius wrote: > Hello again! > > Checking the documentation ... Tomcat can create an encrypted password with > the "digest.sh" tool for application passwords. > > But you cannot create an encrypted password for the DB in the context.xml > file. The only solution without adding anything is to give restrictive > permissions to the context.xml file. > > Wouldn't it be the same problem? Why can't I generate an encrypted password > for the database with the "digest.sh" tool instead of having to use a > customized "factory"? > > I think people who develop Tomcat should consider this option. > > Thank you very much to all. Sorry, those are not the same: Digested passwords cannot be undigested, but any digestion of the same password reveals the same digested result, so that they can be compared. (read about the difference between hashing and encryption) For a database connection, you'll need to undigest (e.g. unencrypt) the password and get it in clear text. And that's precisely what the FAQ answers as impossible to do securely (without requiring manual input of keys at each startup) There's nothing here to consider that hasn't been considered before. Olaf >> Hi, >> I wanted to ask about how to encrypt database passwords in the >> context.xml file in Tomcat 9. > Hi, > please check this article: https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/ TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ > It covers the topic once and for all... > Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org RE: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-06-07 Thread xcorpius Hello again! Checking the documentation ... Tomcat can create an encrypted password with the "digest.sh" tool for application passwords. But you cannot create an encrypted password for the DB in the context.xml file. The only solution without adding anything is to give restrictive permissions to the context.xml file. Wouldn't it be the same problem? Why can't I generate an encrypted password for the database with the "digest.sh" tool instead of having to use a customized "factory"? I think people who develop Tomcat should consider this option. Thank you very much to all. Xcorpius Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, 30 de April de 2021 11:21, xcorpius wrote: > :-) > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Monday, 26 de April de 2021 19:03, jonmcalexan...@wellsfargo.com wrote: > > > And when that isn't good enough for your senior management, take a look at > > the Tomcat Vault in GITHUB. :-) > > Dream * Excel * Explore * Inspire > > Jon McAlexander > > Infrastructure Engineer > > Asst Vice President > > Middleware Product Engineering > > Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions > > 8080 Cobblestone Rd | Urbandale, IA 50322 > > MAC: F4469-010 > > Tel 515-988-2508 | Cell 515-988-2508 > > jonmcalexan...@wellsfargo.com > > Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, > > 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, > > 12/30/2020, 12/31/2020 > > This message may contain confidential and/or privileged information. If you > > are not the addressee or authorized to receive this for the addressee, you > > must not use, copy, disclose, or take any action based on this message or > > any information herein. If you have received this message in error, please > > advise the sender immediately by reply e-mail and delete this message. > > Thank you for your cooperation. > > > > > -Original Message- > > > From: xcorpius xcorp...@protonmail.com.INVALID > > > Sent: Monday, April 26, 2021 8:36 AM > > > To: users@tomcat.apache.org > > > Subject: Re: Question about encrypting database passwords in the > > > context.xml file - Tomcat 9 > > > Thanks Olaf > > > Mensaje original > > > On 26 abr. 2021 14:02, Olaf Kock escribió: > > > > > > > On 26.04.21 13:10, xcorpius wrote: > > > > > > > > > Hi, > > > > > I wanted to ask about how to encrypt database passwords in the > > > > > context.xml file in Tomcat 9. > > > > > > > > > > > > > > > > > Hi, > > > > please check this article: > > > > > > https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/ > > > TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ > > > > > > > It covers the topic once and for all... > > > > Olaf > > > > 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: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-04-30 Thread xcorpius :-) Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, 26 de April de 2021 19:03, wrote: > And when that isn't good enough for your senior management, take a look at > the Tomcat Vault in GITHUB. :-) > > Dream * Excel * Explore * Inspire > Jon McAlexander > Infrastructure Engineer > Asst Vice President > > Middleware Product Engineering > Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions > > 8080 Cobblestone Rd | Urbandale, IA 50322 > MAC: F4469-010 > Tel 515-988-2508 | Cell 515-988-2508 > > jonmcalexan...@wellsfargo.com > > Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, > 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, > 12/30/2020, 12/31/2020 > This message may contain confidential and/or privileged information. If you > are not the addressee or authorized to receive this for the addressee, you > must not use, copy, disclose, or take any action based on this message or any > information herein. If you have received this message in error, please advise > the sender immediately by reply e-mail and delete this message. Thank you for > your cooperation. > > > -Original Message- > > From: xcorpius xcorp...@protonmail.com.INVALID > > Sent: Monday, April 26, 2021 8:36 AM > > To: users@tomcat.apache.org > > Subject: Re: Question about encrypting database passwords in the > > context.xml file - Tomcat 9 > > Thanks Olaf > > Mensaje original > > On 26 abr. 2021 14:02, Olaf Kock escribió: > > > > > On 26.04.21 13:10, xcorpius wrote: > > > > > > > Hi, > > > > I wanted to ask about how to encrypt database passwords in the > > > > context.xml file in Tomcat 9. > > > > > > > > > > > > > Hi, > > > please check this article: > > > > https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/ > > TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ > > > > > It covers the topic once and for all... > > > Olaf > > > > > > 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: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-04-27 Thread Christopher Schultz Jon, On 4/26/21 13:03, jonmcalexan...@wellsfargo.com.INVALID wrote: And when that isn't good enough for your senior management, take a look at the Tomcat Vault in GITHUB. :-) I'm going to publish a STIG for web applications that includes the need to encrypt the password for the Tomcat Vault. :3 We can move the goalposts, too. :) -chris Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 12/30/2020, 12/31/2020 Might want to update that, Jon. -Original Message- From: xcorpius Sent: Monday, April 26, 2021 8:36 AM To: users@tomcat.apache.org Subject: Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 Thanks Olaf Mensaje original On 26 abr. 2021 14:02, Olaf Kock escribió: On 26.04.21 13:10, xcorpius wrote: Hi, I wanted to ask about how to encrypt database passwords in the context.xml file in Tomcat 9. Hi, please check this article: https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/ TOMCAT/Password__;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1- FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ It covers the topic once and for all... Olaf - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org RE: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-04-26 Thread jonmcalexander And when that isn't good enough for your senior management, take a look at the Tomcat Vault in GITHUB. :-) Dream * Excel * Explore * Inspire Jon McAlexander Infrastructure Engineer Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 12/30/2020, 12/31/2020 This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. > -Original Message- > From: xcorpius > Sent: Monday, April 26, 2021 8:36 AM > To: users@tomcat.apache.org > Subject: Re: Question about encrypting database passwords in the > context.xml file - Tomcat 9 > > Thanks Olaf > > Mensaje original > On 26 abr. 2021 14:02, Olaf Kock escribió: > > > On 26.04.21 13:10, xcorpius wrote: > >> Hi, > >> > >> I wanted to ask about how to encrypt database passwords in the > context.xml file in Tomcat 9. > >> > > Hi, > > > > please check this article: > > > https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/ > TOMCAT/Password__;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1- > FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$ > > > > It covers the topic once and for all... > > > > Olaf > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-04-26 Thread xcorpius Thanks Olaf Mensaje original On 26 abr. 2021 14:02, Olaf Kock escribió: > On 26.04.21 13:10, xcorpius wrote: >> Hi, >> >> I wanted to ask about how to encrypt database passwords in the context.xml >> file in Tomcat 9. >> > Hi, > > please check this article: > https://cwiki.apache.org/confluence/display/TOMCAT/Password > > It covers the topic once and for all... > > Olaf > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about encrypting database passwords in the context.xml file - Tomcat 9 2021-04-26 Thread Olaf Kock On 26.04.21 13:10, xcorpius wrote: > Hi, > > I wanted to ask about how to encrypt database passwords in the context.xml > file in Tomcat 9. > Hi, please check this article: https://cwiki.apache.org/confluence/display/TOMCAT/Password It covers the topic once and for all... Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question ad distributing non-Java-binaries with a webapp ... 2021-04-12 Thread Rony G. Flatscher (Apache) Hi Konstantin, thank you *very* much for your extremely helpful information, which gives me quite something to digest and think about! Your remark about the JVM and loading a native library through one classloader only makes me think that it would not be possible at the moment to have two or more webapps with binary resources (that may even be at different version levels over time). Although I would not pursue this therefore at the moment, I still will put your valuable information on the table of "interesting things to explore" and may come back later. The motivation behind such thoughts is to exploit Tomcat as much as possible as it has turned out to be really *great* boon for empowering business administration students to get to create web applications with Tomcat in surprisingly short time (and if BA students can get empowered to exploit Tomcat within a short time, then professionals can get empowered in a fraction of that time, even if they do not speak Java). [In the context of this question the idea was to supply the ooRexx interpreter together with the webapp, such that the webapp contains everything needed to run it. OTOH the students have the interpreter already installed together with its Java bridge and as such can become productive with Tomcat, right after having Tomcat installed on their machines (Windows, Apple and Linux).] Again, thank you very much! ---rony On 11.04.2021 15:19, Konstantin Kolinko wrote: > сб, 10 апр. 2021 г. в 21:50, Rony G. Flatscher (Apache) : >> Is it possible to place and use binaries (including shared libraries) in a >> webapp? Very much like >> supplying jars to the "lib"-directory? >> >> Use case: if possible, I would like to create a webapp that includes >> non-Java binaries (executable, >> image and shared libraries) that get interfaced with via JNI. >> >> If this is possible then how so? Any pointers/hints would be highly >> appreciated! > Hi, Rony! > > 1) You may look for an inspiration on how Tomcat Navive library is loaded > https://tomcat.apache.org/tomcat-9.0-doc/apr.html > https://tomcat.apache.org/native-doc/ > > Note that "64-bit Windows zip" binary distribution includes the > library (tcnative-1.dll). > https://tomcat.apache.org/download-90.cgi > > In the source code, look at > org.apache.tomcat.jni.Library > org.apache.catalina.core.AprLifecycleListener > and its message resources, > java/org/apache/catalina/core/LocalStrings.properties > > You may find examples of System.load(), System.loadLibrary(), > System.mapLibraryName() calls in the Library class. > > See also the system property "java.library.path". > > > 2) JVM has a limitation that a library is allowed to be loaded by one > classloader only. > > That is why using a web application classloader looks to be a poor > place for loading a library, if you are ever going to use its full > features (parallel deployment of several web applications, a reload / > redeploy without stopping Tomcat, etc.) See > https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html > > 3) It is possible to load any classes when Apache Tomcat starts: > > a) with a custom Listener, > > b) abusing a JreMemoryLeakPreventionListener > https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html > > c) as a custom resource > https://tomcat.apache.org/tomcat-9.0-doc/jndi-resources-howto.html#Generic_JavaBean_Resources > > HTH. > > Best regards, > Konstantin Kolinko > > - > 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: Question ad distributing non-Java-binaries with a webapp ... 2021-04-11 Thread Konstantin Kolinko сб, 10 апр. 2021 г. в 21:50, Rony G. Flatscher (Apache) : > > Is it possible to place and use binaries (including shared libraries) in a > webapp? Very much like > supplying jars to the "lib"-directory? > > Use case: if possible, I would like to create a webapp that includes non-Java > binaries (executable, > image and shared libraries) that get interfaced with via JNI. > > If this is possible then how so? Any pointers/hints would be highly > appreciated! Hi, Rony! 1) You may look for an inspiration on how Tomcat Navive library is loaded https://tomcat.apache.org/tomcat-9.0-doc/apr.html https://tomcat.apache.org/native-doc/ Note that "64-bit Windows zip" binary distribution includes the library (tcnative-1.dll). https://tomcat.apache.org/download-90.cgi In the source code, look at org.apache.tomcat.jni.Library org.apache.catalina.core.AprLifecycleListener and its message resources, java/org/apache/catalina/core/LocalStrings.properties You may find examples of System.load(), System.loadLibrary(), System.mapLibraryName() calls in the Library class. See also the system property "java.library.path". 2) JVM has a limitation that a library is allowed to be loaded by one classloader only. That is why using a web application classloader looks to be a poor place for loading a library, if you are ever going to use its full features (parallel deployment of several web applications, a reload / redeploy without stopping Tomcat, etc.) See https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html 3) It is possible to load any classes when Apache Tomcat starts: a) with a custom Listener, b) abusing a JreMemoryLeakPreventionListener https://tomcat.apache.org/tomcat-9.0-doc/config/listeners.html c) as a custom resource https://tomcat.apache.org/tomcat-9.0-doc/jndi-resources-howto.html#Generic_JavaBean_Resources HTH. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about TLS/SSL setup and SSLHostConfig or not 2021-03-02 Thread Alex On 02.03.21 23:50, Peter Kreuser wrote: Alex, Am 02.03.2021 um 23:19 schrieb Alex : Hi. On 02.03.21 23:14, John Larsen wrote: I usually let the apache webserver or nginx handle the SSL while proxying to the tomcat. Unless you need some really fancy rewriting or caching, Tomcat is absolutely capable to handle this. Even static files are OK nowadays. To use tomcat's built in server you'll need to import the SSL certificate into the keystore via your jdk. That’s not the case anymore. Tomcat 8.5.x perfectly speaks PEM-files and openssl config. (See below) Even dynamic reloading of SSL configs can be achieved with the jmxproxy. Fully agree, but sometimes it is requierd that the HAProxy/nginx talk TLS to the backend, in this case tomcat. John Larsen On Tue, Mar 2, 2021 at 3:06 PM Alex wrote: Hi. I try to make a "good" tomcat config and read the docs. Now in the Connector doc is the following statement. http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support Each secure connector must define at least one SSLHostConfig. But when I look into the SSL/TLS Configuration How-To is the snipplet without SSLHostConfig. What's now the "best" way to setup TLS/SSL with tomcat. I would prefer to put SSLHostConfig but I'm not sure if it's the way how the developer think to setup the TLS in tomcat? I use JSSE as implementation. http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html http://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html ``` ``` You should move this to SSLHostConfig. Thank you for the clarification, I will do it. HTH Peter What's your suggestion and opinion to configure the tomcat in a proper way to use TLS also for the future versions. Regards Alex - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about TLS/SSL setup and SSLHostConfig or not 2021-03-02 Thread Peter Kreuser Alex, > Am 02.03.2021 um 23:19 schrieb Alex : > > Hi. > >> On 02.03.21 23:14, John Larsen wrote: >> I usually let the apache webserver or nginx handle the SSL while proxying >> to the tomcat. Unless you need some really fancy rewriting or caching, Tomcat is absolutely capable to handle this. Even static files are OK nowadays. >> To use tomcat's built in server you'll need to import the >> SSL certificate into the keystore via your jdk. That’s not the case anymore. Tomcat 8.5.x perfectly speaks PEM-files and openssl config. (See below) Even dynamic reloading of SSL configs can be achieved with the jmxproxy. > > Fully agree, but sometimes it is requierd that the HAProxy/nginx talk TLS to > the backend, in this case tomcat. > >> John Larsen >>> On Tue, Mar 2, 2021 at 3:06 PM Alex wrote: >>> Hi. >>> >>> I try to make a "good" tomcat config and read the docs. >>> >>> Now in the Connector doc is the following statement. >>> >>> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support >>> http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support >>> >>> Each secure connector must define at least one SSLHostConfig. >>> >>> But when I look into the SSL/TLS Configuration How-To is the snipplet >>> without SSLHostConfig. What's now the "best" way to setup TLS/SSL >>> with tomcat. I would prefer to put SSLHostConfig but I'm not sure if >>> it's the way how the developer think to setup the TLS in tomcat? >>> >>> I use JSSE as implementation. >>> >>> http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html >>> http://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html >>> >>> ``` >>> >>> >> protocol="org.apache.coyote.http11.Http11NioProtocol" >>> port="8443" maxThreads="200" >>> scheme="https" secure="true" SSLEnabled="true" >>> keystoreFile="${user.home}/.keystore" keystorePass="changeit" >>> clientAuth="false" sslProtocol="TLS"/> >>> ``` >>> You should move this to SSLHostConfig. HTH Peter >>> What's your suggestion and opinion to configure the tomcat in a >>> proper way to use TLS also for the future versions. >>> >>> Regards >>> Alex >>> >>> - >>> 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 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about TLS/SSL setup and SSLHostConfig or not 2021-03-02 Thread Alex Hi. On 02.03.21 23:14, John Larsen wrote: I usually let the apache webserver or nginx handle the SSL while proxying to the tomcat. To use tomcat's built in server you'll need to import the SSL certificate into the keystore via your jdk. Fully agree, but sometimes it is requierd that the HAProxy/nginx talk TLS to the backend, in this case tomcat. John Larsen On Tue, Mar 2, 2021 at 3:06 PM Alex wrote: Hi. I try to make a "good" tomcat config and read the docs. Now in the Connector doc is the following statement. http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support Each secure connector must define at least one SSLHostConfig. But when I look into the SSL/TLS Configuration How-To is the snipplet without SSLHostConfig. What's now the "best" way to setup TLS/SSL with tomcat. I would prefer to put SSLHostConfig but I'm not sure if it's the way how the developer think to setup the TLS in tomcat? I use JSSE as implementation. http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html http://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html ``` ``` What's your suggestion and opinion to configure the tomcat in a proper way to use TLS also for the future versions. Regards Alex - 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: Question about TLS/SSL setup and SSLHostConfig or not 2021-03-02 Thread John Larsen I usually let the apache webserver or nginx handle the SSL while proxying to the tomcat. To use tomcat's built in server you'll need to import the SSL certificate into the keystore via your jdk. John Larsen On Tue, Mar 2, 2021 at 3:06 PM Alex wrote: > Hi. > > I try to make a "good" tomcat config and read the docs. > > Now in the Connector doc is the following statement. > > http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support > http://tomcat.apache.org/tomcat-10.0-doc/config/http.html#SSL_Support > > Each secure connector must define at least one SSLHostConfig. > > But when I look into the SSL/TLS Configuration How-To is the snipplet > without SSLHostConfig. What's now the "best" way to setup TLS/SSL > with tomcat. I would prefer to put SSLHostConfig but I'm not sure if > it's the way how the developer think to setup the TLS in tomcat? > > I use JSSE as implementation. > > http://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html > http://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html > > ``` > > protocol="org.apache.coyote.http11.Http11NioProtocol" > port="8443" maxThreads="200" > scheme="https" secure="true" SSLEnabled="true" > keystoreFile="${user.home}/.keystore" keystorePass="changeit" > clientAuth="false" sslProtocol="TLS"/> > ``` > > What's your suggestion and opinion to configure the tomcat in a > proper way to use TLS also for the future versions. > > Regards > Alex > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > RE: Question regarding Invoker 2020-10-26 Thread jonmcalexander Thank you! Dream * Excel * Explore * Inspire Jon McAlexander Infrastructure Engineer Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Mark Thomas Sent: Monday, October 26, 2020 1:06 PM To: users@tomcat.apache.org Subject: Re: Question regarding Invoker On 26/10/2020 17:46, jonmcalexan...@wellsfargo.com.INVALID wrote: > I believe I have read that the Invoker Servlet was deprecated in Tomcat 6 and > removed entirely in Tomcat 7 and above. Can someone confirm that this is > correct? I couldn't find any announcement of this on tomcat.apache.org. Correct. See the Tomcat 6.0.x changelog: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Mark > > Thanks, > > > Dream * Excel * Explore * Inspire > Jon McAlexander > Infrastructure Engineer > Asst Vice President > > Middleware Product Engineering > Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions > > 8080 Cobblestone Rd | Urbandale, IA 50322 > MAC: F4469-010 > Tel 515-988-2508 | Cell 515-988-2508 > > jonmcalexan...@wellsfargo.com<mailto:jonmcalexan...@wellsfargo.com> > > > This message may contain confidential and/or privileged information. If you > are not the addressee or authorized to receive this for the addressee, you > must not use, copy, disclose, or take any action based on this message or any > information herein. If you have received this message in error, please advise > the sender immediately by reply e-mail and delete this message. Thank you for > your cooperation. > > - 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: Question regarding Invoker 2020-10-26 Thread Mark Thomas On 26/10/2020 17:46, jonmcalexan...@wellsfargo.com.INVALID wrote: > I believe I have read that the Invoker Servlet was deprecated in Tomcat 6 and > removed entirely in Tomcat 7 and above. Can someone confirm that this is > correct? I couldn't find any announcement of this on tomcat.apache.org. Correct. See the Tomcat 6.0.x changelog: http://tomcat.apache.org/tomcat-6.0-doc/changelog.html Mark > > Thanks, > > > Dream * Excel * Explore * Inspire > Jon McAlexander > Infrastructure Engineer > Asst Vice President > > Middleware Product Engineering > Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions > > 8080 Cobblestone Rd | Urbandale, IA 50322 > MAC: F4469-010 > Tel 515-988-2508 | Cell 515-988-2508 > > jonmcalexan...@wellsfargo.com > > > This message may contain confidential and/or privileged information. If you > are not the addressee or authorized to receive this for the addressee, you > must not use, copy, disclose, or take any action based on this message or any > information herein. If you have received this message in error, please advise > the sender immediately by reply e-mail and delete this message. Thank you for > your cooperation. > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question regarding servlet lifecycle and connection pooling .. 2020-08-02 Thread Mark Thomas On July 25, 2020 3:25:18 PM UTC, John Dale wrote: >Greetings; > >We've wrapped my connection pool interface in a Factory. Can you >confirm how the current request's thread is used by JDBC connection >pooling to MySQL? > >Sincerely, > >John > >- >To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >For additional commands, e-mail: users-h...@tomcat.apache.org It depends. What type of request (sync or async), which connection pool, etc. You need to ask a more specific question. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question regarding servlet lifecycle and connection pooling .. 2020-07-27 Thread Christopher Schultz -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 7/25/20 11:25, John Dale wrote: > We've wrapped my connection pool interface in a Factory. Can you > confirm how the current request's thread is used by JDBC > connection pooling to MySQL? Are you using Tomcat to manage your DataSource resource? For example: Context ctx = new InitialContext(); DataSource ds = (DataSource)ctx.lookup("java:/comp/env/jdbc/myDataSource"); Connection conn = ds.getConnection(); ? If you have written your own datasource factory, then when you call ctx.lookup(), you will be getting the DataSource object returned by your factory when your web application starts. If you make calls to DataSource.getConnection, Connection.prepareStatement, etc. everything is done in the current thread. If you use Tomcat's tomcat-pool or DBCP2, the only things that happen outside of the current request-processing thread are the background maintenance tasks such as checking for abandoned connections. Does that answer your question? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8e+8oACgkQHPApP6U8 pFihVQ/9H1gtRafA2J5+m0WtgsM7SGVnzbBnPsHpu6Fu58Z+7qK5Ds4sx1OVLoZq PlZa33mZ73MzaLJ5fQh7CI6/dKdl+k6Vst5gkejV+sWvmWnKZuA5t+8+emxecgVg aYU08BLQeblLMqPUp9gjYpaoqgFgpe6EYkE8zQIY63nWAp30yHUW45QPMm0vdtAM gNnUEAHgggMSyTwvrqFlBwxjDJThe4WUS934wg+VsS4CyUvtkg0i97DMoS1FWabH Ipaw7//XKdT63MXI25gJHvo8D3Tu0OPAWJGoqWycFuO6iOpz9gijctnYfWawOOaX 6JvBGH3hYdf2W/qisnnklI6Ips8sSuwwBKzTPcB1ZJGptyJnavi2/LULxqgsE+AY yQGCcj4JFgpf65qOrwo4bBzVS3U+kc+VB9AjUoNQBSyLMmoiq+/8OFx83yT+g/Fr Qt34+b28W49TOzF4v7KFmSVPBlJ40pQIgS7R04RD5aPeNqYkVn0BUmav05q4fTe+ lp3nAcRCfpJMG3T4TDTtHH24xT2WeC3+wyhOyP3QlsYML8yMO6MGOfYCW6wN0jlM muZMCHYlnkZ+xZqaQ9GU6qqL2WhClf8v9Xjw/ppClSr+D8Cx4JXdTKXhO9QUKb0j TyvkHD35UwGcDlQduqyiUQb5tpOC2Ym5vjsZFbmTwbZeKE39zmk= =gT2X -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org RE: Question around catalina.policy change back with 9.0.33, etc. 2020-06-26 Thread jonmcalexander Thank you so much Mark!!! Dream * Excel * Explore * Inspire Jon McAlexander Asst Vice President Middleware Product Engineering Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions 8080 Cobblestone Rd | Urbandale, IA 50322 MAC: F4469-010 Tel 515-988-2508 | Cell 515-988-2508 jonmcalexan...@wellsfargo.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -Original Message- From: Mark Thomas Sent: Friday, June 26, 2020 5:14 AM To: users@tomcat.apache.org Subject: Re: Question around catalina.policy change back with 9.0.33, etc. On 26/06/2020 00:15, jonmcalexan...@wellsfargo.com.INVALID wrote: > I have a developer that is asking WHY the following policies were set to read > only. The Change Log doesn't illuminate why. > > // The cookie code needs these. > permission java.util.PropertyPermission > "org.apache.catalina.STRICT_SERVLET_COMPLIANCE", "read"; > permission java.util.PropertyPermission > "org.apache.tomcat.util.http.ServerCookie.STRICT_NAMING", "read"; > permission java.util.PropertyPermission > > "org.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR", > "read"; > > Any information I can share with her? Those permissions were removed, not set to read only, for 9.0.9 onwards. It was the result of a refactoring: https://github.com/apache/tomcat/commit/6ceb931e1aac0355e0980d09814559f24406a14a I made the change but it was 2 years ago. I don't recall the motivation off-hand. /me heads off to look at the archives... ..and that is why we have the archives. It appears to stem from this issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=43925 The fix for that issue led to this: https://tomcat.markmail.org/thread/mab6jbyb57phslwk Rather than add a permission, the code was refactored so the additional permission (and some of the existing permissions) were no longer required. It isn't documented, but I strongly suspect that got me looking at other permissions which led to the refactoring that allowed the removal of the cookie permissions. The general principle behind all of this being the fewer explicit permissions you need to give to applications the better. HTH, 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: Question around catalina.policy change back with 9.0.33, etc. 2020-06-26 Thread Mark Thomas On 26/06/2020 00:15, jonmcalexan...@wellsfargo.com.INVALID wrote: > I have a developer that is asking WHY the following policies were set to read > only. The Change Log doesn't illuminate why. > > // The cookie code needs these. > permission java.util.PropertyPermission > "org.apache.catalina.STRICT_SERVLET_COMPLIANCE", "read"; > permission java.util.PropertyPermission > "org.apache.tomcat.util.http.ServerCookie.STRICT_NAMING", "read"; > permission java.util.PropertyPermission > "org.apache.tomcat.util.http.ServerCookie.FWD_SLASH_IS_SEPARATOR", > "read"; > > Any information I can share with her? Those permissions were removed, not set to read only, for 9.0.9 onwards. It was the result of a refactoring: https://github.com/apache/tomcat/commit/6ceb931e1aac0355e0980d09814559f24406a14a I made the change but it was 2 years ago. I don't recall the motivation off-hand. /me heads off to look at the archives... ..and that is why we have the archives. It appears to stem from this issue: https://bz.apache.org/bugzilla/show_bug.cgi?id=43925 The fix for that issue led to this: https://tomcat.markmail.org/thread/mab6jbyb57phslwk Rather than add a permission, the code was refactored so the additional permission (and some of the existing permissions) were no longer required. It isn't documented, but I strongly suspect that got me looking at other permissions which led to the refactoring that allowed the removal of the cookie permissions. The general principle behind all of this being the fewer explicit permissions you need to give to applications the better. HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org RE: Question about AJP13 connector 2020-06-02 Thread Hristo Yanchev Karakolev Thank you for the accurate explanation. -Original Message- From: Mark Thomas Sent: 02 June 2020 11:01 To: users@tomcat.apache.org Subject: Re: Question about AJP13 connector On 02/06/2020 08:53, Hristo Yanchev Karakolev wrote: > Hello, > > I'm fairly new to tomcat and I'm charged with the task to do something that I > don't quite understand. > > > > My environment : > > > > OS : Windows Server 2016 Standard x64 > > > > I have 2 tomcat servers : > > #1 - Tomcat 8.5.37 working on a Web Server machine > > #2 - Tomcat 9.0.20 working on a LAN Server machine. > > > > Both servers are in different domains. > > > > Our final goal is to have this configuration : > > On the web server machine we use IIS to serve our web site . When the web > site requires data it turns to Tomcat #1 which is also installed on web > server machine. Tomcat #1 forwards the request to Tomcat #2 and returns the > result to IIS. This isn't possible out of the box. Tomcat doesn't provide reverse proxy functionality. > My question is : > > Is it possible to connect the both servers using AJP13 connectors (giving the > fact that I will do the proper port forwarding of course) and how? Not possible. > I found tons of information how to do this with ("IIS" -> "Tomcat") or > ("Apache httpd" -> "Tomcat") configuration but in my case I have ("Tomcat" -> > "Tomcat") establishment. This isn't supported. There might be a third-party module out there that does this but I would want to test it *very* carefully. Reverse proxies are easy to get the simple stuff working and extremely tricky to get right for all the edge cases. In your position I would be suggesting a different solution architecture where IIS was configured to go directly to each of the 2 Tomcat instances as appropriate. 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: Question about AJP13 connector 2020-06-02 Thread Mark Thomas On 02/06/2020 08:53, Hristo Yanchev Karakolev wrote: > Hello, > > I'm fairly new to tomcat and I'm charged with the task to do something that I > don't quite understand. > > > > My environment : > > > > OS : Windows Server 2016 Standard x64 > > > > I have 2 tomcat servers : > > #1 - Tomcat 8.5.37 working on a Web Server machine > > #2 - Tomcat 9.0.20 working on a LAN Server machine. > > > > Both servers are in different domains. > > > > Our final goal is to have this configuration : > > On the web server machine we use IIS to serve our web site . When the web > site requires data it turns to Tomcat #1 which is also installed on web > server machine. Tomcat #1 forwards the request to Tomcat #2 and returns the > result to IIS. This isn't possible out of the box. Tomcat doesn't provide reverse proxy functionality. > My question is : > > Is it possible to connect the both servers using AJP13 connectors (giving the > fact that I will do the proper port forwarding of course) and how? Not possible. > I found tons of information how to do this with ("IIS" -> "Tomcat") or > ("Apache httpd" -> "Tomcat") configuration but in my case I have ("Tomcat" -> > "Tomcat") establishment. This isn't supported. There might be a third-party module out there that does this but I would want to test it *very* carefully. Reverse proxies are easy to get the simple stuff working and extremely tricky to get right for all the edge cases. In your position I would be suggesting a different solution architecture where IIS was configured to go directly to each of the 2 Tomcat instances as appropriate. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question on HttpSession investigation 2020-02-12 Thread Konstantin Kolinko пн, 10 февр. 2020 г. в 02:32, M. Manna : > > [...], we would like > to check using JMX whether this is present somewhere in session. Debugging > has not resulted into a successful outcome. > > We appreciate if this is not possible, but just wanted to check if tomcat > currently emits anything related to this. The Manager web application (that comes with Tomcat) is able to display contents of a session: - Click on the number that shows the count of active sessions in a web application. You will see a list of active sessions. - Click on sessionid. You will see a list of all attributes for that session. You may look into the source code for HTMLManagerServlet to see how "sessionDetail" command is implemented. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question on Apache Tomcat Patches 2020-02-11 Thread Mark Thomas On 11/02/2020 14:39, Walker, Mike (GE Aviation, US) wrote: > Hi Mark > > Thanks for responding. See answers below... > - what version of Apache Tomcat are you currently using? 7.0 on windows > 2012 server 7.0.what? Not that it really matters but the older it is, the more likely there will be some changes of which you should be particularly aware. > - where did you download this version from and was it a .zip, .exe or > something else? From apache web site, .exe OK. The Windows installer then. > - what version of Apache Tomcat do you want to move to? 7.0_Tomcat7_99, > windows 2012 server 7.0.99 > - where did you download this version from and is it a .zip, .exe or > something else? Apache web site, .exe OK. Still the Windows installer. > So apache only releases full versions not upgrades? Correct. > Does that mean if you run the version 7.99 it will create a new folder under > Apache Software Foundation folder for 7.99 files? I'm not sure what will happen as the installer is not (intentionally) designed for in-place upgrades like that. It might work. I don't recall every trying it. > Since this would imply a change to the path for Tomcat would registry or > other tomcat config files need to be modified for the new path? If you install to a new path, the installer will add the necessary registry settings and you'll end up with 2 Tomcat installations. > I assume all deployed .war files would need to be re-deployed in the new > version also? Correct. Mark > > Thanks for any help! > > Mike > > -Original Message- > From: Mark Thomas > Sent: Thursday, February 6, 2020 6:44 PM > To: users@tomcat.apache.org > Subject: EXT: Re: Question on Apache Tomcat Patches > > On 06/02/2020 20:28, Walker, Mike (GE Aviation, US) wrote: >> HI All- >> >> New to apache and apache patching. I have a question. When you run an >> apache patch (not an upgrade or install), should the patch create a new >> apache folder path, or simply modify & update the existing one? >> >> For example, if I am updating apache tomcat 7 to 7_99, should I expect to >> see a new folder C:\Program Files\Apache Software Foundation\Tomcat >> 7.0_Tomcat7_99, or should I just see updates & modifications made to the >> existing folder C:\Program Files\Apache Software Foundation\Tomcat 7.0 ? > > "Apache" normally means the "Apache HTTP Server Project" or "httpd". I'm > guessing from your second paragraph you are referring to Apache Tomcat - in > which case you are in the right place. > > The Apache Tomcat team does not distribute patches - we only distribute full > versions. There are options for how to upgrade but none of them provided by > the Tomcat community are automated. > > To help you (or point you in the right direction for help) we need to know: > > - what version of Apache Tomcat are you currently using? > - where did you download this version from and was it a .zip, .exe or > something else? > - what version of Apache Tomcat do you want to move to? > - where did you download this version from and is it a .zip, .exe or > something else? > > 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 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question on Apache Tomcat Patches 2020-02-11 Thread Olaf Kock On 11.02.20 15:39, Walker, Mike (GE Aviation, US) wrote: > So apache only releases full versions not upgrades? Does that mean if you > run the version 7.99 it will create a new folder under Apache Software > Foundation folder for 7.99 files? Since this would imply a change to the path > for Tomcat would registry or other tomcat config files need to be modified > for the new path? I assume all deployed .war files would need to be > re-deployed in the new version also? > Simple: The directory within the zip file will carry the number. Nothing forces you to continue to use that version numbered directory in your installation. You're free to move its contents around, rename the directory etc. I hope that helps, Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question on HttpSession investigation 2020-02-10 Thread Luis Rodríguez Fernández Hello M. Manna, I do think HttpSession.getAttributeNames(), HttpSession.getAttribute(name) should be good enough for debugging your issue. You can have a look at the good and classic examples servlet [1] included in every tomcat distribution. If you want to be sure what server is serving your request you can print as well the server's IP or hostname using Inet4Address.getLocalHost().getHostName(). Or even simpler you can add a system property like -Dserver.name=serverA and print it. Hope it helps, Luis [1] https://github.com/apache/tomcat/blob/master/webapps/examples/WEB-INF/classes/SessionExample.java El lun., 10 feb. 2020 a las 0:32, M. Manna () escribió: > Hello, > > I apologise in advance if the answer is obvious for this question. We are > trying to investigate (in an isolated cluster) whether our session > attributes are getting lost somewhere in the process. > > The issue is that we are setting it at a JSP Tag Level, however, when we do > an AJAX request back to the same server, the session doesn't have the > attribute set by the tag. Since it's two different servers, we would like > to check using JMX whether this is present somewhere in session. Debugging > has not resulted into a successful outcome. > > We appreciate if this is not possible, but just wanted to check if tomcat > currently emits anything related to this. > > Regards, > -- "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." - Samuel Beckett Re: Question on Apache Tomcat Patches 2020-02-06 Thread Mark Thomas On 06/02/2020 20:28, Walker, Mike (GE Aviation, US) wrote: > HI All- > > New to apache and apache patching. I have a question. When you run an > apache patch (not an upgrade or install), should the patch create a new > apache folder path, or simply modify & update the existing one? > > For example, if I am updating apache tomcat 7 to 7_99, should I expect to see > a new folder C:\Program Files\Apache Software Foundation\Tomcat > 7.0_Tomcat7_99, or should I just see updates & modifications made to the > existing folder C:\Program Files\Apache Software Foundation\Tomcat 7.0 ? "Apache" normally means the "Apache HTTP Server Project" or "httpd". I'm guessing from your second paragraph you are referring to Apache Tomcat - in which case you are in the right place. The Apache Tomcat team does not distribute patches - we only distribute full versions. There are options for how to upgrade but none of them provided by the Tomcat community are automated. To help you (or point you in the right direction for help) we need to know: - what version of Apache Tomcat are you currently using? - where did you download this version from and was it a .zip, .exe or something else? - what version of Apache Tomcat do you want to move to? - where did you download this version from and is it a .zip, .exe or something else? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question about thread's "keep alive time" value in Embed Tomcat 8.5 in Spring Boot 1.5 2019-11-05 Thread Christopher Schultz -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Roy, On 11/4/19 18:22, Roy Zhang wrote: > Dear Christopher, > > Really appreciate ur quick response! Sorry for late reply due to > personal affairs... > I haven't read the code in detail, but I'm guessing that the thread pool > uses a queue and not a stack of threads, so each thread gets used, > repeatedly, in order of availability. Note that Tomcat's thread pool is just a wrapper around Java'sThreadPoolExecutor > -- adding methods to handle Tomcat's lifecycle events, etc. So if the pool isn't behaving as you'd like it, you'll need to file a > but against the Java API and not Tomcat. [Roy] Based on ur comment, > my understanding is tomcat is using Java'sThreadPoolExecutor, > Java's ThreadPoolExecutor pick up new threads from thread pool > using FIFO approach. Regarding "So if the pool isn't behaving as > you'd like it, you'll need to file a but against the Java API and > not Tomcat.", do we have any mature solution (e.g, any open source > project) which change the tomcat thread pool's behavior (e.g, FIFO > approach)? So you'd like to use a LIFO thread pool? If you can find a LIFO executor in Java, then we can probably configure it in Tomcat. But writing a LIFO executor isn't exactly on our list of things to add to Tomcat itself. What's the goal, here? Your process must be able to tolerate a completely full thread-pool, so you have to plan for maximum capacity. Reducing process threads buys absolutely you nothing except bragging rights for "using the fewest possible resources". If you want fewer threads, make your thread pool smaller. If you want to auto-scale, don't look at live-threads. Look instead at recent-peak-concurrency. - -chris > On Fri, Nov 1, 2019 at 9:56 PM Christopher Schultz < > ch...@christopherschultz.net> wrote: > > Roy, > > On 11/1/19 08:23, Roy Zhang wrote: I am confused about "keep alive time" value in Embed Tomcat. I am using Spring Boot 1.5, embed tomcat version is 8.5. According to https://github.com/spring-projects/spring-boot/issues/16450#issueco mme > nt-480236238 > > > , > we can't configured thread's "keep alive time" via "maxIdleTime" parameter, "keep alive time" value is hard coded as 60s via https://github.com/apache/tomcat/blob/de1f55e672106031821948d5cac80 f40 > adc09513/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L884 > > > , > > It > is only hard-coded if you use the internal, default Executor. You > can instantiate your own Executor with whatever settings you wish. > > It's a bad name for that setting, but this is how long "excess" > threads will live when they are not being used. > I found 60s "keep alive time" sometimes take effect, some times it doesn't take effect. Could u please kindly help to review my following two cases and kindly provide explanation? Really appreciate ur help in advance! *Case 1 (60s "keep alive time" DOESN'T take effect):* API latency: _100ms_ Test step: run API with 800 concurrent threads for 1 minutes, then run API with 10 concurrent threads for about 1 hour. As we can see from following graph, after BusyThreads reduced from ~800 to 10, CurrentThreadsCount remains at 800 for following 1 hour (60s "keep alive time" DOESN'T take effect). After test stopped, CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). image.png > > Your images have been stripped from the mailing list. Find another > way to describe your problem. > > When you say "X concurrent threads", how often are requests being > made? Constantly? So you are sending requests as fast as possible > with c=10? > > I haven't read the code in detail, but I'm guessing that the > thread pool uses a queue and not a stack of threads, so each thread > gets used, repeatedly, in order of availability. That means that if > you keep making requests, you'll keep hitting *all* the threads in > the queue and not just the same 10 over and over again. So they > never time out. > *Case 2 (60s "keep alive time" DOES take effect):* API latency: _10s_ Test step: run API with 800 concurrent threads for 1 minutes, then run API with 10 concurrent threads for about 1 hour. As we can see from following graph, after BusyThreads reduced from ~800 to 10, CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). 60s "keep alive time" DOES take effect) > > Note that Tomcat's thread pool is just a wrapper around Java's > ThreadPoolExecutor -- adding methods to handle Tomcat's lifecycle > events, etc. > > So if the pool isn't behaving as you'd like it, you'll need to file > a but against the Re: Question about thread's "keep alive time" value in Embed Tomcat 8.5 in Spring Boot 1.5 2019-11-04 Thread Roy Zhang Dear Christopher, Really appreciate ur quick response! Sorry for late reply due to personal affairs... >>>I haven't read the code in detail, but I'm guessing that the thread pool uses a queue and not a stack of threads, so each thread gets used, repeatedly, in order of availability. >>>Note that Tomcat's thread pool is just a wrapper around >>>Java'sThreadPoolExecutor -- adding methods to handle Tomcat's lifecycle events, etc. >>>So if the pool isn't behaving as you'd like it, you'll need to file a but against the Java API and not Tomcat. [Roy] Based on ur comment, my understanding is tomcat is using Java'sThreadPoolExecutor, Java's ThreadPoolExecutor pick up new threads from thread pool using FIFO approach. Regarding "So if the pool isn't behaving as you'd like it, you'll need to file a but against the Java API and not Tomcat.", do we have any mature solution (e.g, any open source project) which change the tomcat thread pool's behavior (e.g, FIFO approach)? Thanks in advance! Thanks, Roy On Fri, Nov 1, 2019 at 9:56 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Roy, > > On 11/1/19 08:23, Roy Zhang wrote: > > I am confused about "keep alive time" value in Embed Tomcat. I am > > using Spring Boot 1.5, embed tomcat version is 8.5. > > > > According to > > https://github.com/spring-projects/spring-boot/issues/16450#issuecomme > nt-480236238 > > , > > > > > we can't configured thread's "keep alive time" via "maxIdleTime" > > parameter, "keep alive time" value is hard coded as 60s via > > https://github.com/apache/tomcat/blob/de1f55e672106031821948d5cac80f40 > adc09513/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L884 > > , > > It > > > is only hard-coded if you use the internal, default Executor. You > can instantiate your own Executor with whatever settings you wish. > > It's a bad name for that setting, but this is how long "excess" > threads will live when they are not being used. > > > I found 60s "keep alive time" sometimes take effect, some times it > > doesn't take effect. Could u please kindly help to review my > > following two cases and kindly provide explanation? Really > > appreciate ur help in advance! > > > > *Case 1 (60s "keep alive time" DOESN'T take effect):* API latency: > > _100ms_ Test step: run API with 800 concurrent threads for 1 > > minutes, then run API with 10 concurrent threads for about 1 hour. > > As we can see from following graph, after BusyThreads reduced from > > ~800 to 10, CurrentThreadsCount remains at 800 for following 1 hour > > (60s "keep alive time" DOESN'T take effect). After test stopped, > > CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). > > image.png > > Your images have been stripped from the mailing list. Find another way > to describe your problem. > > When you say "X concurrent threads", how often are requests being > made? Constantly? So you are sending requests as fast as possible with > c=10? > > I haven't read the code in detail, but I'm guessing that the thread > pool uses a queue and not a stack of threads, so each thread gets > used, repeatedly, in order of availability. That means that if you > keep making requests, you'll keep hitting *all* the threads in the > queue and not just the same 10 over and over again. So they never time > out. > > > *Case 2 (60s "keep alive time" DOES take effect):* API latency: > > _10s_ Test step: run API with 800 concurrent threads for 1 minutes, > > then run API with 10 concurrent threads for about 1 hour. As we can > > see from following graph, after BusyThreads reduced from ~800 to > > 10, CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). > > 60s "keep alive time" DOES take effect) > > Note that Tomcat's thread pool is just a wrapper around Java's > ThreadPoolExecutor -- adding methods to handle Tomcat's lifecycle > events, etc. > > So if the pool isn't behaving as you'd like it, you'll need to file a > but against the Java API and not Tomcat. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl28NzYACgkQHPApP6U8 > pFjcRxAApIe9WPrO43rIn+8TZ/KBncZbw2ZQr/nEew1pS7xdRFl2LVn/gMpuYaIe > 78rF/3M9S0aYcG93vaqzn1+BZXW5EI9EINo+UG3E17ZYeD162Cpl2Q7aqaB/Te0j > QR/JHIv31TAUpH39VLEpzfk/d1uct7oVZDq4P3kUjjAFwAo2G0useiHjokXtdIEm > 3wXL1e8ChpvdP8RfrPdeATdGtEvGh0zNDW2Qjce+7R5LoC55UpHqJfB+p8BB6nV/ > W6Jdp8CN8pVp+wROMMyK3HFvubFqSPcrKGURCmwKMH/QgRfRSTNpIfXYpubfOOqm > EF0XxvRc2s/x6ZqRrfnbkunqqmb0h35SXPaWl1RJWpe/cAAaHi0DGORorbDZfnff > agzNvl7Wl0/6HL09CXr2PHU6ZQGytSYbItVAjEHqLKhbYW4pLKviLYB84ZRiEc5N > 2ZA2ZE9VKWQRgu1kS25U4c5R7Zgy5oVAAIPLzNqEdcqu2dXSsZZeW4sJutwjioOL > Re: Question about thread's "keep alive time" value in Embed Tomcat 8.5 in Spring Boot 1.5 2019-11-01 Thread Christopher Schultz -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Roy, On 11/1/19 08:23, Roy Zhang wrote: > I am confused about "keep alive time" value in Embed Tomcat. I am > using Spring Boot 1.5, embed tomcat version is 8.5. > > According to > https://github.com/spring-projects/spring-boot/issues/16450#issuecomme nt-480236238, > > we can't configured thread's "keep alive time" via "maxIdleTime" > parameter, "keep alive time" value is hard coded as 60s via > https://github.com/apache/tomcat/blob/de1f55e672106031821948d5cac80f40 adc09513/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L884, It > is only hard-coded if you use the internal, default Executor. You can instantiate your own Executor with whatever settings you wish. It's a bad name for that setting, but this is how long "excess" threads will live when they are not being used. > I found 60s "keep alive time" sometimes take effect, some times it > doesn't take effect. Could u please kindly help to review my > following two cases and kindly provide explanation? Really > appreciate ur help in advance! > > *Case 1 (60s "keep alive time" DOESN'T take effect):* API latency: > _100ms_ Test step: run API with 800 concurrent threads for 1 > minutes, then run API with 10 concurrent threads for about 1 hour. > As we can see from following graph, after BusyThreads reduced from > ~800 to 10, CurrentThreadsCount remains at 800 for following 1 hour > (60s "keep alive time" DOESN'T take effect). After test stopped, > CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). > image.png Your images have been stripped from the mailing list. Find another way to describe your problem. When you say "X concurrent threads", how often are requests being made? Constantly? So you are sending requests as fast as possible with c=10? I haven't read the code in detail, but I'm guessing that the thread pool uses a queue and not a stack of threads, so each thread gets used, repeatedly, in order of availability. That means that if you keep making requests, you'll keep hitting *all* the threads in the queue and not just the same 10 over and over again. So they never time out. > *Case 2 (60s "keep alive time" DOES take effect):* API latency: > _10s_ Test step: run API with 800 concurrent threads for 1 minutes, > then run API with 10 concurrent threads for about 1 hour. As we can > see from following graph, after BusyThreads reduced from ~800 to > 10, CurrentThreadsCount reduced from 800 to 100(MinSpareThreads). > 60s "keep alive time" DOES take effect) Note that Tomcat's thread pool is just a wrapper around Java's ThreadPoolExecutor -- adding methods to handle Tomcat's lifecycle events, etc. So if the pool isn't behaving as you'd like it, you'll need to file a but against the Java API and not Tomcat. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl28NzYACgkQHPApP6U8 pFjcRxAApIe9WPrO43rIn+8TZ/KBncZbw2ZQr/nEew1pS7xdRFl2LVn/gMpuYaIe 78rF/3M9S0aYcG93vaqzn1+BZXW5EI9EINo+UG3E17ZYeD162Cpl2Q7aqaB/Te0j QR/JHIv31TAUpH39VLEpzfk/d1uct7oVZDq4P3kUjjAFwAo2G0useiHjokXtdIEm 3wXL1e8ChpvdP8RfrPdeATdGtEvGh0zNDW2Qjce+7R5LoC55UpHqJfB+p8BB6nV/ W6Jdp8CN8pVp+wROMMyK3HFvubFqSPcrKGURCmwKMH/QgRfRSTNpIfXYpubfOOqm EF0XxvRc2s/x6ZqRrfnbkunqqmb0h35SXPaWl1RJWpe/cAAaHi0DGORorbDZfnff agzNvl7Wl0/6HL09CXr2PHU6ZQGytSYbItVAjEHqLKhbYW4pLKviLYB84ZRiEc5N 2ZA2ZE9VKWQRgu1kS25U4c5R7Zgy5oVAAIPLzNqEdcqu2dXSsZZeW4sJutwjioOL pia5qqRcotdDPxATqv0Eo75cqvvgE5WeWZ/tMb2sVia85UPRL/cJCgrc/+HmYPmb JRzhobGhQ7WA33yqRfvBdcJ5HIGe2aU4o06VoAv6tHXPldjD4jQ/YHyyicP+bj6E wswEM7oIAIU8+R7JFp1Lhv6ZMuLlKohDmOu2bubhAgweSrAQ8jY= =901h -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: [OT] Re: Question about DirResourceSet? 2019-10-20 Thread Mark Thomas > Mark, > > On 10/16/19 04:41, Mark Thomas wrote: >>> On 10/15/19 09:37, Mark Thomas wrote: >>> Isn't there a magic ${property} that can be used to mean "the >>> context's root" so you don't have to use ${catalina.base} >>> instead? I browsed through the document a bit and didn't find >>> anything, but I could swear it's been discussed in the past. > >> There has been some discussion about exposing the context name via >> additional routes but I don't remember anything specific about the >> context root - apart from various discussions around getRealPath() >> and not being able to assume that any web app maps to a location on >> a file system. > > Right, getRealPath is the badness. > > But! Since all resource loading in Tomcat now goes through the > resources framework, perhaps "${context-root}" could use a proper > protocol that isn't "file:///" and point to the right place? Well, the server.xml parsing should accept URLs anywhere you can specify a file (assuming we've hooked up everything correctly) so you could probably have ${context-root} return the result of WebResourceRoot.getResource("/").getURL() However... That is only going to work *after* the web application has started but you need it *before* the app starts to use it in context.xml. I think this might end up being one of those cases where using ${catalina.base} is the better approach. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: [OT] Re: Question about DirResourceSet? 2019-10-16 Thread Christopher Schultz -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 10/16/19 04:41, Mark Thomas wrote: >> Mark, >> >> On 10/15/19 09:37, Mark Thomas wrote: >>> On 14/10/2019 20:29, André Warnier (tomcat) wrote: From a long-time (occasional) list contributor : That's a nice post, in many ways, and a good way to get quick and useful answers. I only regret that my own knowledge is not sufficient to provide such an answer. (We regularly complain at people posting to this list, when their post is "not nice", so I thought we should also from time to time give kudos when it is). >> >>> +1 >> On 14.10.2019 16:37, Robert Olofsson wrote: > Hi! > > Some background: We are currently running tomcat (9.0.26) > and we serve data to both html/webapp and to our java > application. The java application uses a lot of the same > jar files that our servlets use. > > We have had tomcat setup with two directories: 1) > webapps//WEB-INF/lib (as usual for servlet classes) > 2) webapps//clientdir/ (jar files for the java > application). > > This means that we have a lot of duplication of jar files > in these two directories. > > We would like to have the duplicate files in only one > place, sure disk space is cheap, but data transfer takes > time. We thought that having the jars in the clientdir > would be nice. > > We have read the documentation for tomcat and found the > resource handling and it looks like we could possibly use > something like: > > base="${catalina.base}/webapps//clientdir/" > className="org.apache.catalina.webresources.DirResourceSet" > > webAppMount="/WEB-INF/lib" /> > > We tested this lightly and things seems to work. > > Questions: Is there any problem with this? >> >>> Generally, no. You've done it in what I'd consider to be the >>> "safer" way by exposing all the JARs visible to the client to >>> the application's class loader rather than the other way >>> around. >> >> Isn't there a magic ${property} that can be used to mean "the >> context's root" so you don't have to use ${catalina.base} >> instead? I browsed through the document a bit and didn't find >> anything, but I could swear it's been discussed in the past. > > There has been some discussion about exposing the context name via > additional routes but I don't remember anything specific about the > context root - apart from various discussions around getRealPath() > and not being able to assume that any web app maps to a location on > a file system. Right, getRealPath is the badness. But! Since all resource loading in Tomcat now goes through the resources framework, perhaps "${context-root}" could use a proper protocol that isn't "file:///" and point to the right place? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2naqYACgkQHPApP6U8 pFgAXA//Z/IlqTRKyuXgBQUFB1UlnYesICkN+1IvLNYeo/ooNoxNpoBHw0Wkotkt KJ1R+QNrJ9U/kPZ7lLe0eng5fLtv2kuTX1ZhqyOuqCRTnb+Knl3I3EiZ7czgX1RK v+Y99EMCKg5aVXj1n9fB9Qha+WMD0JI729Qr0kPd7WPmhbLcLXts7/aqAAU1+7zs hZDUNB9eW+eV+f3nkA0mjJBzj18sLdNpvn1oxUwFr70YaZenXb7kIb2zueGVloOw X1378Yr3txvPb03T9mwcEZ5PyZ+NJgVvoL0HB5N+K67X1DiBGPolOWVw6lUjNQmt +nSEvrBz2jkVbl9MLVj9soGborgNZpFAE88T73qTj3Ky88uxgVn8gy4wQirynEEA ggBdjrybi2Ecl9gjgmrkY+EjFVndWFq0kykkLPPIAWalIGM0eDL+LXGpORRQ7VNx QQfPGmbSF6QahRBFx+wdxLziIT++QZJgZFQO49eWyID4okAaoW4U5ml4oHEj602i 0Ab1YXEuH8+tCiyklgIQYiU1bW2WW1281Lml9m399jTTKzaW/A4/ZpEM4Ak4Pj8q X6Sigo3AK7aBT7TrPpx/GHbkM53lA6pBYERp156iFCYecVOjwUNSWrtY8Z0gLnQi 6vriV9z8WWFD2FdZ3WDVS3FTpfJbE8jONZZugQbrIKN5yTj1Ves= =gSFg -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: [OT] Re: Question about DirResourceSet? 2019-10-16 Thread Mark Thomas > Mark, > > On 10/15/19 09:37, Mark Thomas wrote: >> On 14/10/2019 20:29, André Warnier (tomcat) wrote: >>> From a long-time (occasional) list contributor : That's a nice >>> post, in many ways, and a good way to get quick and useful >>> answers. I only regret that my own knowledge is not sufficient to >>> provide such an answer. (We regularly complain at people posting >>> to this list, when their post is "not nice", so I thought we >>> should also from time to time give kudos when it is). > >> +1 > >>> On 14.10.2019 16:37, Robert Olofsson wrote: Hi! Some background: We are currently running tomcat (9.0.26) and we serve data to both html/webapp and to our java application. The java application uses a lot of the same jar files that our servlets use. We have had tomcat setup with two directories: 1) webapps//WEB-INF/lib (as usual for servlet classes) 2) webapps//clientdir/ (jar files for the java application). This means that we have a lot of duplication of jar files in these two directories. We would like to have the duplicate files in only one place, sure disk space is cheap, but data transfer takes time. We thought that having the jars in the clientdir would be nice. We have read the documentation for tomcat and found the resource handling and it looks like we could possibly use something like: >>> base="${catalina.base}/webapps//clientdir/" className="org.apache.catalina.webresources.DirResourceSet" webAppMount="/WEB-INF/lib" /> We tested this lightly and things seems to work. Questions: Is there any problem with this? > >> Generally, no. You've done it in what I'd consider to be the >> "safer" way by exposing all the JARs visible to the client to the >> application's class loader rather than the other way around. > > Isn't there a magic ${property} that can be used to mean "the > context's root" so you don't have to use ${catalina.base} instead? I > browsed through the document a bit and didn't find anything, but I > could swear it's been discussed in the past. There has been some discussion about exposing the context name via additional routes but I don't remember anything specific about the context root - apart from various discussions around getRealPath() and not being able to assume that any web app maps to a location on a file system. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: [OT] Re: Question about DirResourceSet? 2019-10-15 Thread Christopher Schultz -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 10/15/19 09:37, Mark Thomas wrote: > On 14/10/2019 20:29, André Warnier (tomcat) wrote: >> From a long-time (occasional) list contributor : That's a nice >> post, in many ways, and a good way to get quick and useful >> answers. I only regret that my own knowledge is not sufficient to >> provide such an answer. (We regularly complain at people posting >> to this list, when their post is "not nice", so I thought we >> should also from time to time give kudos when it is). > > +1 > >> On 14.10.2019 16:37, Robert Olofsson wrote: >>> Hi! >>> >>> Some background: We are currently running tomcat (9.0.26) and >>> we serve data to both html/webapp and to our java application. >>> The java application uses a lot of the same jar files that our >>> servlets use. >>> >>> We have had tomcat setup with two directories: 1) >>> webapps//WEB-INF/lib (as usual for servlet classes) 2) >>> webapps//clientdir/ (jar files for the java >>> application). >>> >>> This means that we have a lot of duplication of jar files in >>> these two directories. >>> >>> We would like to have the duplicate files in only one place, >>> sure disk space is cheap, but data transfer takes time. We >>> thought that having the jars in the clientdir would be nice. >>> >>> We have read the documentation for tomcat and found the >>> resource handling and it looks like we could possibly use >>> something like: >>> >>> >> base="${catalina.base}/webapps//clientdir/" >>> className="org.apache.catalina.webresources.DirResourceSet" >>> webAppMount="/WEB-INF/lib" /> >>> >>> We tested this lightly and things seems to work. >>> >>> Questions: Is there any problem with this? > > Generally, no. You've done it in what I'd consider to be the > "safer" way by exposing all the JARs visible to the client to the > application's class loader rather than the other way around. Isn't there a magic ${property} that can be used to mean "the context's root" so you don't have to use ${catalina.base} instead? I browsed through the document a bit and didn't find anything, but I could swear it's been discussed in the past. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2mGvYACgkQHPApP6U8 pFgdjg/9GKn1rTf5hXozVinl6tiVD9RJGi9mC/+zzLtUJOsb2/LNGsjd7CcVNP/S IgnlbQun9SQtyK8mSd3cQXwenrKY5mkFta12cgc1FMuuLBT3m74WPWcv+OLo1HKd +yTgkSak9i4U+zV4sP/RfusKW3FgYU9UJRIE/I/wWXt6fSrc7pEtH12qdH9gauH2 itvo4XtJNsNq3RADqdf79vz/oL5+90n3OB29/L7ocO5p8tEiHF1W95Mt1hVwo0Re rYi5Rv8MesTkw35K2GYWFzV9TndiOGiI7uH3GW8Y/7wXoNecXmL4XuFLiNUsTXhI XRrLsLl6qwxagan627Q1TW7SMMfsu7h3M1you1qe/wB8PB3MIZ6mvAbyIFKXxw2j zt0iuYWsZppM6ZKU4nr8//Q+icDLgJIHwKxk/OlpLNahmThmSn4bml9IML3R7m0H TWMezbuL4QPSTMhMywKVAdMH5IMQe3jO1pXVsrgJmAj6YaCqQy87rilYf+5xGpRo pTtgOYV/pKk/YCTAB88O4EkgMwbwhFxa2mbsYIX12RCWm5EevmacBQ6cv5oZdTDS mVIRWeMUxDjCM1tHLIMFv2/xDo+BINiVmWLEpvuqddsO65399xERdTDMqeRJehSm lg0sIlrne8ankbkGPxIi5iRLqCt4dVID86kkehEZov8xM2px6iU= =Mbci -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: [OT] Re: Question about DirResourceSet? 2019-10-15 Thread Robert Olofsson Hi! On Tue, 2019-10-15 at 14:37 +0100, Mark Thomas wrote: > Generally, no. You've done it in what I'd consider to be the "safer" way > by exposing all the JARs visible to the client to the application's > class loader rather than the other way around. Ok, good to hear, we will try this and see how things work out. I am happy to hear that you reflected about security and as far as I know we do not have any upload into the web app (and I ought to know if we do :-). Security was one of the main reason for my questions. > another option would be to use a ServletContextListener to copy the > files... Sure, but just pointing out another directory is a lot easier. Thanks a lot. /robo - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: [OT] Re: Question about DirResourceSet? 2019-10-15 Thread Mark Thomas On 14/10/2019 20:29, André Warnier (tomcat) wrote: > From a long-time (occasional) list contributor : > That's a nice post, in many ways, and a good way to get quick and useful > answers. > I only regret that my own knowledge is not sufficient to provide such an > answer. > (We regularly complain at people posting to this list, when their post > is "not nice", so I thought we should also from time to time give kudos > when it is). +1 > On 14.10.2019 16:37, Robert Olofsson wrote: >> Hi! >> >> Some background: >> We are currently running tomcat (9.0.26) and we serve data to >> both html/webapp and to our java application. The java application >> uses a lot of the same jar files that our servlets use. >> >> We have had tomcat setup with two directories: >> 1) webapps//WEB-INF/lib (as usual for servlet classes) >> 2) webapps//clientdir/ (jar files for the java application). >> >> This means that we have a lot of duplication of jar files in these two >> directories. >> >> We would like to have the duplicate files in only one place, sure >> disk space is cheap, but data transfer takes time. We thought that >> having the jars in the clientdir would be nice. >> >> We have read the documentation for tomcat and found the resource handling >> and it looks like we could possibly use something like: >> >> >> > className="org.apache.catalina.webresources.DirResourceSet" >> webAppMount="/WEB-INF/lib" /> >> >> >> We tested this lightly and things seems to work. >> >> Questions: >> Is there any problem with this? Generally, no. You've done it in what I'd consider to be the "safer" way by exposing all the JARs visible to the client to the application's class loader rather than the other way around. If applications can upload files then, depending on how that is configured, you might have opened a remote code execution vulnerability. But then, if clients can upload arbitrary files into the web app you likely have an RCE issue anyway (via an uploaded JSP) irrespective of how you handle JARs. >> If so, do you know of any better way to accomplish this? Depending on how early the classes in those JARs might be required, another option would be to use a ServletContextListener to copy the files from the app to the WEB-INF/lib directory. That would, arguably, be safer. You could specify exactly which files to copy and, for extra security if required, validate the JAR signature (if signed) or SHA512 hash, etc. before copying. To be honest, I'm struggling to think of a scenario where this would be necessary. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org [OT] Re: Question about DirResourceSet? 2019-10-14 Thread tomcat From a long-time (occasional) list contributor : That's a nice post, in many ways, and a good way to get quick and useful answers. I only regret that my own knowledge is not sufficient to provide such an answer. (We regularly complain at people posting to this list, when their post is "not nice", so I thought we should also from time to time give kudos when it is). On 14.10.2019 16:37, Robert Olofsson wrote: Hi! Some background: We are currently running tomcat (9.0.26) and we serve data to both html/webapp and to our java application. The java application uses a lot of the same jar files that our servlets use. We have had tomcat setup with two directories: 1) webapps//WEB-INF/lib (as usual for servlet classes) 2) webapps//clientdir/ (jar files for the java application). This means that we have a lot of duplication of jar files in these two directories. We would like to have the duplicate files in only one place, sure disk space is cheap, but data transfer takes time. We thought that having the jars in the clientdir would be nice. We have read the documentation for tomcat and found the resource handling and it looks like we could possibly use something like: We tested this lightly and things seems to work. Questions: Is there any problem with this? If so, do you know of any better way to accomplish this? Thanks /robo - 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: Question regarding changelog in 8.5.46 2019-10-02 Thread Mark Thomas On 02/10/2019 16:16, M. Manna wrote: > Hello, > > http://tomcat.apache.org/tomcat-8.5-doc/changelog.html#Tomcat_8.5.46_(markt) > > > I am just trying to understand if these changes have any impact on 8.5.45 > with CPU usage. It seems to be some potential NPE and (HTTP/2 only) hanging > issues. > > We are seeing some CPU spikes with 8.5.45 and these changes don't seem to > be directly responsible for fixing the issues. So, just trying to eliminate > the need for jumping to another upgrade. The only way you'll be able to tell what is causing those CPU spikes is with a profiler. Once you know that, then we might be able to help by suggesting mitigations. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Re: Question regarding tomcat random number seeding and startup times 2019-07-28 Thread John Dale I changed securerandom.source=file:/dev/random in /jre/lib/security/java.security, changing this to urandom and it vastly improved things. My question is, what will this do? I don't really rely on the tomcat generated session affinity .. On 7/28/19, John Dale wrote: > Greetings; > > I found this in the logs where it's hanging-up: > > 28-Jul-2019 19:05:10.520 WARNING [main] > org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom > Creation of SecureRandom instance for session ID generation using > [SHA1PRNG] took [212,424] milliseconds. > > Thoughts? > > John > > > On 7/27/19, Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> John, >> >> On 7/27/19 19:49, John Dale wrote: >>> Greetings Everyone; >>> >>> A quick update to the folks who I have interacted with on the list >>> (you know who you are and I thank you). >>> >>> I got all of my applications and sites migrated from Tomcat 7.x.x >>> to Tomcat 9.x running on Ubuntu 18.04 and Java 8. Lots of fun work >>> with the firewalls, databases, and email servers (DKIM, SPF, and >>> DMARC are something else). >>> >>> Overall, I was kind of disappointed to find out that Java 11 >>> doesn't include activation and jax libs, but it sure was fast once >>> I included these things in my lib folder. That said, I thought it >>> might be better to revert to Java 8, which bundles and unit tests >>> these libraries. So, that's what I did. >>> >>> But yikes .. the startup times are now very slow .. sometimes two >>> minutes. I understand that this might relate to the need of the >>> JVM to initialize for random number seeding. Is this true? >> >> What makes you say that? It might be correct, but you are just >> providing a guess, here. >> >>> What other strategies should I be looking at to make the bounce >>> more zippy? I deploy two smallish war files (<5MB, about 160KB >>> Java Services code) >> >> Note that the size of the code is largely irrelevant. >> >>> I noticed several recommendations for different random number >>> seeding strategies, but they came with warnings relative to the >>> quality of encryption. What else might be done that doesn't >>> compromise encryption quality? >> >> Most modern JVMs (on Linux) use /dev/urandom as a source of entropy by >> default which is safe enough to use for probably everything but >> long-loved encryption keys (e.g. multi-year-valid RSA/EC keys, PGP >> keys, etc.). You probably shouldn't be generating long-lived keys of >> these kinds from within a Tomcat-hosted application. /dev/urandom is >> non-blocking so it shouldn't stall when grabbing entropy for things >> like random-number seeding (which are used by Tomcat for both random >> session-id generation and random TLS bulk-encryption keys. >> >>> I would like to push back my Java 11 upgrade until I have a good >>> longer term strategy for jax and activation libraries. Thoughts? >> >> Why not simply bundle those required libraries with your application? >> >>> Glad to have made it through the upgrade .. it really wasn't very >>> painful at all. >> >> Glad to hear it wasn't painful. >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ >> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl09KVgACgkQHPApP6U8 >> pFhPew/+JpMBI7y27lkZdvD61QoWWVYQm4VrsVu9iCGMSSznSPdVSROgvupjtF1Z >> QCuTRLTOGdxWC1RuNMg47chtUiRtUnS/dIaCscN9AYSzqKvyGkGdW97S0cdTZnHy >> plSRqsep4RkoseyFPBrLHRy3FU8po8Bt+2L3btCSwVK6pcp4GNVkywqF9/gkAJVp >> uAL5Pyy57SY84sdHyCxxYeo9iO3Jtg3UVVQzGJzaFJ3bhCQcQO/50CNbsTMutGYJ >> sJFOAWL6vQhnojIH2PAm6fqQ2e0XF+RmZh5Kf0+Jsl3VjBxw1C5wzyixcK9NvKxq >> vdxG2Cs9YGpYiLLmF5Diz0JU7rTWfz/A0jalNt8Fr6y2HS65rFSlWsTsjlmjpl14 >> b1hEw/o+vtRwJ3e+HEbTelnOXzaZU4HhlaiDkd43EcWOUyicvlEuAToQHMou5N68 >> uKjP5/AdrDvGuSdAxCRrnAmAsOP4P0XMXoG9n6tHoTRy6L+3eh01h931lsFlxlYy >> dOly8rOzDwE80x5BzugDw9I9Rotg0U0mGzogNzs9thG/1rrBzdUdWNDcWvJLaEkT >> joKGlScnB/gEisV2NT2DEB4E8q9kf6BoypSVMhzOTQ9KDnIq6cau7dtfXWwusODt >> St7SCCJtAsxMtici5HihZvuf+CDVpuZ5+PD3KWSuFjSxrwrl1Es= >> =Qhtz >> -END PGP SIGNATURE- >> >> - >> 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 1 2 3 4 5 6 7 8 9 10 >

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 920 matches

Mail list logo