from:"Mark Thomas"

Re: Errors after upgrading to Tomcat 9.0.90

2024-06-20 Thread Mark Thomas

That looks like an issue accessing a request/response after the 
request/response has been completed.


Possibly surfaced by this entry from the change log:

The system property org.apache.catalina.connector.RECYCLE_FACADES will 
now default to true if not specified, which will in turn set the default 
value for the discardFacades connector attribute, thus causing facade 
objects to be discarded by default. (remm)


You could try explicitly setting discardFacades to false.

Mark


On 20/06/2024 11:25, Francesco Chicchiriccò wrote:

Hi there,
at Syncope we usually use the latest Tomcat versions to run a large 
chunk of our integration tests.


In our master branch we relay on Tomcat 10.1.x, and upgrading to 10.1.25 
from 10.1.24 went smooth as usual.


In our 3_0_X branch we relay on Tomcat 9.0.x; with 9.0.89 everything 
goes as expected, but with 9.0.90 we are getting the exception [1].


Any idea of what could be changed in 9.0.90 within this regard? Thank you.

Regards.


[1] https://gist.github.com/ilgrosso/be1fb1f2ea205eef60fb221973f87b34



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

Re: Configuration of Certificate Verification on Tomcat 10

2024-06-19 Thread Mark Thomas

On 18/06/2024 23:30, Christopher Schultz wrote:

Izek,

On 6/18/24 13:49, Izek Hornbeck wrote:

I am creating a Java web app (Java v17, 2021-09-14) that runs on a Tomcat
10.1.23 server. I need to authenticate users by verifying their
certificate

from a smart card. (This Stack Overflow question I posted gives some good
context: "
https://stackoverflow.com/questions/78387597/what-is-the-standard-modern-way-to-use-cac-piv-card-authentication-in-java-tomca
".)

Through all the research I have done, the best way to solve this is by
using the server configuration in "server.xml". I am very new to Tomcat,
but I will try to explain everything as best as I can.

This authentication must occur after the user has entered their
credentials, so I'm thinking the best way is to redirect the user to a
new

port (e.g., from 8443 to 8444) with the appropriate settings. And some
users will not be required to authenticate with a smart card
certificate. I

asked another question on Stack Overflow ("
https://stackoverflow.com/questions/78624062/how-to-get-the-popup-menu-to-select-user-certificate-in-tomcat-10-server;)
that describes more of the things that I have tried specific to the
server

config.

I added the command "-Djavax.net.debug=ssl" to see more details about
what

was happening during the SSL handshake; I get the following:
- javax.net.ssl|ALL|F3|https-jsse-nio-8444-exec-6|2024-06-18
10:25:02.564

According to some sources (like "
https://stackoverflow.com/a/11803823/1587;) this happens because some
certificates have not yet been added to the keystore/truststore. I have
ensured that the test client certificates and the server certificate have
been successfully added to the stores.

The two major questions I have are these:
1) How can I get the popup menu for the user to select their
certificate
and enter the smart cards pin? (Both to set up their account and for
later

logins.)
2) How do I configure my server to accept the clients' certificates?

Let me know what more information would be useful.

Starting from your SO post:

> protocol="org.apache.coyote.http11.Http11NioProtocol"
> port="8444" maxThreads="150" SSLEnabled="true"
> maxParameterCount="1000" secure="true" scheme="https" >
>
> sslProtocol="TLSv1.2"
> certificateVerification="true"

You don't actually want certificateVerification="true" here, unless you
want every single connection to require a certificate to be presented.
Since you mentioned you need to be able to support "sign up" and also
first request some other kind of authentication (username/password?) and
also some resources without client-certs, this setting *must* be set to
something else.

I suspect you want clientAuth="false" which is counterintuitive, but it
means that the web application gets to set the policy for if/when client
certs are requested.

That means that your WEB-INF/web.xml file needs to declare one or more
web-resource-collection elements as requiring CLIENT-CERT authentication.

I *think* that if you have clientAuth="false" you will get the behavior
you want, but you are going to have to set up some places in your
application where client certs are required versus not-required. Since
you are building a new application and not trying to retrofit an old
one, this may be relatively easy. Here's my recommendation:

This won't work. You can only have 1 authentication mechanism per web
application. You might need to split functionality between multiple web
applications.

Mark

1. Unauthenticated web-resource-collection

This basically has your login informational resources that never require
any authentication in order to view. That includes images, CSS, etc. No
need to define any authentication constraints.

2. Semi-authenticated web-resource-collection

This is only accessible to users who have successfully logged-in using
your "easy" criteria such as username+password. Probably also any pages
you need to display that say "okay, now you need to register your client
certificate with your account" or whatever.

For this, you must set the user-roles you will allow to view these
resources. You can use any combination of roles (I recommend "*"),
because unauthenticated users have no roles. You can probably use "FORM"
as the authentication type if you are using e.g. username+password.

3. Fully-protected web-resource-collection

These resources are only accessible using a client certificate. After
registration, or after you have determined that a user must use

[ANN] Apache Tomcat 11.0.0-M21 (beta) available

2024-06-18 Thread Mark Thomas


The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M21 (beta).

Apache Tomcat 11 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M21 is a milestone release of the 11.0.x branch and
has been made to provide users with early access to the new features in
Apache Tomcat 11.0.x so that they may provide feedback. The notable
changes compared to 11.0.0-M20 include:

- Ensure that static resources deployed via a JAR file remain accessible
  when the context is configured to use a bloom filter. Based on a pull
  request provided by bergander.

- Add task queue size configuration on the Connector element, similar to
  the Executor element, for consistency.

- Update to Commons Daemon 1.4.0

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-11.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-11.cgi

Migration guides from Apache Tomcat 8.5.x, 9.0.x and 10.1.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

Re: A curious case of Tomcat 10.1.x NIO(1) acceptor not stopping clearly on some setups

2024-06-14 Thread Mark Thomas

Just to follow up on this.

I tripped over a related issue today running the Tomcat unit tests for
9.0.x. Being able to reproduce it gave me a chance to dig further and
come up with a better fix. These interfaces are marked as "point to
point" interfaces which Java can see so we can skip them. I've updated
the unlock code and the fix will be in the July release round.

Mark

On 26/02/2024 15:59, Michał Szymborski wrote:
Thank you, that clears things up. I did not think about implication of
using wildcard. I will try to use explicit addresses from now on. You
learn something new every day!

Cheers,
Michał

On 26.02.2024 09:48, Mark Thomas wrote:

On 25/02/2024 18:18, Michał Szymborski wrote:

On quick inspection the acceptor thread
(https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/Acceptor.java#L128) was listening on [/[0:0:0:0:0:0:0:0]:39033]
, which was correctly picked up at first, but then this local address
got transformed:

0.0.0.0 is shorthand for "all configured IP address". Tomcat can't use
that address to establish a connection to the Acceptor thread so it
has to try and deduce a valid IP local address from the network
configuration information exposed through the Java APIs.

https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L1164

It started picking up interfaces to use, and it stopped at the first
non-loopback non-link local address, which also happens to be some
sort of a bridge network for one of my VMs. I don't quite know why
there is no routing set up, but this interface should not have been
picked in the first place.

It is a local IP address so as far as Tomcat can see it should be
valid to connect to the Acceptor.

I'll take a look at how it works on my work laptop with MacOs, but
I'd wager a guess that some corporate VPNs have interfaces which have
messed up routing as well. Can't tell if it's a bug or a feature, but
it sure is unexpected. Making this timeout for acceptor shutdown
configurable would be one sort of band-aid.

It is configurable. socket.unlockTimeout. Documented default is 250ms
although looking at the code it appears there is a minimum of 2000ms -
need to see why that is.

Configuring a specific address (even 127.0.0.1) for the Connector
would also address this.

Mark

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

Re: EOL of servelet-api

2024-06-12 Thread Mark Thomas


On 12/06/2024 10:54, Madhu Mitha (EXT-Nokia) wrote:

Hi,

I'm currently using Apache Tomcat 9.0.86, in my component(JOMA) that runs in 
RHEL 8.6.
Customer has triggered security scan and found servlet-api.jar has reached EOL 
in 2018 and the recommendation is to migrate to Jakarta-servelet-api.jar.


You need to get a better security scanner. That statement is nonsense 
for Tomcat 9. The servlet-api.jar provided with Tomcat 9.0.x is 
currently supported and will continue to be supported for as long as 
Tomcat 9.0.x is supported.



So, when can we expect the changes from Tomcat. Unless or until you change 
this, I cannot deploy in my component.


If you had bothered to do even a minimal amount of research you would 
know that Tomcat 10.x is already available (and has been for over 3.5 
years) with Jakarta EE support.



Please reply with the timeline on the availability of this, or any alternate 
way to mitigate this.


See above.

Mark

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

Re: Mysterious websocket disconnection--no logs

2024-06-11 Thread Mark Thomas


On 09/06/2024 01:08, Flaviu Tamas wrote:

I'm writing some tests for my Spring Boot application, which uses
tomcat-embed-websocket-10.1.18. When I send a message to the socket
from handleVideoFrame, all I see is

.WebSocketAnnotationMethodMessageHandler : Invoking
VideoStreamController#handleVideoFrame[3 args]
o.s.w.s.m.SubProtocolWebSocketHandler: Clearing session
3b7fc290-eeb3-a86c-a465-8826819f3bde

I can turn debug logging on for org.apache.tomcat.websocket.WsSession,
which give me a bit more detail, but this is detail that the
application user is unlikely to care about (some sort of internal ID
that I don't think is exposed anywhere else)

.WebSocketAnnotationMethodMessageHandler : Invoking
VideoStreamController#handleVideoFrame[3 args]
org.apache.tomcat.websocket.WsSession: Closing WebSocket session [3]
o.s.w.s.m.SubProtocolWebSocketHandler: Clearing session
a77dcddd-877e-1d5a-8dd2-daf3f38395f7

This is especially frustrating because this log line has complete
context. If I place a breakpoint in WsSession.doClose, I can see that
the error is "The decoded text message was too big for the output
buffer and the endpoint does not support partial messages", which does
help me solve my problem.

It would be nice if this message was exposed to the user, either by
default, or at the very least in the debug logs.


The message is sent to the user/client as part of the WebSocket close 
message. If the client doesn't expose that to the user, there isn't much 
Tomcat can do.


Mark

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

Re: Side effect of Tomcat 10.1.20 with Freemarker

2024-06-11 Thread Mark Thomas


On 11/06/2024 12:30, Mark Thomas wrote:



I need to confirm that it doesn't break the original fix but my plan is 
to check clazz after line 2311 and rethrow the original exception if it 
is null.


Testing with the original reproducer looks good.

Fixed in:
- 11.0.x for 11.0.0-M21 onwards
- 10.1.x for 10.1.25 onwards
-  9.0.x for  9.0.90 onwards

Mark

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

Re: Side effect of Tomcat 10.1.20 with Freemarker

2024-06-11 Thread Mark Thomas


On 07/06/2024 09:04, Jeroen Hoffman wrote:


On 06-Jun-24 18:17, Mark Thomas wrote:

On 06/06/2024 11:01, Jeroen Hoffman wrote:

Hi all,

We've found a side effect of change #68721 [1] in Tomcat 10.1.20 that 
we'd like to notify you about.


We're using Apache Freemarker for back-end templating, and its 
NodeModel class uses reflection to determine what classes to use for 
xpath, thereby catching IllegalAccessError, see [2].


Per change #68721 a IllegalAccessError is caught as LinkageError and 
turned into a Throwable, NoClassDefFoundError in our case, see [3], 
and then falls through that block in NodeModel and errors out.


So this change in Tomcat alters the behaviour in Freemarker, which I 
assume was unexpected. We can (and must) work around it, preventing 
the IllegalAccessError, but still, maybe you'd like to improve again 
or have other thoughts?


How are you getting from the original IllegalAccessError to a 
NoClassDefFoundError? Tomcat should re-throw the original 
IllegalAccessError.


Small correction from my side: WebappClassLoaderBase throws a 
ClassNotFoundException (not NoClassDefFoundError) at the end of 
#loadClass (line 1353).


It's not re-throwing the original IllegalAccessError because the call to 
#findLoadedClass0(name) at line 2361 is NOT throwing anything, just 
returns null and then the ClassNotFoundException is thrown.


This specific case is about an anonymous inner class that implements 
PrefixResolver from the java.xml module, see 
https://github.com/apache/freemarker/blob/2.3/freemarker-core/src/main/java/freemarker/ext/dom/SunInternalXalanXPathSupport.java


Got it. Thanks for the explanation.

I need to confirm that it doesn't break the original fix but my plan is 
to check clazz after line 2311 and rethrow the original exception if it 
is null.


Mark

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

Re: Embedded Tomcat common classloader

2024-06-06 Thread Mark Thomas


On 06/06/2024 18:48, Dave Breeze wrote:

Thanks Mark
appreciate that the url was for 8.0

With regards to classpath that was my first attempt - unfortunately it
would seem that Tomcat does not support wildcards in the classpath -
for example dirpath/lib/*.jar - at least in version 9.


The requirements for setting the class path are set by the JVM, not by 
Tomcat. If you want all the JARs in a directory to be included in the 
class path then you should add dirpath/lib/* to the class path.


Mark





Dave Breeze
Linkedin:https://uk.linkedin.com/in/dabreeze

On Thu, 6 Jun 2024 at 17:23, Mark Thomas  wrote:


On 06/06/2024 17:52, Dave Breeze wrote:

   I have an issue with embedded Tomcat and classloaders.

I have a java servlet application that runs in an embedded
Tomcat(9.0.70) instance.





https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html


Those are the Tomcat 8.0.x docs. You are using Tomcat 9.0.x.

Tomcat embedded does not set up the class loader structure you get with
a standard Tomcat instance. Tomcat just uses the classpath.

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: Embedded Tomcat common classloader

2024-06-06 Thread Mark Thomas


On 06/06/2024 17:52, Dave Breeze wrote:

  I have an issue with embedded Tomcat and classloaders.

I have a java servlet application that runs in an embedded
Tomcat(9.0.70) instance.





https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html


Those are the Tomcat 8.0.x docs. You are using Tomcat 9.0.x.

Tomcat embedded does not set up the class loader structure you get with 
a standard Tomcat instance. Tomcat just uses the classpath.


Mark

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

Re: Side effect of Tomcat 10.1.20 with Freemarker

2024-06-06 Thread Mark Thomas


On 06/06/2024 11:01, Jeroen Hoffman wrote:

Hi all,

We've found a side effect of change #68721 [1] in Tomcat 10.1.20 that 
we'd like to notify you about.


We're using Apache Freemarker for back-end templating, and its NodeModel 
class uses reflection to determine what classes to use for xpath, 
thereby catching IllegalAccessError, see [2].


Per change #68721 a IllegalAccessError is caught as LinkageError and 
turned into a Throwable, NoClassDefFoundError in our case, see [3], and 
then falls through that block in NodeModel and errors out.


So this change in Tomcat alters the behaviour in Freemarker, which I 
assume was unexpected. We can (and must) work around it, preventing the 
IllegalAccessError, but still, maybe you'd like to improve again or have 
other thoughts?


How are you getting from the original IllegalAccessError to a 
NoClassDefFoundError? Tomcat should re-throw the original 
IllegalAccessError.


Mark

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

Re: Invalid character found in the request target

2024-06-05 Thread Mark Thomas


On 04/06/2024 15:37, Christopher Schultz wrote:

On 6/4/24 09:10, Chuck Caldarale wrote:





The problem is the { and } characters.

My reading of RFC 7230 is that { and } /should/ be allowed, but 
Tomcat's code rejects them by default.


My reading is as follows:

RFC 9110:

http-URI = "http" "://" authority path-abempty [ "?" query ]

RFC 3968:

path-abempty  = *( "/" segment )
segment   = *pchar
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
  / "*" / "+" / "," / ";" / "="

Neither '{' nor '}' are included in unreserved or sub-delims The are not 
pct-encoded. Nor are they ':' or '@'. Therefore, there are not valid for 
use in a segment. If you want to use them, they need to be pct-encoded.


While some of the text of RFC 3968, section 2.3 could be read as 
suggesting other characters are included in unreserved, my reading of 
that section is that the intended definition of unreserved is the 
explicit definition I quoted above.


Mark

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

Re: Tomcat 9.0.xx JDK Version Support and EOL

2024-06-05 Thread Mark Thomas


On 05/06/2024 15:11, Chaitanya Gopisetti wrote:

Also can you update on the End of life expected date for Tomcat 9.0.x version


Best guess (based on the next major release being in ~3 years time) 
right now is 31 March 2027 for 9.0.x noting that a 9.10.x will follow to 
retain supoprt for the Java EE APIs.


We will provide at least 12 months notice of any offical EOL date for 9.0.x.

We expect to support 9.x for an extended period of time.

When 10.x reaches EOL so will 9.10.x and then we'll have 9.11.x and so on.

Mark



-Original Message-
From: Christopher Schultz 
Sent: Wednesday, June 5, 2024 6:37 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.xx JDK Version Support and EOL

Chaitanya,

On 6/5/24 08:47, Chaitanya Gopisetti wrote:

It was mentioned that Tomcat 9.0.x supports java 8 and later. So
wanted to know whether it supports Jdk 21? Also wanted to know the End
of life expected date for Tomcat 9.0.x version.


Tomcat 9 should run jut fine on any Java version from 8 up through the latest 
release (currently Java 21).

-chris

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


To the extent permitted by law, we may monitor electronic communications for 
the purposes of ensuring compliance with our legal and regulatory obligations 
and internal policies. We may also collect email traffic headers for analyzing 
patterns of network traffic and managing client relationships. For additional 
information see https://blueyonder.com/privacy-policy.

-
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: Webapp Getting redirected to an external IP Address

2024-06-03 Thread Mark Thomas


On 04/06/2024 05:07, Tom Robinson wrote:

Hi,

We are running a tomcat7 application


You do realise that support for Tomcat 7 ended on 31 March 2021 don't you?


on our LAN which gets redirected from
a private, internal IP Address to an external ip address at which point it
fails. I can't find where this is happening.


Is it an actual redirect - i.e. a 30x response? Or do you mean something 
else?


If a redirect, does it redirect on the first request?


Where and what can I check for this redirect and how to control it or
switch it off all together.


Tomcat doesn't do this by default.

Tomcat 7 doesn't have the redirect valve so it won't be that.

Are you sure that the redirect is being issued by Tomcat? Might there be 
a reverse proxy in mix somewhere?


Other than that, it would have to be in the application code somewhere.



I browse to here on our LAN:

https://myinternalhost.mydomain.com.au:8443


Check what myinternalhost.mydomain.com.au resolves to in terms of an IP 
address.


Try requesting a page that won't trigger a directory redirect. Something 
like:


https://myinternalhost.mydomain.com.au:8443/index.html

You may need to adjust that for your application.

Mark



I end up here:

https://a.b.c.d:8443/kb

Where a.b.c.d is our external, ISP provided IP Address.

Why is this happening and how can I fix it?

*Kind regards,*

*Tom Robinson*
*IT Manager/System Administrator*



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

Re: Cannot invoke "org.apache.tomcat.util.net.SSLHostConfig.getProtocols()" because "this.sslHostConfig" is null

2024-06-03 Thread Mark Thomas


On 03/06/2024 09:16, Adam Danischewski wrote:


Not sure why I'm getting:

Caused by: java.lang.NullPointerException: Cannot invoke
"org.apache.tomcat.util.net.SSLHostConfig.getProtocols()" because
"this.sslHostConfig" is null


You haven't configured a default SSLHostConfig.

Either use "_default_" for the host name of the SSLHostConfig you have 
defined or call setDefaultSSLHostConfigName("localhost") on the endpoint.


Mark

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

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-05-31 Thread Mark Thomas


On 31/05/2024 16:09, Eric Robinson wrote:

The results are looking great so far.


Excellent.


Here's what we know:

Before the patch, we had 2 load-balanced tomcats in production for this 
customer. Due to the driver search bottleneck, we were seeing hundreds of stuck 
threads during the slowdown periods. To work around this problem, we threw more 
tomcats at it. With 6 tomcats, the load was spread around enough to keep the 
bottleneck condition from manifesting badly, and users did not complain as 
much. We were still seeing dozens of stuck threads, but not hundreds.

After the patch, we went back to 2 tomcats.


I appreciate the show of faith! I think that is braver than I would have 
been but it does rather confirm both the problem and the fix.



During the same timeframe today, there have been 1 stuck thread on Tomcat A and 
6 on Tomcat B.


That is great news.


If the numbers hold, this works out to roughly a 10,000% improvement.


Not bad for free support ;)

Seriously, I am glad that we seem to have tracked down the root cause 
and that you have a temporary fix that works until such time (probably 
the July releases) that we can figure out how we want to address caching 
of "not found" classes.


Cheers,

Mark

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

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-05-30 Thread Mark Thomas


OK.

This is an interim binary patch for 9.0.80 only.

The purpose is to:
- confirm the proposed change fixes the problem
- provide you with a workaround in the short term

This is the binary patch:

https://people.apache.org/~markt/dev/classloader-not-found-cache-9.0.80-v1.zip

Extract the contents into $CATALINA_HOME/lib

You should end up with:

$CATALINA_HOME/lib/org/apache/...

Usual caveats apply. This is not an official release. Use it at your own 
risk. Don't blame either me or the ASF it is results in alien invasion, 
a tax bill, the server catching fire or anything else unexpected and/or 
unwanted.


Longer term, I'm not sure this is exactly how I want to fix it in 
Tomcat. I am convinced of the need to cache classes that don't exist but 
exactly where / how to do that and what degree of control the user 
should have is very much TBD.


I suspect this will be a topic of discussion at Community Over Code at 
Bratislava next week.


I am expecting that any fix won't be in the June release round but 
should be in the July release round.


Let us know how you get on and good luck.

Mark


On 30/05/2024 10:16, Mark Thomas wrote:

On 29/05/2024 17:03, Eric Robinson wrote:



One of the webapps is related to voice reminder messages that go out 
to people. The reminders go out sometime after 9 am, which tracks with 
the slowdowns.


Ack.

Something to try while I work on a patch is setting 
archiveIndexStrategy="bloom" on the resources.


You'd configure that in META-INF/context.xml something like this:


   


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: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-05-30 Thread Mark Thomas


On 29/05/2024 17:03, Eric Robinson wrote:




One of the webapps is related to voice reminder messages that go out to people. 
The reminders go out sometime after 9 am, which tracks with the slowdowns.


Ack.

Something to try while I work on a patch is setting 
archiveIndexStrategy="bloom" on the resources.


You'd configure that in META-INF/context.xml something like this:


  


Mark

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

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-05-29 Thread Mark Thomas


On 29/05/2024 16:08, Eric Robinson wrote:


I believe your assessment is correct. How hard is it to enable pooling? Can it 
be bolted on, so to speak, through changes to the app context, such that the 
webapp itself does not necessarily need to implement special code?


It looks like - from the database configuration you provided earlier - 
there is an option to configure the database via JNDI. If you do that 
with Tomcat you will automatically get pooling. That might be something 
to follow up with the vendor. If you go that route, I'd recommend 
configuring the pool to remove abandoned connections to avoid any issues 
with connection leaks.


Not sure if all the web applications support a JNDI based configuration.




Would the problem be relieved if the vendor stuck to one driver?


Yes. That would avoid the attempt to load the "other" driver which is 
causing the delay.


Mark

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

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-05-29 Thread Mark Thomas


On 29/05/2024 13:38, Eric Robinson wrote:

-Original Message-
From: Mark Thomas 





I intend to wok on a patch for Tomcat that will add caching that should
speed things up considerably. I hope to have something for Eric to test
today but it might take me until tomorrow as I have a few other time
critical things fighting to get tot he top of my TODO list at the moment.


Moving the JDBC driver JARs from WEB-INF/lib to $CATALINA_BASE/lib may
also be a short-term fix but is likely to create problems if the same
JAR ever exists in both locations at the same time.


Just an FYI. On further reflection, moving the JDBC driver JARs isn't 
going to help. Sorry. You'll need my fix.


Assuming, of course, you are willing to test a patch to address this on 
a production system.



That's some great sleuthing and the explanation makes a ton of sense. It leaves 
me with a couple of questions.

If you are correct, then it follows that historic activity has been hovering 
dangerously near the threshold where this symptom would manifest. Within the 
past month, an unknown change in the system climate now causes an uptick in the 
number of DB requests/second at roughly the same time daily (with occasional 
exceptions) and the system begins to trip over its own feet. I haven't seen 
anything in my Zabbix graphs that stood out as potentially problematic. Armed 
with this information, I am now taking a closer look.


Ack.


The natural next question is, what changed in the application or the users' 
workflow to push activity over the threshold? We'll dig into that.


Could be all sorts of things.

It might just have been coincidence the first time and now the users all 
request the data they need at the start of their day in case the problem 
happens again. And by doing that they cause the very problem they are 
trying to avoid.


Mark

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

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-05-29 Thread Mark Thomas


On 29/05/2024 10:26, Mark Thomas wrote:

On 28/05/2024 16:26, Eric Robinson wrote:



Took a bunch of thread and heap dumps during today's painful debacle. 
Will send a link to those as soon as I can.


Thanks. I have them. I have taken a look and I am starting to form a 
theory. To help with that I have a couple of questions.


Scratch that. I've found some further information in the data Eric sent 
me off-list and I am now pretty sure what is going on.


There are multiple web applications deployed on the servers. I assume 
there are related but it actually doesn't matter.


At least one application is using the "new" MySQL JDBC driver:
com.mysql.cj.jdbc.Driver

At least one application is using the "old" MySQL JDBC driver:
com.mysql.jdbc.Driver


(I've told Eric off-list which application is using which).

There are, therefore, two drivers registered with the java.sql.DriverManager


The web applications are not using connection pooling. Or, if they are 
using it, they are using it very inefficiently. The result is that there 
is a high volume of calls to create new database connections.


This is problem number 1. Creating a database connection is expensive. 
That is why the concept of database connection pooling was created.



When a new connection is created, java.sql.DriverManager iterates over 
the list of registered drivers and

- tests to see if the current class loader can see the driver
- if yes, tests to see if that driver can service the connection url
- if yes, use it and exit
- go on to the next driver in the list and repeat

The test to see if the current class loader can use the driver is, 
essentially, to call Class.forName(driver.getClass(), true, classloader)


And that is problem number 2. That check is expensive if the current 
class loader can't load that driver.



It is also problem number 3. The reason it is expensive is that class 
loaders don't cache misses so if a web application has a large number of 
JARs, they all get scanned every time the DriverManager tries to create 
a new connection.



The slowness occurs in the web application that depends on the second 
JDBC driver in DriverManager's list. When a request that requires a 
database connection is received, there is a short delay while the web 
application tries, and fails, to load the first JDBC driver in the list. 
Class loading is synchronized on class name being loaded so if any other 
requests also need a database connection, they have to wait for this 
request to finish the search for the JDBC driver before they can 
continue. This creates a bottleneck. Requests are essentially rate 
limited to 1 request that requires a database connection per however 
long it takes to scan every JAR in the web application for a class that 
isn't there. If the average rate of requests exceeds this rate limit 
then a queue is going to build up and it won't subside until the average 
rate of requests falls below this rate limit.




Problem number 1 is an application issue. It should be using pooling. It 
seems unlikely that we'll see a solution from the application vendor and 
- even if the vendor does commit to a fix - I suspect it will take months.



Problem number 2 is a JRE issue. I think there are potentially more 
efficient ways to perform that check but that needs research as things 
like OSGI and JPMS make class loading more complicated.



Problem number 3 is a Tomcat issue. It should be relatively easy to 
start caching misses (i.e. this class loader cannot load this class) and 
save the time spent repeatedly scanning JARs for a class that isn't there.



I intend to wok on a patch for Tomcat that will add caching that should 
speed things up considerably. I hope to have something for Eric to test 
today but it might take me until tomorrow as I have a few other time 
critical things fighting to get tot he top of my TODO list at the moment.



Moving the JDBC driver JARs from WEB-INF/lib to $CATALINA_BASE/lib may 
also be a short-term fix but is likely to create problems if the same 
JAR ever exists in both locations at the same time.



Mark

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

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-05-29 Thread Mark Thomas


On 28/05/2024 16:26, Eric Robinson wrote:




Took a bunch of thread and heap dumps during today's painful debacle. Will send 
a link to those as soon as I can.


Thanks. I have them. I have taken a look and I am starting to form a 
theory. To help with that I have a couple of questions.


1. Could you tell me where the JDBC driver JAR is located. Is it in 
WEB-INF/lib for the web application(s) or is it in $CATALINA_BASE/lib ?


2. How big is WEB-INF/lib for the web application(s)? How many JAR files 
and what is the total size on disk of that directory?


3. Would you be prepared to run Tomcat in production with a binary patch 
(against 9.0.80). This would involve placing one or more class files in 
the right directory structure under $CATALINA_BASE/lib either to collect 
additional debug logging or to test a potential fix.




Mark

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

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-05-28 Thread Mark Thomas

Hi Eric,

Follow-up observsations and comments in-line.

What time does this problem start?

It typically starts around 9:15 am EDT and goes until around 10:30 am.

Does that match the time of highest request load from the customer?
Rather than a spike, I'm wondering if the problem is triggered once load
exceeds some threshold.

We finished and implemented the script yesterday, so today will be the first
day that it produces results. It watches the catalina.out file for stuck thread
detection warnings. When the number of stuck threads exceeds a threshold, then
it starts doing thread dumps every 60 seconds until the counts drops back down
below the threshold. The users typically do not complain of slowness until the
stuck thread count exceeds 20, and during that time the threads often take up
to a minute or more to complete. It's too late today to change the timings, but
if it does not produce any actionable intel, we can adjust them tonight.

Lets see what that produces and go from there.

The vendor claims that the feature uses a different server and does not send
requests to the slow ones, so it has been re-enabled at the customer's request.
We may ask them to disable it again until we get this issue resolved.

Noted.

This customer sends about 1.5 million requests to each load-balanced server
during a typical production day. Most other customers send much less, often
only a fraction of that. However, at least one customer sends about 2 million
to the same server, and they don't see the problem. (I will check if they have
the AI feature enabled.)

Hmm. Whether that other customer has the AI feature enabled would be an
interesting data point.

Can we see the full stack trace please.

Here's one example.

java.lang.Throwable
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1252)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1220)

That is *very* interesting. That is the start of a synch block in the
class loader. It should complete quickly. The full thread dump should
tell us what is holding the lock. If we are lucky we'll be able to tell
why the lock is being held for so long.

We might need to reduce the time between thread dumps to figure out what
the thread that is blocking everything is doing. We'll see.

The app has DB connection details in two places. First, it uses a database
connection string in a .properties file, as follows. This string handles most
connections to the DB.

mobiledoc.DBUrl=jdbc:mysql://ha52a:5791
mobiledoc.DBName=mobiledoc_791?useSSL=false=round=false=true=true=false=true=true
mobiledoc.DBUser=
mobiledoc.DBPassword=

OK. That seems unlikely to be using connection pooling although the
application might be pooling internally.

It also has second DB config specifically for a drug database.

c:\out.log

INSERT_CONTEXT_FACTORY
INSERT_JNDI_URL
INSERT_USER_NAME
INSERT_PASSWORD
INSERT_LOOKUP_NAME
com.mysql.jdbc.Driver

jdbc:mysql://dbclust54:5791/medispan?sessionVariables=wait_timeout=28800,interactive_timeout=28800
redacted
redacted
10
5000

true
0
1800

Hmm. There is a pool size setting there but we can't tell if it is being
used.

Is that Tomcat 9.0.80 as provided by the ASF?

An explicit answer to this question would be helpful.

In terms of the way forward, we need to see to thread dumps when the
problem is happening to figure out where the blockage is happening and
(hopefully) why.

Mark

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

Re: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

2024-05-28 Thread Mark Thomas

Hi Eric,

I have a some follow-up questions in-line. I have also read the other
messages in this thread and added a couple of additional questions based
on what I read in those threads.

On 26/05/2024 02:58, Eric Robinson wrote:

One of our hosting customers is a medical practice using a commercial EMR
running on tomcat+mysql. It has operated well for over a year, but users have
suddenly begun experiencing slowness for about an hour at the same time every
day.

What time does this problem start?

Does it occur every day of the week including weekends?

How does the slowness correlate to:
- request volume
- requests to any particular URL(s)?
- requests from any particular client IP?
- any other attribute of the request?

(I'm trying to see if there is something about the requests that
triggers the issue.)

During the slow times, we've done all the usual troubleshooting to catch the
problem in the act. The servers have plenty of power and are not overworked.
There are no slow database queries. Network connectivity is solid. Tomcat has
plenty of memory. The numbers of database connections, threads, questions,
queries, etc., remain steady, without spikes. There is no unusual disk latency.
We have not found any maintenance tasks running during that timeframe.

I would usually suggest taking three thread dumps approximately 5s apart
and then diffing them to try and spot "slow moving" threads.

I see you have scripted trigger a thread dump when the slowness hits. If
you haven't already, please configure it to capture (at least) 3 dumps
~5 seconds apart.

(If we can spot the slow moving threads we might be able to identify
what it is that makes them slow moving.)

The customer has another load-balanced tomcat instance on a different physical
server, and the problem happens on that one, too. The servers were upgraded
with a new kernel and packages on 4/5/24, but the issue did not appear until
5/6/24. The vendor enabled a new feature in the customer's software, and the
problem appeared the next day, but they subsequently disabled the feature, and
(reportedly) the problem did not go away.

Have you confirmed that the feature really is disabled? Or was it just
hidden?

Has this feature been enabled for any other customers? If yes, have they
experienced similar issues?

(It is suspicious that the issue occurred after the feature was
disabled. I wonder if some elements of that change (e.g. a database
change) are still in place and causing issues.)

It is worth mentioning that the servers are multi-tenanted, with other
customers running the same medical application, but the others do not
experience the slowdowns, even though they are on the same servers.

How does this customer compare, in terms of volume of requests, to other
customers that are not experiencing this issue.

Is there anything unique or special about the customer experiencing the
issue? Do they have some custom settings no-one else uses?

(I am trying to figure out if the issue is load related, customer
specific or something else).

There are no unusual errors in the tomcat or database server logs, EXCEPT this
one: Java.sql.DriverManager.getConnection

Can we see the full stack trace please.

During the periods of slowness, we see lots of those errors along with a large
spike in the number of stuck tomcat threads (from 1 or 2 to as high as 100). It
seems obvious that the threads are stuck because tomcat is waiting on a
connection to the database. However, tcpdump shows that connectivity to the
database is perfect at the network and application layers. There are no
unanswered SYNs, no retransmissions, no half-open connections, no failures to
allocate TCP ports, no conntrack messages, and no other indications of system
resource exhaustion. Every time tomcat requests a connection to the DB, it
completes in less than 1 ms. Ten thousand connection attempts completed
successfully in about 15 seconds, with zero failures.

It sounds like things might be getting stuck somewhere in or near the
JDBC driver.

Can you provide the exact version of the JDBC driver you are using?

Can you provide the full database configuration from context.xml (or
wherever it is configured). Please redact sensitive information such as
passwords.

We are forced to conclude that some database connection requests are being
initiated but are not being sent on the wire. The problem seems to be in the
interaction between tomcat and the database driver, or in the driver itself.

I agree.

Unfortunately, the application vendor is taking the "it's your infrastructure"
position without providing any evidence or offering suggestions for configuration changes,

I'm sorry to hear that. We'll do what we can to help.

other than to deploy more tomcat instances, which is just shooting in the dark.
They don't know why the software is throwing
java.sql.DriverManager.getConnection errors (even though it's their code), and

Re: Deployment using directory

2024-05-25 Thread Mark Thomas


On 24/05/2024 19:28, Brandie Nickey wrote:

Hi all,

I am curious if there are any cons to deploying a webapp without using a war 
file.


None.

If you deploy a WAR Tomcat will (by default) unpack it and run it from 
the unpacked directory anyway. If you configure Tomcat to run from the 
packed WAR you will get a small performance hit.



 Our web app has just always traditionally been 'unzipped' as a set of folders 
within the Tomcat/webapps/ROOT directory.  However I have been doing some 
troubleshooting using procmon.exe from Sysinternals and it appears that tomcat 
is constantly looking for Root.war file.


Define constantly. I'd expect Tomcat to be checking for a WAR file every 
~15s if autodeploy is enabled.



Not sure if I have something misconfigured or this behavior is just normal?  
The app will start up but does have some issues with loading all features  
(takes 2+ hours) .


If the app is taking 2 hours to start then the app has some serious issues.


Running Tomcat 8.0.43.


Tomcat 8.0.x reached end of support on 30 June 2018.

Tomcat 8.5.x (that replaced 8.0.x) reached end of life on 31 March 2024.

You need to upgrade to at least 9.0.x ASAP. I'd suggest a quick upgrade 
to 9.0.x and then start looking at moving to 10.1.x or even 11.0.x but 
that is a bigger job due to the Java EE -> Jskarta EE repackaging.


Mark

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

Re: PersistentManager and ClassNotFoundException

2024-05-25 Thread Mark Thomas


On 24/05/2024 14:31, Jakub Królikowski wrote:




Hi Mark,
It seems to me that this can be tested on any application.
In Tomcat 10.1, if any session attribute is an instance of a new public
class (unknown to Tomcat and to Tomcat class loader), implementing
java.io.Serializable,
then on reloading the application PersistanceManager (configured as in the
first message) crashes with ClassNotFoundException. StandardManager works.
I don't know if this problem occurred in earlier versions of Tomcat.

If you fail to reproduce this bug, let me know, I will prepare a simple web
app.

Best regards,

Jakub


Jakub,

The chances of a committer looking at the issue you are seeing are 
significantly higher if you provide a test case that demonstrates the 
issue rather than expecting a committer to write a test case for you 
based on your description.


Mark


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

Re: PersistentManager and ClassNotFoundException

2024-05-24 Thread Mark Thomas

Can you provide the simplest web application (with source) that 
replications the problem?


Mark


On 23/05/2024 23:45, Jakub Królikowski wrote:

Hi,

I'm working with Tomcat 10.1.

When a user starts using the store in my web application, I save the
ShopCart object on the "cart" session attribute.
I want the "cart" attributes to return to the session after restarting the
app.


To enable session persistence I added



to the Context. It loads the StandardManager.

And this works fine - after reload / restart the object "ShopCart" is back
in the session.



I want to experiment with PersistentManager. Tomcat docs says: "
The persistence across restarts provided by the *StandardManager* is a
simpler implementation than that provided by the *PersistentManager*. If
robust, production quality persistence across restarts is required then the
*PersistentManager* should be used with an appropriate configuration.

"

I hope for a Listener of deserialization of the session attributes.

The new Manager configuration looks like this:







But it doesn't work. After restart I get this exception:


java.lang.ClassNotFoundException: ShopCart

at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1332)

at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1144)

at java.base/java.lang.Class.forName0(Native Method)

at java.base/java.lang.Class.forName(Class.java:534)

at java.base/java.lang.Class.forName(Class.java:513)

at
org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:158)

at
java.base/java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:2061)

at
java.base/java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1927)

at
java.base/java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2252)

at
java.base/java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1762)

at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:540)

at
java.base/java.io.ObjectInputStream.readObject(ObjectInputStream.java:498)

at
org.apache.catalina.session.StandardSession.doReadObject(StandardSession.java:1198)

at
org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:831)

at org.apache.catalina.session.FileStore.load(FileStore.java:203)

at org.apache.catalina.session.StoreBase.processExpires(StoreBase.java:138)

at
org.apache.catalina.session.PersistentManagerBase.processExpires(PersistentManagerBase.java:409)

at
org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:587)

at
org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:4787)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1172)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1176)

at
org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1154)

at
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)

at
java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358)

at
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)

at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)

at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)

at
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:63)

at java.base/java.lang.Thread.run(Thread.java:1583)


I guess this means that the two managers use ClassLoader differently.
How to get the PersistentManager to work in this case?

Best regards,
--
Jakub Królikowski



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

Re: Security Constraints and Session Timeout

2024-05-24 Thread Mark Thomas


On 23/05/2024 17:01, Jerry Malcolm wrote:
I have some servlets that I can't put security constraints on at the 
web.xml level.  However, deep down in the code there are some places 
that I need a user to be logged in.  My overall UI ensures this all 
works by having certain JSPs with constraints that force the user to log 
in before getting to the servlet.  But if the user spends too much time 
interacting with the servlet and not reloading one of the pages that 
require a login, the session will timeout, and the user is now buried in 
one of the servlets, and I've lost the session/userprincipal.  It 
appears that interacting with a servlet that has no constraints does not 
reset the session timer.  Is that correct, or am I seeing it wrong?  I 
know the easy answer would be to add a constraint requiring login to 
access the servlet.  But with the current design, that's not going to 
work. Is there something I can do in the servlet and/or servlet config 
in web.xml to force servlet access to keep resetting the session timer 
so it won't expire without having to put role constraints directly on 
the servlet?


Just calling HttpServletRequest.getSession(false) from the Servlet 
should be sufficient.


Note you can monitor the expiration time for sessions using the Manager 
application. That might be helpful in testing.


Mark

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

Re: After Windows Server Restart, tomcat generating New JSESSIONID even with <%@ page session="false" %>

2024-05-07 Thread Mark Thomas


On 06/05/2024 11:05, Hamdan Khan wrote:

Hello everyone,

We're having a problem with Tomcat on Windows servers. It only happens when:

Tomcat is running as a service (automatically started by Windows).
The Windows server automatically restarts for updates.
After the restart, Tomcat starts creating new session IDs for
every request,


That suggests that the client isn't returning the session ID to Tomcat 
for the subsequent request. I'd be asking why that is the case.


Is there a reverse proxy in the mix?

Are you using sessions at all or are they completely disabled? If yes, 
which session manager are you using?



even though our jsp tells it not to.

<%@ page session="false" %>


That is just a single page and any page can potentially trigger session 
creation.



We can fix this by deleting temp and work files from Tomcat and restarting
the service ourselves.  However, this is a manual process, and we'd like to
find a more permanent solution.


It would be interesting to know if you need to clear both of these or 
whether clearing just one is sufficient to resolve the issue. That might 
narrow down potential root causes.



Can anyone help us understand why this might be happening?


I can't think of any way Tomcat would do this. This feels more like an 
application issue at this point.



Or what logs to
configure and monitor.


My preference would always be to attach an IDE and use remote debugging 
but that probably isn't an option in production.


You could try attaching a profiler and recording object allocations. 
That should show you where/how sessions are being created.


The minimally invasive option would probably be to add an 
HttpSessionListener to your application that logs the current stack 
trace every time a session is created.



Version of Tomcat is Tomcat-9.0.83

To emphasize we are not able to reproduce this in our local computer it
only happens to the longrunning production servers.


If you manually reboot the production servers (without clearing out work 
or temp) can you trigger the issue?


Mark

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

Re: missing headers

2024-05-02 Thread Mark Thomas

On 02/05/2024 06:15, Piyush Sharma wrote:

Hi,

How to forward custom headers from frontend tomcat to backend tomcat witn
mod_jk?

When using mod_jk the front end is always httpd, not Tomcat.

You don't need to do anything. mod_jk passes all the http headers it
receives.

*Scenario :*

1. APP1 : Apache (mod_jk) + Tomcat
2. APP2 : Apache (mod_jk) + Tomcat

Now, when a user accesses APP1 it add fews headers via SSO app user details
etc..
I can see in Tomcat logs as by adding filters. Now when the request goes to
APP2 (backend Tomcat via Apache), it drops those custom headers.

That sounds like a client issue. Client sends request to app1 and
receives some custom headers. If you want those headers sent to app2
then that is a client issue, not a Tomcat issue.

I came to
know that *mod_jk does not use the http protocol to talk to the tomcat
server.* Is there any way to forward all the custom headers from frontend
application to backend applications.

This already happens.

https://stackoverflow.com/questions/18998715/http-response-header-not-coming-with-apache-tomcat-connection-using-mod-jk

There is a fair amount of nonsense in both the question and some of the
responses.

It would be a lot easier to help you if you provided a lot more
information. For example:

- httpd version
- tomcat version
- mod_jk version
- httpd configuration
- tomcat configuration
- mod_jk configuration
- sample request as sent by the client
- sample request as received by Tomcat
- sample response as sent by Tomcat
- sample response as received by the client
- the previous 4 to be provided both by going via the reverse proxy and
by going directly to Tomcat

Mark

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

Re: Monitoring and Tuning Tomcat

2024-05-01 Thread Mark Thomas


On 30/04/2024 21:24, Jerry Malcolm wrote:
I'm trying to optimize my instance, CPU, tuning, and size requirements 
for Tomcat.  It's easy to see CPU usage.  But this TC instance is 
running a lot of microservices that are often in and out fairly 
quickly.  So there can be a huge number of requests coming in.  I'm not 
sure that CPU starving is my biggest concern. I'm more interested is 
getting an understanding of TC front end bottlenecks and also JDBC data 
connection bottlenecks.   So I need a bit of education.   Am I correct 
that maxThreads on the connector throttles the number of requests that 
can come in at one time?


Not quite.

maxThreads is the maximum number of concurrent requests that Tomcat can 
process. This excludes:

- connections in keep-alive
- requests that have entered async mode and have exited the original
  container thread
This includes:
- multiple requests received on a single HTTP/2 connection

The maximum number of connections is controlled by maxConnections.

And connectionTimeout is the time to wait to 
get in the door if threads are maxed out before giving up and failing, 
correct?


No. It is the maximum time Tomcat will wait from the point the 
connection is accepted to reading the first byte of data.


I'd really like to track total threads in use and then track 
wait time if total threads are maxed out.  Likewise, with database 
connections.


You can track the status of the thread pool but wait time isn't 
available as Tomcat has no visibility into the accept queue (see 
acceptCount). Your OS might provide some stats here.


  I'd like to monitor the jdbc connection pool as well and 
see when and where the code is having to wait for a db connection and 
how long the average wait is.  I assume there are jms hooks to monitor 
this?


Correct. You probably want the stats from the o.a.t.u.dbcp.pool2.impl 
package.


But I don't want to reinvent the wheel.  Are there tools out there 
to assist with this already? Thx


Generally, I start with a profiler when looking at questions like this. 
I use YourKit because they given me a free copy to use for Tomcat 
development but there are lots of different profilers available.


Mark

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

Re: Disabling OPTIONS HTTP method with * path

2024-05-01 Thread Mark Thomas


On 30/04/2024 19:56, Oleg Frenkel wrote:

This issue exists in 9.0.88 and 10.1.23.

I am looking to disable the following HTTP request (note 'OPTIONS *' in the 
request):


Why?


Please confirm if this is a bug in Tomcat or if I am missing something in 
Tomcat configuration.


Neither. Tomcat is working as designed.

Mark

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

Re: Installation on Win 10 failure.

2024-04-23 Thread Mark Thomas

On 23/04/2024 03:31, DdC wrote:

I have installed tomcat originally with version 4.04 on winxp andlater on win7,
ubuntu, and another linux box - many times by now.Trouble now with win10 and
version 9.0.88.Yes, there is a jdk, CLASSPATH is set, j2ee.jar is in
lib.Running in a cmd window with bin startup triggers another cmd windowto
popup, shows errors flashing by and the 2nd window disappers.

Rather than running "startup.bat" use "catalina.bat run" which will keep
the process in the same window and you'll be able to read any error message.

Alternatively, you could look in the logs directory. It is usually
easiest if you empty the logs directory, attempt to start Tomcat and
then check the log files for errors.

Mark

Running subsequently shutdown gives: Tomcat may not be running.Thanks a lot ...
Each next window version made installation more difficult - or i gotolder :-)
Is win10 creating trouble? Or ?
Thanks for help ...

--
Home page: rs6.risingnet.net/~ddccMarketing site: www . OntoOO.comKindle
books: Side Effects: Impacts on the 21st
Century::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09MHJ5W48
Even if not
true::https://www.amazon.com/-/es/Dennis-Champeaux-ebook/dp/B09Y4WR9J7 9/11::
They had the Sun in their
Eyeshttps://www.amazon.com/11-They-had-their-Eyes-ebook/dp/B0CMQ2WSK9https://www.amazon.nl/dp/B0CMQ2WSK9

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Mark Thomas


On 18/04/2024 15:18, Stefan Ansing wrote:

Hi Rémy, Mark,



I just want to make sure that we’re understanding each other. I can see
that the connection needs to be closed in certain conditions to prevent
request smuggling attacks. I certainly don’t want to change that behaviour.

However, I’m facing a scenario where an application is responding to a
valid request (from HTTP perspective), with a valid response using these
status codes (more specifically status codes 400 and 500).


If the request is a valid HTTP request then a 400 status doesn't seem 
appropriate to me.


If the server is correctly handling that request to generate the 
response, a 500 status doesn't seem right either.




I don’t think that in this scenario a request smuggling attack could be
executed, or am I missing something?


The main issue is if the original request is invalid HTTP there is no 
way to determine where the next HTTP request starts.


If there is a proxy in the mix then the risks of something going wrong 
tend to go up.


Mark

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Mark Thomas

On 18/04/2024 15:16, Adwait Kumar Singh wrote:

I think we should *always* close connections in cases where it can lead to
request smuggling vulnerabilities like when there is an error during header
or request line parsing, but allowing the user to control connection close
when the status is being set by the user, should be safe?

I'm not (yet) convinced distinguishing between those scenarios is always
going to be possible.

It allows users to send back responses like InvalidInputException with a
400 status without being forced to close the connection.

I appreciate why a 400 is used here but 400 has always struck me as more
for protocol level issues rather than application level issues.

That is the fundamental problem here. The status codes are being used
for two completely different purposes.

Mark

On Thu, Apr 18, 2024 at 6:41 AM Rémy Maucherat wrote:

On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas wrote:

On 18/04/2024 09:07, Stefan Ansing wrote:

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version

10.1.19)

where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414,

500,

503, 501. This causes client applications to rapidly reconnect and

induce

high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful

microservices to

communicate errors. Reviewing RFC 9112 I couldn't find any requirement

for

closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the

same

behaviour, we believe that these status codes do not necessitate a new
connection.

The Tomcat developers disagree. Connections are closed after these
status codes to avoid various forms of request smuggling attacks.

Checking the Tomcat sources makes me believe that the behaviour is
hard-coded[1]. I'm reaching out here to re-evaluate the list of status
codes and to discuss the possibilities of making the behaviour

configurable.

Making this list of status codes configurable seems reasonable. The
default can stay as current and if users want to change it then they
have to accept the associated security risks.

If it's insecure, then it would still be a valid CVE even if the
configuration is optional. We don't have an "allowSmuggling" attribute
on the connector to relax header or status line parsing, even though
many would have wanted it in the past ...

Rémy

Mark

A colleague of mine reported a bug for this issue:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68901

Kind regards,
Stefan Ansing

[1]:

https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Mark Thomas


On 18/04/2024 14:41, Rémy Maucherat wrote:

On Thu, Apr 18, 2024 at 1:17 PM Mark Thomas  wrote:


On 18/04/2024 09:07, Stefan Ansing wrote:

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version 10.1.19)
where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414, 500,
503, 501. This causes client applications to rapidly reconnect and induce
high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful microservices to
communicate errors. Reviewing RFC 9112 I couldn't find any requirement for
closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the same
behaviour, we believe that these status codes do not necessitate a new
connection.


The Tomcat developers disagree. Connections are closed after these
status codes to avoid various forms of request smuggling attacks.


Checking the Tomcat sources makes me believe that the behaviour is
hard-coded[1]. I'm reaching out here to re-evaluate the list of status
codes and to discuss the possibilities of making the behaviour configurable.


Making this list of status codes configurable seems reasonable. The
default can stay as current and if users want to change it then they
have to accept the associated security risks.


If it's insecure, then it would still be a valid CVE even if the
configuration is optional. We don't have an "allowSmuggling" attribute
on the connector to relax header or status line parsing, even though
many would have wanted it in the past ...


I don't think it is quite that black and white.

If the client connects directly to the server (no proxy) then there 
request smuggling is a lot less likely and arguably impossible (assuming 
no Tomcat bugs).


If there is a proxy that is when there is a risk of request smuggling.

Given that there are circumstances where the risk of request smuggling 
is low (possibly none) it seems reasonable to allow users to configure 
the status codes that trigger connection close.


Mark

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

Re: Regarding Tomcat url redirection

2024-04-18 Thread Mark Thomas


On 18/04/2024 12:05, lavanya tech wrote:

Hi Team,

I am using "Tomcat 10.1" in our environment and I wanted to redirect url
from https://example.com to https://www.servercom: and for this i
modified the server.xml as below in tomcat config, and the below
configuration doesnot seems to work. Does anyone has ideas. Please suggest.
The url alone https://www.servercom:/ already works. But just
redirection from the old to one doesnot.


 
 example.com
 
 
 
 
 
 example.com
 
 
 
 
 example.com
 
 https://www.servercom:/example/$1 [R=301,L]


1. That isn't valid XML.

2. Where in the Tomcat docs does it say you can nest re-write rules in a 
Host element (or any other element)?



 
 
 
 



You need to configure the RewriteValve.
https://tomcat.apache.org/tomcat-10.1-doc/rewrite.html

Mark

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

Re: Tomcat closes connections on unexpected status codes

2024-04-18 Thread Mark Thomas

On 18/04/2024 09:07, Stefan Ansing wrote:

Hi,

We've observed some unexpected behaviour in Apache Tomcat (version 10.1.19)
where we see that HTTP/1.1 connections are closed whenever a servlet
application returns the following status codes: 400, 408, 411, 414, 500,
503, 501. This causes client applications to rapidly reconnect and induce
high server-side CPU load due to doing TLS handshakes.

The 400 and 500 status codes are commonly used in RESTful microservices to
communicate errors. Reviewing RFC 9112 I couldn't find any requirement for
closing connections on these status codes.

After testing with Undertow (version 2.3.12), where we didn't see the same
behaviour, we believe that these status codes do not necessitate a new
connection.

The Tomcat developers disagree. Connections are closed after these
status codes to avoid various forms of request smuggling attacks.

Making this list of status codes configurable seems reasonable. The
default can stay as current and if users want to change it then they
have to accept the associated security risks.

Mark

A colleague of mine reported a bug for this issue:
https://bz.apache.org/bugzilla/show_bug.cgi?id=68901

Kind regards,
Stefan Ansing

[1]:
https://github.com/apache/tomcat/blame/bc900e0100de9879604b93af4722c272ab3d1a24/java/org/apache/coyote/http11/Http11Processor.java#L604-L617

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

Re: Tomcat log warnings for connection parameter limits?

2024-04-16 Thread Mark Thomas

It would be worth creating an enhancement request for this in Bugzilla 
to ensure the request doesn't get forgotten about.


Mark


On 16/04/2024 01:06, Baron Fujimoto wrote:

 From our perspective, it needn't be super timely. It would be more for
forensic confirmation that there's something we should consider. I think a
hysteresis behavior would be compatible with this.

On Mon, Apr 15, 2024 at 12:00 AM Mark Thomas  wrote:


On 11/04/2024 21:28, Baron Fujimoto wrote> I was thinking it would be
something that would be left on in a live> system. We can set these
parameters, so it would be useful to know if we

were hitting the set limits.


For the connection limit:

How timely do you need the information to be? It is much easier to add a
check when the connection is closed since a) it returns the current
count and b) we are already checking the return value for mis-counting.

For the thread limit:

We have a couple of options here. (We use a custom queue which
effectively changes the way threads in the pool re used.) The simplest
is probably to add log in TaskQueue.offer() if all threads are currently
being used.


I'm not sure I fully grasp how this additional logging presents a
significant incremental DOS risk. I mean, if an attacker is flooding you
with enough traffic or connections where this becomes an issue, aren't

you

already logging various aspects of the attempts anyway (e.g., access

logs,

etc)? At that point aren't your logs already being filled anyway?


It is an area we need to be careful with. Log messages that include
exceptions are of greatest concern since they are relatively expensive
to generate. If an invalid HTTP message triggers a log message with an
exception (it does, but only when configured for debug logging) then
there is a degree of DoS risk there.

Access logs are a special case and one that we have taken care to try
and optimise. Still, if you want to make a performance test look good
turning off access logging is one of the first things to do (and of
course results in totally meaningless results that don't reflect real
world usage).

I think the concern Chris was trying to express (although I'm sure he'll
correct me if I am wrong) is that when these limits are reached there is
a risk of a lot of log messages being generated and that can cause
issues both from a performance issue and from just filling the logs with
the same message over and over again.

I think what we would need is some form of hysteresis. Log a message
when the limit is reached, log another message when usage falls below
80%? of the limit. That way, administrators see the peaks in usage but
aren't inundated with log messages.

My only concern is that at least some this code is going to run for
every single request. It needs to be efficient. We should measure the
impact of adding this code before we decide on whether to include it.

Mark




On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Baron,

On 4/9/24 16:33, Baron Fujimoto wrote:

I'm investigating occasional 503 errors for our CAS service running in

a

Tomcat 10.1.x container. The 503s appear to correlate with some traffic
spikes at the same time.

The connector is configured as follows:

   

Can Tomcat log info such as when the maxThreads or maxConnections

limits

are reached? I'm basically trying to see if there is a good way to
more definitively determine what may have caused the 503s and what may

be

feasible to mitigate them.


Are you thinking of a debugging feature or something to be left-on for a
live production system?

Such logging might be considered a DOS vector for a live system: you can
fill the logs by asking lots of trivial requests.

-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: Package URLs for Apache Tomcat distributions

2024-04-15 Thread Mark Thomas


On 11/04/2024 16:52, von Loewenstein, Jan wrote:

Hi folks,

I am part of the Paketo community, and we are providing Cloud Native Buildpacks 
to create container images with – amongst other technologies – Apache Tomcat 
and Apache TomEE as application runtimes.

One of the features of Cloud Native Buildpacks is that images come with 
Software-Bill-of-Material. When installing Apache Tomcat, we issue the 
following CPE and pURL to the SBOM:

   1.  cpe:2.3:a:apache:tomcat:10.1.20:*:*:*:*:*:*:*
   2.  pkg:generic/apache-tomcat@10.1.20

The former should be the right one for users to find relevant CVEs in e.g. the 
nvd.nist.gov. The latter however is made up and will likely not lead to any 
findings on e.g. https://osv.dev

Now I am wondering if you report Tomcat vulnerabilities under any pURL and 
which one that would be.


We don't.


There is a 
proposal
 to introduce `pkg:apache` as a namespace, which would open up 
`pkg:apache/tomcat@10.1.20` as a canonical pURL.


That is a foundation wide decision and not one the Tomcat project can 
make unilaterally. That is probably a topic for 
security-disc...@community.apache.org where pURL has already been 
touched on this thread:

https://lists.apache.org/thread/7hs5ooqhfozmhlvq24k5xztzn1nwp9yv

Mark

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

Re: Tomcat log warnings for connection parameter limits?

2024-04-15 Thread Mark Thomas

On 11/04/2024 21:28, Baron Fujimoto wrote> I was thinking it would be 
something that would be left on in a live> system. We can set these 
parameters, so it would be useful to know if we

were hitting the set limits.


For the connection limit:

How timely do you need the information to be? It is much easier to add a 
check when the connection is closed since a) it returns the current 
count and b) we are already checking the return value for mis-counting.


For the thread limit:

We have a couple of options here. (We use a custom queue which 
effectively changes the way threads in the pool re used.) The simplest 
is probably to add log in TaskQueue.offer() if all threads are currently 
being used.



I'm not sure I fully grasp how this additional logging presents a
significant incremental DOS risk. I mean, if an attacker is flooding you
with enough traffic or connections where this becomes an issue, aren't you
already logging various aspects of the attempts anyway (e.g., access logs,
etc)? At that point aren't your logs already being filled anyway?


It is an area we need to be careful with. Log messages that include 
exceptions are of greatest concern since they are relatively expensive 
to generate. If an invalid HTTP message triggers a log message with an 
exception (it does, but only when configured for debug logging) then 
there is a degree of DoS risk there.


Access logs are a special case and one that we have taken care to try 
and optimise. Still, if you want to make a performance test look good 
turning off access logging is one of the first things to do (and of 
course results in totally meaningless results that don't reflect real 
world usage).


I think the concern Chris was trying to express (although I'm sure he'll 
correct me if I am wrong) is that when these limits are reached there is 
a risk of a lot of log messages being generated and that can cause 
issues both from a performance issue and from just filling the logs with 
the same message over and over again.


I think what we would need is some form of hysteresis. Log a message 
when the limit is reached, log another message when usage falls below 
80%? of the limit. That way, administrators see the peaks in usage but 
aren't inundated with log messages.


My only concern is that at least some this code is going to run for 
every single request. It needs to be efficient. We should measure the 
impact of adding this code before we decide on whether to include it.


Mark




On Thu, Apr 11, 2024 at 1:44 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Baron,

On 4/9/24 16:33, Baron Fujimoto wrote:

I'm investigating occasional 503 errors for our CAS service running in a
Tomcat 10.1.x container. The 503s appear to correlate with some traffic
spikes at the same time.

The connector is configured as follows:

  

Can Tomcat log info such as when the maxThreads or maxConnections limits
are reached? I'm basically trying to see if there is a good way to
more definitively determine what may have caused the 503s and what may be
feasible to mitigate them.


Are you thinking of a debugging feature or something to be left-on for a
live production system?

Such logging might be considered a DOS vector for a live system: you can
fill the logs by asking lots of trivial requests.

-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: Retrieve server.built, server.number

2024-04-11 Thread Mark Thomas





On 11/04/2024 15:49, Bill Stewart wrote:

On Wed, Apr 10, 2024 at 2:14 PM Mark Thomas wrote:


... and it might represent an information leakage vulnerability in your

application. Be Careful.


Shall we start the flame war now on whether exposing the current version
   you are running represents a valid vulnerability or if hiding it is
just security by obscurity? Or do you want to save it for Bratislava?

:)

More seriously, your time is likely to be better spent (in my view)
keeping your Tomcat installations up to date with the latest releases
than it is ensuring that you hide the version number.



The amusing thing (or irritating thing, depending on your point of view) is
when a large organization uses a vulnerability scanner and a Tomcat
instance gets flagged as a security risk because it reveals its version
number in the 404 error page. (Yes, this is a real scenario.)


At least it is an easy fix: showServerInfo="false"

assuming that is going to be easier than convincing folks that exposing 
the version number isn't an issue.


Mark

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

Re: Retrieve server.built, server.number

2024-04-10 Thread Mark Thomas





On 10/04/2024 21:15, Christopher Schultz wrote:

All,

On 4/10/24 4:00 AM, Mark Thomas wrote:

On 09/04/2024 17:17, prat 007 wrote:

Hi All,

I would like to know is there a way to find tomcat's server.built and
server.number remotely using tool loke curl or from browser?


In a default installation, no.

You'd have to write a servlet that reported that information and then 
request that page.


... and it might represent an information leakage vulnerability in your 
application. Be Careful.


Shall we start the flame war now on whether exposing the current version 
 you are running represents a valid vulnerability or if hiding it is 
just security by obscurity? Or do you want to save it for Bratislava?


:)

More seriously, your time is likely to be better spent (in my view) 
keeping your Tomcat installations up to date with the latest releases 
than it is ensuring that you hide the version number.


Mark

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

Re: Retrieve server.built, server.number

2024-04-10 Thread Mark Thomas


On 09/04/2024 17:17, prat 007 wrote:

Hi All,

I would like to know is there a way to find tomcat's server.built and
server.number remotely using tool loke curl or from browser?


In a default installation, no.

You'd have to write a servlet that reported that information and then 
request that page.


Mark




I am currently running tomcat v 9.0.87.

This information gets displayed when we run version.sh or in the starting
logs when tomcat starts up but how we can find it without logging into the
tomcat server.

Thanks,



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

Re: Tomcat & Http 103 Early Hint

2024-04-10 Thread Mark Thomas


Contributions always welconme.

The initial work will be on the changes to the Servlet API. The issue to 
track that is:

https://github.com/jakartaee/servlet/issues/542

Mark


On 09/04/2024 08:15, xulin y wrote:

Hi Mark,

Is there any chance I could help with delivering this new feature? At
least, I can help with writing some tests.

I think this new http feature can be beneficial a lot for web application
page load performance. Therefore, this is crucial for the whole Tomcat
community.

By Xulin Yang
Kind Regards

Mark Thomas  于2024年4月8日周一 19:24写道：


8 Apr 2024 10:26:23 xulin y :


Hi,
I would like to ask about whether Tomcat has support for http 103 early
hint response status?


Not at the moment.


I have checked the latest
doc that



https://tomcat.apache.org/tomcat-11.0-doc/servletapi/jakarta/servlet/http/HttpServletResponse.html

does not have 103 response status.

If not, do we have any plan to implement it?


It is expected to be part of Servlet.next / Tomcat 12. If possible, there
is a good chance it will be back-ported to earlier Tomcat versions.

Mark




By Xulin Yang
Kind Regards


-
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: Tomcat & Http 103 Early Hint

2024-04-08 Thread Mark Thomas


8 Apr 2024 10:26:23 xulin y :


Hi,
I would like to ask about whether Tomcat has support for http 103 early
hint response status?


Not at the moment.


I have checked the latest
doc that

https://tomcat.apache.org/tomcat-11.0-doc/servletapi/jakarta/servlet/http/HttpServletResponse.html
does not have 103 response status.

If not, do we have any plan to implement it?


It is expected to be part of Servlet.next / Tomcat 12. If possible, there 
is a good chance it will be back-ported to earlier Tomcat versions.


Mark




By Xulin Yang
Kind Regards


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

Re: Intermittent error 404

2024-04-08 Thread Mark Thomas


8 Apr 2024 11:20:09 andreas.moro...@wobi.bz.it:


Hello
we use Apache Tomcat/8.5.99.


Tomcat 8.5.x is no longer supported by the Tomcat community. You should 
upgrade to at least 9.0.x or consider purchasing 8.5.x support from one 
of the commercial vendors that offer it.


It sounds like an issue with JSP compilation. I'd suggest stopping 
Tomcat, cleaning out the work directory and then starting Tomcat.


Mark



Last week I changed the user of the Tomcat services.


When I refresh teh page then every second time the page appears 
correctly and the other 50% I get the error


No I get intermittent error 404

The origin server did not find a current representation for the target 
resource or is not willing to disclose that one exists.


on the index.jsp

The user has the rights to read the index.jsp

The fact that sometimes it works and the next time it doesn't confuses 
me. If it were due to the rights, it should probably never work.

Can someone kindly help me?

Greetings
Andreas

Institut für den sozialen Wohnbau des Landes Südtirol
Istituto per l’edilizia sociale della Provincia autonoma di Bolzano
39100 Bozen Horazstraße 14 / 39100 Bolzano via Orazio, 14_*
*__*wobi.bz.it[https://www.wobi.bz.it/de/default.asp]*_*   
*_*ipes.bz.it[https://www.ipes.bz.it/it/default.asp]*_*



*[cid:_4_00C1B7780DBA0634003348A4C1258AF9]*

*
Dies ist eine vertrauliche Nachricht und nur für den Adressaten 
bestimmt. Sollten Sie diese Nachricht irrtümlich erhalten haben, bitten 
wir um Ihre diesbezügliche Benachrichtigung und um die Löschung der 
Nachricht. Eine Veröffentlichung oder Verbreitung des Inhaltes sowie 
jegliche anderweitige Verwendung sind untersagt.


Il contenuto di questa e-mail è rivolto esclusivamente al destinatario 
della stessa e deve intendersi riservato e personale. Laddove questa 
e-mail Le fosse pervenuta per errore, Le chiediamo di comunicarci 
l’errata notifica e di cancellarne il contenuto. Sono sempre vietate la 
pubblicazione o diffusione del contenuto, nonché l'utilizzo per 
qualsiasi altro scopo.


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

Re: [EXT]Re: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element

2024-04-02 Thread Mark Thomas


On 02/04/2024 15:41, Rick Noel wrote:

Mark you were correct. I, needed to move those attributes to the Connection 
element.
Plus on top of that I had this misspelled attribute  compressableMinemType
should be compressibleMimeType

In your opinion, should we use the Upgrade UpgradeProtcol protocol?


It depends. h2 is more performant in some circumstances. Best to test 
and find out.



I mean does not the semantics of its name imply it is better?


I'm afraid not. It is just the name of the process (HTTP upgrade) use to 
transition from HTTP/1.1 to h2c.


Mark




Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Mark Thomas 
Sent: Tuesday, April 2, 2024 10:05 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: unable to set compression, compressionMinSize and 
compressableMinemType attributes in UpgradeProtocol element

On 02/04/2024 14:53, Rick Noel wrote:

Hello,

What am I missing here?


You haven't provided information on the Tomcat version you are using.
I'm assuming 10.1.x.

https://tomcat.apache.org/tomcat-10.1-doc/config/http2.html

Search for compressionMinSize.


I get warnings that the compression related attributes of compression, 
compressionMinSize and compressableMinemType are not being set.





I have also tried moving of compression, compressionMinSize and
compressableMinemType to the Connector element with same results


That seems ... unlikely. Please provide the Connector configuration and the 
error message.


BTW, I am supposed to get improved speed by using the  UpgradeProtcol  
Correct?


It depends. YMMV.

Mark

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


-
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: unable to set compression, compressionMinSize and compressableMinemType attributes in UpgradeProtocol element

2024-04-02 Thread Mark Thomas


On 02/04/2024 14:53, Rick Noel wrote:

Hello,

What am I missing here?


You haven't provided information on the Tomcat version you are using. 
I'm assuming 10.1.x.


https://tomcat.apache.org/tomcat-10.1-doc/config/http2.html

Search for compressionMinSize.


I get warnings that the compression related attributes of compression, 
compressionMinSize and compressableMinemType are not being set.





I have also tried moving of compression, compressionMinSize and 
compressableMinemType to the Connector element with same results


That seems ... unlikely. Please provide the Connector configuration and 
the error message.



BTW, I am supposed to get improved speed by using the  UpgradeProtcol  
Correct?


It depends. YMMV.

Mark

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

Re: PKCS#8 encryption algorithm unrecognized

2024-03-31 Thread Mark Thomas

4M3.mydomain.com.key" -out "C:\tmp12\Certificate\Private
Key\WSD-2DNX4M3.mydomain.com.key.2" -passin pass:"changeit"
openssl.exe rsa -aes256 -in "C:\tmp12\Certificate\Private
Key\WSD-2DNX4M3.mydomain.com.key.2" -out "C:\tmp12\Certificate\Private
Key\WSD-2DNX4M3.mydomain.com.key.3" -passin pass:"changeit" -passout
pass:"changeit"
openssl.exe pkcs8 -topk8 -v1 PBE-SHA1-3DES -in
"C:\tmp12\Certificate\Private Key\WSD-2DNX4M3.mydomain.com.key.3" -out
"C:\tmp12\Certificate\Private Key\WSD-2DNX4M3.mydomain.com.key" -passin
pass:"changeit" -passout pass:"changeit"

DEL /Q "C:\tmp12\Certificate\Private Key\WSD-2DNX4M3.mydomain.com.key.2"
DEL /Q "C:\tmp12\Certificate\Private Key\WSD-2DNX4M3.mydomain.com.key.3"

keytool.exe -importkeystore -srckeystore
"C:\tmp12\Certificate\Keystore\Vessel.jks" -destkeystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -srcstoretype JKS -deststoretype
PKCS12 -srcstorepass "changeit" -deststorepass "changeit" -noprompt
keytool.exe -delete -alias "ASA12 SAMM Vessel Temporary CA" -keystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -storepass "changeit" -noprompt
keytool.exe -delete -alias "ASA12 SAMM Vessel" -keystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -storepass "changeit" -noprompt
keytool.exe -delete -alias "WSD-2DNX4M3.mydomain.com" -keystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -storepass "changeit" -noprompt
keytool.exe -import -alias "ASA12 SAMM Vessel" -file "C:\tmp12\Client
Configuration.pem" -keystore "C:\tmp12\Certificate\Keystore\Vessel.p12"
-storepass "changeit" -noprompt
keytool.exe -import -trustcacerts -alias "ASA12 SAMM Vessel Temporary CA"
-file "C:\tmp12\Client Configuration.pem" -keystore
"C:\tmp12\Certificate\Keystore\Vessel.p12" -storepass "changeit" -noprompt


if you need anything else please get in touch with me.
I have tested this with the Tomcat 87 release and it still does not work.

Thanks

Mark Resh




On Tue, Mar 19, 2024 at 4:15 PM Mark Thomas  wrote:


On 19/03/2024 18:18, Timothy Resh wrote:


ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"


  SSLPassword="${KSENC(6qkaMErQ==;

C:\Certificate\Keystore\Vessel.p12)}"

SSLCertificateChainFile="C:Certificate\Public Key\WSD-2DNX4M3...cer"
SSLCertificateFile="C:\Certificate\Public Key\WSD-2DNX4M3...cer"
SSLCertificateKeyFile="C:\Certificate\Private Key\WSD-2DNX4M3..key"
SSLVerifyClient="optional"
SSLCACertificateFile="C:\Certificates\CA\intermediate.ca"
SSLCACertificatePath="C:\Certificates\CA\"




where the . is the fqdn

This works fine *until* Tomcat 9.0.83 and now we get the following listed
below. I have read some of the
https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=67675 bugs and ask

for

help.
The certificates are being created using openssl 3.013.  Please note the
encrypted password to the p12 keystore.  There was a message saying this
was going to be fixed in a January release.
I just tested 9.0.87 and the error is the same.  The ASN.1 is  OBJECT
IDENTIFIER=Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Does anyone have some suggestions for a fix?


Please provide a set of OpenSSL commands that create a problematic,
self-signed certificate for localhost. This will save us a *lot* of time.

Mark




Thanks Mark Resh


15-Mar-2024 18:27:37.621 WARNING [main]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the
[ciphers] attribute in a manner consistent with the latest OpenSSL
development branch. Some of the specified [ciphers] are not supported by
the configured SSL engine for this connector (which may use JSSE or an
older OpenSSL version) and have been skipped:
[[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256]]
15-Mar-2024 18:27:37.636 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector["https-openssl-apr-192.168.56.1-8443"]]
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at

org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at


org.apache.catalina.core.StandardService.initInternal(StandardService.java:554)

at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at


org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:103

Re: [EXT]Re: how to define database resource in just context.xml or server.xml

2024-03-31 Thread Mark Thomas


On 29/03/2024 21:58, Christopher Schultz wrote:

Rick,

On 3/29/24 14:33, Rick Noel wrote:

Our application is really a suite of 5applications.  And the
server.xml  I am talking about is on our dev machine, where we want
to run all 5 apps on the one web server.

The context.xml has global enviroiment variables (like mail server
related vars) that all the dev applications use. All the different
dev applications also use the same database.

So that is why we define resources in the context.xml  file
It sounds like you really *do* want to define the JDBC/JNDI resource in 
server.xml and the link it to your applications.


I think the correct way to do that is by defining it in server.xml and 
then linking it through your applications' WEB-INF/web.xml files.


You should not have to touch CATALINA_BASE/conf/context.xml.


The only reason you might want to touch context.xml is if you want to 
provide the same resource link to all web applications rather than have 
to specify it in each web application.


Mark



-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, March 29, 2024 2:21 PM
To: Tomcat Users List ; Rick Noel 

Subject: Re: [EXT]Re: how to define database resource in just 
context.xml or server.xml


Rick,

On 3/29/24 11:56, Rick Noel wrote:

If have the resource defined in
CATALINA_BASE/conf/context.xml
And
CATALINA_BASE/conf/server.xml


You really shouldn't have anything custom in 
CATALINA_BASE/conf/context.xml. That will affect every application 
deployed on the server. Perhaps you only have a single application 
deployed, but things can get really confusing when you edit that file.

It also makes upgrades more difficult.

I would recommend taking your  from 
CATALINA_BASE/conf/context.xml and putting it into the proper place:
your application's META-INF/context.xml file. You will need to 
surround it with  ...  since that file defines the 
context.


If you have  in your CATALINA_BASE/conf/server.xml file, you 
should remove it. If you want to disable auto-deploy, then you can 
always copy your application's META-INF/context.xml file into 
CATALINA_BASE/conf/[engine]/[host]/[contextpath].xml.


Finally, you should be able to delete your  from your 
CATALINA_BASE/conf/server.xml file entirely.


Do you have anything in your web.xml that is related? For example:

    
  jdbc/foo
  javax.sql.DataSource
  Container
    

I have one of those in my web.xml, but it's not clear to be whether or 
not I actually need it. I have *one* of them but my application uses 
two different JDBC resources. Both are declared in 
META-INF/context.xml and both are available to the application.


I think you need to use  in web.xml when you define 
"global naming resources" in server.xml. But if you put them into 
META-INF/context.xml it's obvious that (a) they aren't global and (b) 
the application expects them.


So I would remove any global naming resources you may have in 
server.xml and also remove anything you don't need in web.xml.


Doing all this will make upgrading Tomcat much easier.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Friday, March 29, 2024 11:47 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: how to define database resource in just context.xml
or server.xml

Rick,

On 3/29/24 09:48, Rick Noel wrote:

Can someone tell me why I need to have my database source defined in
both my context.xml and server.xml? I thought we are suppose to
define it in only one location?

It's definitely not a requirement to specify it in both places.


I can only log into my app if I have it defined in both my
context.xml and server.xml

Below  is my database resource   as defined in server.xml..

I have xxx out postgres URL for security reasons





     
type="javax.sql.DataSource"  driverClassName="org.postgresql.Driver"
 
url="jdbc:postgresql://xxx"
 username="postgres" 
password="postgres4now"
 maxTotal="30"  maxIdle="30" 
maxWaitMillis="-1"
 
removeAbandonedOnBorrow="true" removeAbandonedTimeout="90"
 testOnBorrow="true"  
validationQuery="select 1" validationQueryTimeout="3"
 testWhileIdle="true"  
timeBetweenEvictionRunsMillis="6"

 testOnReturn="true"
  />


 



Below is my database resource   as defined in context.xml




   



      type="javax.sql.DataSource"  
driverClassName="org.postgresql.Driver"

    url="jdbc:postgresql://xx
    username="postgres" password="postgres4now"
    maxTotal="30"  maxIdle="30" maxWaitMillis="-1"
    removeAbandonedOnBorrow="true"

Re: [EXT]Re: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :

2024-03-22 Thread Mark Thomas


On 22/03/2024 15:43, Rick Noel wrote:

Mark,

So if my customer object is failing to get set in the session replication,
I could add this to the config snippet?

sessionAttributeNameFilter="customer"


You set that to the attributes you DO want to replicate, not the ones 
you don't.


Mark



so like this?...




   

   
 
 

 
   
 
 
 
 
   

   


   
  





Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-----
From: Mark Thomas 
Sent: Friday, March 22, 2024 11:32 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: Tomcat session replication issue - 
java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :

On 22/03/2024 15:15, Rick Noel wrote:

Is there a way to configure DeltaManager or the Cluster element so it does not 
cause my application to throw this error.

22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] 
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for 
servlet [jsp] in context with path [##0001] threw exception [An exception 
occurred processing [/services/include/properties.jsp] at line [196]

193:
194:session.setAttribute( "format", stationFormat );
195:session.setAttribute( "employee_id", employeeId );
196:session.setAttribute( "customer", customer );
197:session.setAttribute( "customer_id", customerId );
198:session.setAttribute( "nonidentifier_call_letters", 
nonIdentifierCallLetters );
199:session.setAttribute( "call_letters", callLetters );


Stacktrace:] with root cause
 java.lang.IllegalArgumentException: setAttribute: 
Non-serializable attribute [customer]


I know why the error, it is because the  customer object was never written to 
be serialiazable.
The old application I am working on has a lot of such non serialized objects 
and I do not want to search out change them all to implement serialiazable

I am hoping there is a way to configure Tomcat to just not try and replication 
sessions all object which are not serialiazable


https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html

Search for sessionAttributeNameFilter

Mark

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you know the sender and you are sure the 
content is safe. Please report the message using the Report Message feature in 
your email client if you believe the email is suspicious.


-
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: Tomcat session replication issue - java.lang.IllegalArgumentException: setAttribute: Non-serializable attribute :

2024-03-22 Thread Mark Thomas


On 22/03/2024 15:15, Rick Noel wrote:

Is there a way to configure DeltaManager or the Cluster element so it does not 
cause my application to throw this error.

22-Mar-2024 10:56:34.382 SEVERE [http-nio-8586-exec-5] 
org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for 
servlet [jsp] in context with path [##0001] threw exception [An exception 
occurred processing [/services/include/properties.jsp] at line [196]

193:
194:session.setAttribute( "format", stationFormat );
195:session.setAttribute( "employee_id", employeeId );
196:session.setAttribute( "customer", customer );
197:session.setAttribute( "customer_id", customerId );
198:session.setAttribute( "nonidentifier_call_letters", 
nonIdentifierCallLetters );
199:session.setAttribute( "call_letters", callLetters );


Stacktrace:] with root cause
java.lang.IllegalArgumentException: setAttribute: 
Non-serializable attribute [customer]


I know why the error, it is because the  customer object was never written to 
be serialiazable.
The old application I am working on has a lot of such non serialized objects 
and I do not want to search out change them all to implement serialiazable

I am hoping there is a way to configure Tomcat to just not try and replication 
sessions all object which are not serialiazable


https://tomcat.apache.org/tomcat-10.1-doc/config/manager.html

Search for sessionAttributeNameFilter

Mark

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

Re: Regression in mutual authentication in 9.0.86+?

2024-03-21 Thread Mark Thomas


On 21/03/2024 16:12, Amit Pande wrote:

Thank you Mark for your inputs.

Upon further debugging, it looks like the issue we ran into is also with the 
reloading of SSL context.

Test execution sequence:
1. Add a trusted CA in Tomcat's trust store.
2. The SSL context is reloaded if any of the trust/key store has changes.
3. Perform a mutual client authentication using a client certificate signed by 
the CA used in step 1.

Still a bit puzzled in such a case there was no SSL handshake failure at Tomcat 
level but request made it to application and failed (due to empty 
javax.servlet.request.X509Certificate).


It sounds like you have optional certificate verification enabled.


One follow-up question:

Are we planning to have an immediate 9.0.88 release, or it will be regular 
cadence? Asking because the versions until 9.0.85 have vulnerabilities reported 
and this regression might potentially block the upgrade to 9.0.86/87.


This fix will be picked up in the April release round.

Mark



Lastly, I wholeheartedly echo the gratitude many have expressed around the 
awesome Tomcat leads.

Thanks,
Amit


-Original Message-
From: Mark Thomas 
Sent: Monday, March 18, 2024 4:41 AM
To: users@tomcat.apache.org
Subject: Re: Regression in mutual authentication in 9.0.86+?


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



I've just tested 9.0.x and mutual TLS authentication appears to be working as 
expected.

I suggest starting with testing a simple JSP that echoes that attribute and if 
you still see the issue, provide us with your configuration. Note that the 
issue may be related to the certs you are using so the configuration 
information should include steps to recreate the TLS certs with keystore, 
OpenSSL or similar.

On 15/03/2024 00:48, Amit Pande wrote:

Hello all,

I have upgraded the Tomcat version from 9.0.85 to 9.0.86 (and tried with 9.0.87 
too).

Some of our tests which involve on mutual authentication ("certificateVerification = 
optional") have started to fail.

In tests where the client does pass the certificate, I didn't see any SSL handshake 
errors (with SSL handshake debugging enabled) but 
"javax.servlet.request.X509Certificate" attribute wasn't set. This is the 
attribute the application needs for further validations.


Have you confirmed that the certificate was sent from the client?


Could anyone please give pointers on how to debug this further?

Any code pointers where Tomcat sets this 
"javax.servlet.request.X509Certificate" attribute?


git clone
grep


Also, one more question - with optional certificate verification, the 
connection doesn't fail if certificate is not passed. But connection will fail 
if SSL handshake fails when a certificate is passed by client, is that correct 
understanding?


Yes, that is what I would expect.

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: What future plans are for Tomcat authentication

2024-03-20 Thread Mark Thomas


On 20/03/2024 06:22, Mircea Butmalai wrote:




Questions are:

   1.  Is Jakarta Authentication specification going to replace the 
authentication part of Jakarta Servlet specification?


Unlikely.


   2.  Are current authenticatiors from Tomcat (FORM, SPNEGO, SSL, HTTP DIGEST, 
HTTP BASIC, SSO) going to be implemented as Jakarta Authentication providers in 
future versions of Tomcat?


This has been discussed in the past but there is little motivation to do 
so as there are no obvious benefits and possible negative performance 
impacts.



   3.  Is any effort to introduce in Jakarta standards + Tomcat an authentcator 
of type 2FA?


No plans I am aware of.

Mark

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

Re: PKCS#8 encryption algorithm unrecognized

2024-03-19 Thread Mark Thomas


On 19/03/2024 18:18, Timothy Resh wrote:





where the . is the fqdn

This works fine *until* Tomcat 9.0.83 and now we get the following listed
below. I have read some of the
https://bz-he-de.apache.org/bugzilla/show_bug.cgi?id=67675 bugs and ask for
help.
The certificates are being created using openssl 3.013.  Please note the
encrypted password to the p12 keystore.  There was a message saying this
was going to be fixed in a January release.
I just tested 9.0.87 and the error is the same.  The ASN.1 is  OBJECT
IDENTIFIER=Sha256WithRSAEncryption (1.2.840.113549.1.1.11)

Does anyone have some suggestions for a fix?


Please provide a set of OpenSSL commands that create a problematic, 
self-signed certificate for localhost. This will save us a *lot* of time.


Mark




Thanks Mark Resh


15-Mar-2024 18:27:37.621 WARNING [main]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets the
[ciphers] attribute in a manner consistent with the latest OpenSSL
development branch. Some of the specified [ciphers] are not supported by
the configured SSL engine for this connector (which may use JSSE or an
older OpenSSL version) and have been skipped:
[[TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256,
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256]]
15-Mar-2024 18:27:37.636 SEVERE [main]
org.apache.catalina.util.LifecycleBase.handleSubClassException Failed to
initialize component [Connector["https-openssl-apr-192.168.56.1-8443"]]
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1011)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:554)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:1039)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:127)
at org.apache.catalina.startup.Catalina.load(Catalina.java:724)
at org.apache.catalina.startup.Catalina.load(Catalina.java:746)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:307)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:477)
Caused by: java.lang.IllegalArgumentException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:467)
at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:433)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1332)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1345)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:654)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:75)
at org.apache.catalina.connector.Connector.initInternal(Connector.java:1009)
... 13 more
Caused by: java.security.NoSuchAlgorithmException: The PKCS#8 encryption
algorithm with DER encoded OID of [2a864886f70d010c0103] was not recognised
at
org.apache.tomcat.util.net.jsse.PEMFile$Part.toPrivateKey(PEMFile.java:379)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:213)
at org.apache.tomcat.util.net.jsse.PEMFile.(PEMFile.java:141)
at
org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.java:355)
at
org.apache.tomcat.util.net.openssl.OpenSSLUtil.getKeyManagers(OpenSSLUtil.java:108)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:268)
at
org.apache.tomcat.util.net.AprEndpoint.createSSLContext(AprEndpoint.java:465)
... 19 more
15-Mar-2024 18:27:37.636 INFO [main]
org.apache.catalina.startup.Catalina.load Server initialization in [1655]
milliseconds



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

Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

2024-03-19 Thread Mark Thomas

On 19/03/2024 07:54, Ivano Luberti wrote:

Could there be a regression also in 9.0.86

Yes. It will be fixed in 9.0.88.

Mark

Because I had a similar issue (reload tls didn't work) but It was the
first time I was doing that on that tomcat instance and I had assumed
there was some misconfiguration, even though certificates where server
correctly but the wrong expiration date and after restarting tomcat the
certificates were served with correct dates

Il 18/03/2024 21:20, Mark Thomas ha scritto:

On 18/03/2024 08:21, Mark Thomas wrote:

On 17/03/2024 15:26, Justin Y wrote:

Hi Everyone --

I've spent a few hours scratching my head and then diving into
the source code of 10.1.19 to figure out what's going on.

Could you test with 10.1.18? I'm wondering if the user provided
SSLContext changes in 10.1.19 have triggered a regression.

Never mind. I've just confirmed that those changes did trigger a
regression. I'll commit a fix shortly and it will be in the next round
of releases.

Mark

I'm using the /TLSCertificateReloadListener/
<https://github.com/apache/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d> to reload files that will be (eventually) managed by Let's Encrypt.

Although it does detect the expiration and log that things were
reloaded, the new files are never read and the old cert & key are
used forever, causing the trigger to reoccur again and again.

The only way I can get the system to function correctly is if I,
during debugging in Eclipse with the matching Tomcat source, null
out the "sslContext" on line 102 of AbstractJsseEndpoint.

From what I can tell, the SSLHostConfigCertificate objects keep a
copy of an SSLContext and during the JMX unregister and register the
same SSLContext is transferred, which never takes in the same files.

From my limited knowledge, it appears the files will never be
loaded unless a new instance of SSLContext is created.

I've tried both APR (OpenSSL) and native JSSE configurations. One
thing of note - during testing, I'm only using PEM-based cert and
key files (no CA).

I have tried writing my own /TLSCertificateReloadListener/
<https://github.com/apache/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d> implementation but have found no clear way to null the SSLContext of the (determined expired) SSLHostConfigCertificate objects to allow a reload.

I appreciate any suggestions!

-- Justin

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

Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

2024-03-18 Thread Mark Thomas

On 18/03/2024 08:21, Mark Thomas wrote:

On 17/03/2024 15:26, Justin Y wrote:

Hi Everyone --

I've spent a few hours scratching my head and then diving into the
source code of 10.1.19 to figure out what's going on.

Could you test with 10.1.18? I'm wondering if the user provided
SSLContext changes in 10.1.19 have triggered a regression.

Never mind. I've just confirmed that those changes did trigger a
regression. I'll commit a fix shortly and it will be in the next round
of releases.

Mark

I'm using the /TLSCertificateReloadListener/
<https://github.com/apache/tomcat/commit/144cb84e1a9777ef63c30f6021b562cc04aa708d> to reload files that will be (eventually) managed by Let's Encrypt.

Although it does detect the expiration and log that things were
reloaded, the new files are never read and the old cert & key are used
forever, causing the trigger to reoccur again and again.

The only way I can get the system to function correctly is if I,
during debugging in Eclipse with the matching Tomcat source, null out
the "sslContext" on line 102 of AbstractJsseEndpoint.

From my limited knowledge, it appears the files will never be
loaded unless a new instance of SSLContext is created.

I've tried both APR (OpenSSL) and native JSSE configurations. One
thing of note - during testing, I'm only using PEM-based cert and key
files (no CA).

I appreciate any suggestions!

-- Justin

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

Re: problems with partitioned cookies

2024-03-18 Thread Mark Thomas


On 18/03/2024 15:16, info@klawitter.de wrote:


What am I doing wrong here? (Tomcat 9.0.82)


https://tomcat.apache.org/tomcat-9.0-doc/changelog.html

Search for "partitioned"

The problem is you are using Tomcat 9.0.82. Support for a default 
partitioned attribute wasn't added until 9.0.85.


Mark

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

Re: Regression in mutual authentication in 9.0.86+?

2024-03-18 Thread Mark Thomas

I've just tested 9.0.x and mutual TLS authentication appears to be 
working as expected.


I suggest starting with testing a simple JSP that echoes that attribute 
and if you still see the issue, provide us with your configuration. Note 
that the issue may be related to the certs you are using so the 
configuration information should include steps to recreate the TLS certs 
with keystore, OpenSSL or similar.


On 15/03/2024 00:48, Amit Pande wrote:

Hello all,

I have upgraded the Tomcat version from 9.0.85 to 9.0.86 (and tried with 9.0.87 
too).

Some of our tests which involve on mutual authentication ("certificateVerification = 
optional") have started to fail.

In tests where the client does pass the certificate, I didn't see any SSL handshake 
errors (with SSL handshake debugging enabled) but 
"javax.servlet.request.X509Certificate" attribute wasn't set. This is the 
attribute the application needs for further validations.


Have you confirmed that the certificate was sent from the client?


Could anyone please give pointers on how to debug this further?

Any code pointers where Tomcat sets this 
"javax.servlet.request.X509Certificate" attribute?


git clone
grep


Also, one more question - with optional certificate verification, the 
connection doesn't fail if certificate is not passed. But connection will fail 
if SSL handshake fails when a certificate is passed by client, is that correct 
understanding?


Yes, that is what I would expect.

Mark

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

Re: TLSCertificateReloadListener Detects Expiration But Never Reads New Cert & Key Files

2024-03-18 Thread Mark Thomas

On 17/03/2024 15:26, Justin Y wrote:

Hi Everyone --

I've spent a few hours scratching my head and then diving into the
source code of 10.1.19 to figure out what's going on.

Could you test with 10.1.18? I'm wondering if the user provided
SSLContext changes in 10.1.19 have triggered a regression.

Mark

I'm using the /TLSCertificateReloadListener/
to reload files that will be (eventually) managed by Let's Encrypt.

Although it does detect the expiration and log that things were
reloaded, the new files are never read and the old cert & key are used
forever, causing the trigger to reoccur again and again.

The only way I can get the system to function correctly is if I,
during debugging in Eclipse with the matching Tomcat source, null out
the "sslContext" on line 102 of AbstractJsseEndpoint.

From my limited knowledge, it appears the files will never be loaded
unless a new instance of SSLContext is created.

I've tried both APR (OpenSSL) and native JSSE configurations. One
thing of note - during testing, I'm only using PEM-based cert and key
files (no CA).

I have tried writing my own /TLSCertificateReloadListener/
implementation but have found no clear way to null the SSLContext of the (determined expired) SSLHostConfigCertificate objects to allow a reload.

I appreciate any suggestions!

-- Justin

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

[ANN] Apache Tomcat 11.0.0-M18 (alpha) available

2024-03-14 Thread Mark Thomas


The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M18 (alpha).

Apache Tomcat 11 is an open source software implementation of the
Jakarta Servlet, Jakarta Server Pages, Jakarta Expression Language,
Jakarta WebSocket, Jakarta Authentication and Jakarta Annotations
specifications.

Users of Tomcat 10 onwards should be aware that, as a result of the move
from Java EE to Jakarta EE as part of the transfer of Java EE to the
Eclipse Foundation, the primary package for all implemented APIs has
changed from javax.* to jakarta.*. This will almost certainly require
code changes to enable applications to migrate from Tomcat 9 and earlier
to Tomcat 10 and later. A migration tool is available to aid this process.

Apache Tomcat 11.0.0-M18 is a milestone release of the 11.0.x branch and 
has been made to provide users with early access to the new features in 
Apache Tomcat 11.0.x so that they may provide feedback. The notable 
changes compared to 11.0.0-M17 include:


- Reduce minimum Java version to Java 17

- When restoring a saved POST request after a successful FORM
  authentication, ensure that neither the URI, the query string no
  the protocol are corrupted when restoring the request body.

- Align error handling for Writer and OutputStream. Ensure use of either
  once the response has been recycled triggers a NullPointerException
  provided that discardFacades is configured with the default value of
  true.

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/tomcat-11.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-11.cgi

Migration guides from Apache Tomcat 8.5.x, 9.0.x and 10.1.x:
http://tomcat.apache.org/migration.html

Enjoy!

- The Apache Tomcat team

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

Re: reloading context with manager-script

2024-03-14 Thread Mark Thomas

On 12/03/2024 13:47, Christopher Schultz wrote:

Greg and Mark,

On 3/12/24 05:00, Greg Huber wrote:

On 11/03/2024 18:17, Christopher Schultz wrote:

Mark,

On 3/10/24 08:49, Mark Thomas wrote:

On 10/03/2024 10:50, Greg Huber wrote:

Hello,

Using http://tomcat/manager-app/text/reload?path=/

When I reload an application (in java), I get a reply

OK - Reloaded application at context path [/]

but when the application is not present I get this reply:

FAIL - No context exists named []

Is it intentional that the fail shows the ascii code rather than 
the slash like on the OK?

Yes.

If the provided context exists then we know that the name is HTML 
safe since all valid context names are HTML safe. In this case there 
is no escaping.

If the context does not exist then the provided content name may not 
be HTML safe (it could be a deliberate XSS attempt) hence it is 
escaped.

What is the Content-Type of the response? The URL implies that it's a 
text interface, not HTML.

 >
 > Running it on the browser I get
 >
 > Content-Type : text/plain;charset=utf-8

Yeah, that's what I was expecting.

I think HTML escaping is not appropriate, here.

Agreed. The challenge is that you don't have the context to determine if 
the request originates from the HTMLManagerServlet.

It may be possible to refactor the escaping so it happens in 
HTMLManagerServlet instead.

Mark

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

Re: What does the number preceding the catalina.org.apache.juli.AsyncFileHandler in Tomcat's conf/logging.properties mean?

2024-03-14 Thread Mark Thomas


On 14/03/2024 11:51, Vincent Daniel wrote:

Thank you so much.
I am ashamed that I did not read the documentation carefully.


No problem. It is only a single line in the docs and it helps a lot if 
you know what you are looking for.


Mark



On Thu, Mar 14, 2024 at 7:46 PM Mark Thomas  wrote:


On 14/03/2024 11:36, Vincent Daniel wrote:

Hi, community

When I configured Tomcat logs, I found the following configuration in
logging.properties

1catalina.org.apache.juli.AsyncFileHandler
2localhost.org.apache.juli.AsyncFileHandler
3manager.org.apache.juli.AsyncFileHandler
4host-manager.org.apache.juli.AsyncFileHandler

I am not sure what the numbers in front of them mean?

I checked the Tomcat documentation > Logging chapter and found no
relevant instructions. I also searched the Tomcat source code
repository on Github, and only found document-related content.

Can someone explain this please?


https://tomcat.apache.org/tomcat-11.0-doc/logging.html

Search for the word "prefix".

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: What does the number preceding the catalina.org.apache.juli.AsyncFileHandler in Tomcat's conf/logging.properties mean?

2024-03-14 Thread Mark Thomas


On 14/03/2024 11:36, Vincent Daniel wrote:

Hi, community

When I configured Tomcat logs, I found the following configuration in
logging.properties

1catalina.org.apache.juli.AsyncFileHandler
2localhost.org.apache.juli.AsyncFileHandler
3manager.org.apache.juli.AsyncFileHandler
4host-manager.org.apache.juli.AsyncFileHandler

I am not sure what the numbers in front of them mean?

I checked the Tomcat documentation > Logging chapter and found no
relevant instructions. I also searched the Tomcat source code
repository on Github, and only found document-related content.

Can someone explain this please?


https://tomcat.apache.org/tomcat-11.0-doc/logging.html

Search for the word "prefix".

Mark

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

[SECURITY] CVE-2024-23672 Apache Tomcat - Denial of Service

2024-03-13 Thread Mark Thomas


CVE-2024-23672 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
It was possible for a WebSocket client to keep a WebSocket connection 
open leading to increased resource consumption.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

History:
2024-03-13 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html
[4] https://tomcat.apache.org/security-8.html

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

[SECURITY] CVE-2024-24549 Apache Tomcat - Denial of Service

2024-03-13 Thread Mark Thomas


CVE-2024-24549 Apache Tomcat - Denial of Service

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 11.0.0-M1 to 11.0.0-M16
Apache Tomcat 10.1.0-M1 to 10.1.18
Apache Tomcat 9.0.0-M1 to 9.0.85
Apache Tomcat 8.5.0 to 8.5.98

Description:
When processing an HTTP/2 request, if the request exceeded any of the 
configured limits for headers, the associated HTTP/2 stream was not 
reset until after all of the headers had been processed.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 11.0.0-M17 or later
- Upgrade to Apache Tomcat 10.1.19 or later
- Upgrade to Apache Tomcat 9.0.86 or later
- Upgrade to Apache Tomcat 8.5.99 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by Bartek Nowotarski (https://nowotarski.info/).


History:
2024-03-13 Original advisory

References:
[1] https://tomcat.apache.org/security-11.html
[2] https://tomcat.apache.org/security-10.html
[3] https://tomcat.apache.org/security-9.html
[4] https://tomcat.apache.org/security-8.html

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

Re: Tomcat 9 returning 404 for audio files

2024-03-11 Thread Mark Thomas


On 11/03/2024 11:31, Sam wrote:

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


Is there any chance of an attempt to access the file before it is 
created? The resources implementation can cache "not found" results for 
a short period of time.


You might want to test the code with a simple text file to determine 
whether file type is a factor (which seems unlikely but you never know).


Mark




On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:


On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files

playback.


When loading a page that contains an audio file. First time Tomcat

returns

404 error but if reloading the page, audio file is loaded properly and no
error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working without
any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log

entry

when I try to open the audio file first time. I can see 404 being

returned

from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:


 
bottom:0;"




  

 

I've tried relative path and full path but result is the same in both

cases.


I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



-
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: contextVersion NullPointerException due to race condition

2024-03-11 Thread Mark Thomas


On 29/02/2024 13:32, FRANTS Patrick wrote:

Not sure this is the right mailing list or that it should go to dev.


users@ is fine. Generally, if you aren't sure use users@.


One of our unit tests will occasionally have a null pointer exception durin=

g shutdown. Unfortunately I have not been able to create a small reproducti=

on yet.

The scenario is as follows.

   *   SpringApplicationShutdownHook calls Tomcat.stop() and a contextVersio=

n used by a SSE request is removed through MapperListener.unregisterContext

   *   A tomcat thread processes an IOException ("Connection reset by peer")=

  exception for that SSE request and ends up in Mapper.map() and gets a null=

  result

from contextObjectToContextVersionMap.get(context). In the end this causes =

a NullPointerException in internalMapWrapper when

calling contextVersion.path.length()


This seems to be only in Tomcat 10.1.12+. Tomcat 10.1.11 does not have the =

problem.


I think I can see what the problem is.

When stopping a Context (which can happen during shutdown or during 
normal usage) Tomcat first removes the Context from the mapper to 
prevent any further requests from reaching the Context, then it stops 
the Context. That in turn stops the individual Wrappers (servlets). Note 
that that process waits for in progress requests to complete before the 
Wrapper is stopped.


The problem here is that the application won't be notified that it is 
being stopped until the Context is stopped. But RequestDistaptchers will 
start failing from the point the Context is removed from the mapper.


Without some major refactoring (and I'm not even sure that would be 
successful) I don't think we can address this. The best I think we could 
do is ensure that getRequestDispatcher(String) returns null in this 
case. Although that might just move the source of the NPE to your code.


Mark

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

Re: Tomcat not syncing existing sessions on restart

2024-03-11 Thread Mark Thomas


On 10/03/2024 16:59, Manak Bisht wrote:

On Fri, Feb 9, 2024 at 4:45 PM Mark Thomas  wrote:


Using 0.0.0.0 as the address for the receiver is going to cause
problems. I see similar issues with 11.0.x as 8.5.x. I haven't dug too
deeply into things as a) I am short of time and b) I'm not convinced
this should/could work anyway.

What seems to happen is that the use of 0.0.0.0 confuses the cluster as
to which node is which - I think because multiple nodes are using
0.0.0.0. That causes the failure of the initial state synchronisation.



Yes, this was indeed the problem. I chose 0.0.0.0 because binding to the
host's ip threw the following error -


01-Mar-2024 22:30:32.315 SEVERE [main]
org.apache.catalina.tribes.transport.nio.NioReceiver.start Unable to start
cluster receiver
  java.net.BindException: Cannot assign requested address


The full stack trace is available in my previous mail.

To identify the problem, I ran my application outside the container, where
I did not encounter the above error. This led me to investigate on the
Docker side of things. By default, a Docker container uses a bridge
network, so binding to the host's ip address from inside the container is
simply not possible even when the receiver port has been correctly mapped.
I was able to get it to work by passing the --network=host flag to my
docker create command. This puts the container inside the host's network,
essentially de-containerizing its networking.
Although this works, this is not desirable because this opens every port on
the container, increasing the surface area for security and debugging.
0.0.0.0 is a natural choice and is used by a lot of applications running on
Docker, even the official Tomcat image on Docker Hub does so.


There is no official Docker image provided by the Tomcat project.


I am no expert on Docker or Tomcat, however, I don't think this is ideal.
Docker has become so ubiquitous that I couldn't imagine deploying without
it, but using clustering makes me lose some of the benefits of it. I have
not looked into it, but this might also impact the BackupManager because it
also requires a Receiver element.

On Mon, Feb 12, 2024 at 8:52 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


If this is known to essentially always not-work... should we log
something at startup?


I think this is the least that we could do, I am willing to work on this.
However, I also think that this should be looked into deeper to solve the
actual problem.


Thinking about this a little more (although I am still short on time so 
haven't investigated) I wonder if the issue is that a node needs to 
advertise to other nodes what IP address it is listening on. If if 
advertises 0.0.0.0 the other nodes have no way to contact it. Further 
(and you can look at the acceptor unlock code for the details) trying to 
determine a valid IP address to provide to other nodes is non-trivial 
(and the acceptor case is only looking at localhost, not across a network).



I understand that this discussion might be more fit for the dev mailing
list, please let me know if you think the above holds merit, and I will
move it there.


You start to get into having to separate the IP address a node listens 
on and the IP address it advertises for other nodes to contact it 
(similar to HTTP or JMX behind a proxy)


I'm not a docker expert but it looks to me from a quick Google search 
that the expectation in this case is that you should use swarm mode 
which provides an overlay network across the nodes.


Mark

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

Re: Tomcat 9 returning 404 for audio files

2024-03-11 Thread Mark Thomas


On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files playback.

When loading a page that contains an audio file. First time Tomcat returns
404 error but if reloading the page, audio file is loaded properly and no
error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working without
any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log entry
when I try to open the audio file first time. I can see 404 being returned
from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:





   
 
   


I've tried relative path and full path but result is the same in both cases.

I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



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

Re: reloading context with manager-script

2024-03-10 Thread Mark Thomas


On 10/03/2024 10:50, Greg Huber wrote:

Hello,

Using http://tomcat/manager-app/text/reload?path=/

When I reload an application (in java), I get a reply

OK - Reloaded application at context path [/]

but when the application is not present I get this reply:

FAIL - No context exists named []

Is it intentional that the fail shows the ascii code rather than the 
slash like on the OK?


Yes.

If the provided context exists then we know that the name is HTML safe 
since all valid context names are HTML safe. In this case there is no 
escaping.


If the context does not exist then the provided content name may not be 
HTML safe (it could be a deliberate XSS attempt) hence it is escaped.


Mark

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

Re: Need help for a problem on migrating from Tomcat-8 to Tomcat-9

2024-02-26 Thread Mark Thomas


On 26/02/2024 06:11, Saha, Rajib wrote:

Hi Experts,

In our product, we are using Tomcat [OriginalFileName:  prunsrv.exe] for 
creating a service[Say, Service-A]. It's a huge product running in market for 
last 20 years.
We are in progress of moving from Tomcat-8 to tomcat-9.

When we are creating the Service-A with Tomcat-8 [tomcat8.exe]. In "Services" desktop app, we can 
see the service is created with "Local System" in "Log On as".
When we are creating the Service-A with Tomcat-9 [tomcat9.exe]. in "Services" desktop app, we can 
see the service is created with "Local service" in "Log On as".

Looks like "Local service" has less power than "Local System".
Due to it, Service-A created with Tomcat-9 failing for several operation inside 
product.


That should be a security concern. Local System is broadly equivalent to 
local administrator. You generally don't want to be running Tomcat under 
Local System.



Can somebody suggest, how we can create a service with tomcat-9, with the privilege of 
"Local System"?


Have you looked at the documentation?

https://tomcat.apache.org/tomcat-9.0-doc/windows-service-howto.html

Look for "--ServiceUser"

Mark

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

Re: A curious case of Tomcat 10.1.x NIO(1) acceptor not stopping clearly on some setups

2024-02-26 Thread Mark Thomas

On 25/02/2024 18:18, Michał Szymborski wrote:

0.0.0.0 is shorthand for "all configured IP address". Tomcat can't use
that address to establish a connection to the Acceptor thread so it has
to try and deduce a valid IP local address from the network
configuration information exposed through the Java APIs.

https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L1164

It started picking up interfaces to use, and it stopped at the first
non-loopback non-link local address, which also happens to be some sort
of a bridge network for one of my VMs. I don't quite know why there is
no routing set up, but this interface should not have been picked in the
first place.

It is a local IP address so as far as Tomcat can see it should be valid
to connect to the Acceptor.

I'll take a look at how it works on my work laptop with MacOs, but I'd
wager a guess that some corporate VPNs have interfaces which have messed
up routing as well. Can't tell if it's a bug or a feature, but it sure
is unexpected. Making this timeout for acceptor shutdown configurable
would be one sort of band-aid.

It is configurable. socket.unlockTimeout. Documented default is 250ms
although looking at the code it appears there is a minimum of 2000ms -
need to see why that is.

Configuring a specific address (even 127.0.0.1) for the Connector would
also address this.

Mark

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

Re: NoClassDefFoundError for SSL operations

2024-02-22 Thread Mark Thomas


On 23/02/2024 01:14, bigelytechnol...@yahoo.com wrote:

This spammer has been unsubscribed and banned from re-subscribing.

Mark

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

Re: The custom 404 page of Tomcat8 suddenly becomes invalid

2024-02-19 Thread Mark Thomas


On 19/02/2024 01:35, LeventLee wrote:

Hello,


Here is my information：
openjdk version "1.8.0_345" | OpenJDK Runtime Environment (build 1.8.0_345-b01) 
| OpenJDK 64-Bit Server VM (build 25.345-b01, mixed mode)

Linux 5.10.134-12.al8.x86_64
Apache Tomcat/8.0.24


That version is over 8 years old.

The 8.0.x has been unsupported for more than 5 years (since 30 Jun 2018).

Note that 8.5.x will reach EOL on 31 March 2024.

You *really* need to upgrade.

Upgrading to 9.0.x will be easiest as it still uses the Java EE APIs. 
You may want to consider an upgrade to 10.1.x but that will be more work 
is there is a package change related to the Java EE to Jakarta EE change.




Now, please let me explain the problems encountered：
Previously, I set up a custom 404 page in tomcat's WEB INF/web.xml, so that 
once the client accesses a non-existent page, it will return to this 404 page. 
However, not long ago, after Tomcat restarted, it was unable to return the 
custom 404 page and only returned the browser's 404 page.
I have checked the localhost logs of Tomcat and found a large number of 
errors:org.apache.catalina.core.ApplicationContext.log ssi:
Can't serve file:/WEB-INF/index/my404page


Is that the full error message?

Why is SSI involved?

Is the rest of the application working correctly?

Mark


But the custom 404 page does exist,and the path is right.
I want to figure out what this error means. If possible, maybe can try 
this problem.


Thanks in advance for your suggestions!


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

Re: Tomcat Manager 403's with LDAP Realm

2024-02-19 Thread Mark Thomas


On 17/02/2024 21:42, Dan McLaughlin wrote:

We've had the same LDAP realm configured for probably 10 years, and the
same roles in our LDAP for probably the same.  We have 4 roles configured
in LDAP manager-gui, manager-jmx, manager-script, and manager-status.  My
user only has the manager-gui role.  Everything has worked fine up until
about the time we moved to Tomcat 10.1.   Now, I can log in just fine, but
if I try to click stop, start, reload, or undeploy, I always get a 403.  I
don't see any errors in the logs telling me why.  Does anyone have pointers
on debugging this?  My user only has the manager-gui role; the only users
with the JMX or script roles are the users I use for Nagios monitoring of
JMX parameters.

FYI... I can't reproduce it using Tomcat 10.1 running in docker using the
same LDAP realm configuration, so that tells me it has nothing to do with
the roles not being correct...and they should be correct since they haven't
changed since I set things up probably 10 years ago.   The only change has
been the upgrade of Tomcat.  Could CSRF somehow be involved?  It might be
about when CSRF was introduced that I started having issues. I haven't
tried removing the filter yet, only because it really doesn't seem related
based on my understanding of how the filter works.

If someone knows the specific packages, I might want to bump up the logging
on; that would probably be most helpful at this point.


Try:

org.apache.catalina.filters.CsrfPreventionFilter.level=ALL

Mark

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

Re: Compile with JDK 17, run on JRE 11?

2024-02-17 Thread Mark Thomas


On 17/02/2024 16:01, Troels Arvin wrote:

Hello,

Since 9.0.83, building Tomcat has required JDK 17, according to the 
release notes.


Is it possible to take the resulting binaries and run them on JRE 11?


Yes. The minimum Java version at runtime (8) is unchanged.

Mark

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

Re: Long lasting websocket sessions

2024-02-16 Thread Mark Thomas


On 09/02/2024 13:47, Alex O'Ree wrote:

I've been experimenting with tomcat 9.x in seeing how long i can get a web
socket session to last. I'm currently struggling to get past 30 minutes or
so. Looking for guidance on how to best increase this or if this is a bad
idea.

Here's the current configuration and what i've tried thus far:

The server continuously streams messages the client, about 1 per second
The client periodically (every 30 seconds) sends a keep alive text message
back to the server
The server side endpoint sets the Session.setTimeout(0); according to the
docs, this should prevent timeouts
The server side WAR file/WEB-INF/web.xml had a session timeout defined at
15 minutes but i then removed it in order to increase the websocket
duration.

Despite all this, both the client and server log a session disconnect, but
i'm still not sure what the reasoning is. I'm still assuming it's some kind
of timeout mechanism.


I think you need to do a little more investigation with your 
application. I've been running the snake WebSocket example on 9.0.x for 
over any hour wihtout any issues.


Mark

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

Re: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-13 Thread Mark Thomas


On 09/02/2024 16:26, Rick Noel wrote:

Thank you so much Mark for working with me on this issue!
I am taking your recommendation to create a   webapps-javaee directory and 
place my Tomcat 9 running war file into
that dir so that Tomcat does the compile correctly.

Only problem is that now I cannot figure out what is the correct URL path to my 
servlet!

When I place the .war, the old way with the .war  being in  
webapps/transaction,my tomcat cat log says...

Deploying web application directory [C:\apache-tomcat-9.0.73\webapps\transaction
And I see my application at
C:\apache-tomcat-9.0.73\webapps\transaction\ROOT##0001

And I can hit my servlet via...

http://localhost:8588/XmlRpc


That is all very non-standard.

What I would expect to see is:

foo.war deployed to $CATALINA_BASE/webapps/foo.war and then accessed at 
http://localhost:port/foo


In server.xml what do you have configured for the Host's appBase ? Is it 
"webapps/transaction" ?


Mark




BUT when I place my .war in webapps-javaee\transaction the tomcat cat log 
says..

Deploying web application directory 
[C:\apache-tomcat-10.1.18\webapps-javaee\transaction\transaction

And I cannot hit either..

http://localhost:8588/XmlRpc
or
http://localhost:8588/transaction/XmlRpc


The creation of the 
C:\apache-tomcat-10.1.18\webapps-javaee\transaction\transaction  directory is 
baffling me
See attached file

I expect only to see the creation of a 
C:\apache-tomcat-10.1.18\webapps-javaee\transaction\ROOT##0001 directory.
That is where I believe my application to be

Here is how I have my context defined in server.xml..



Is my server.xml wrong?
When I place my .war in   webapps-javaee\transaction   dir?




-Original Message-----
From: Mark Thomas 
Sent: Thursday, February 8, 2024 5:45 PM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

[You don't often get email from ma...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

Confirmed this is user error. There is no bug in the migration tool.

Steps to demonstrate this:

- Create new, blank Eclipse dynamic web project
- Add provided servlet code
- Add required libraries
- Remove referenced to internal logging code
- Add web.xml with basic mapping to "/test"
- Export WAR file
- Deploy to Tomcat
- Start Tomcat
- Request servlet

Servlet loads and then reports an exception during init. That is fine.
It proves that the servlet was loaded which is all we care about at this point.

- Use migration tool to migrate WAR
- Deploy migrated WAR to Tomcat 10.1.x
- Start Tomcat
- Request servlet

Servlet loads and then reports an exception during init. Again, this is fine as 
it proves that the Servlet has been converted correctly and can be loaded by 
Tomcat 10.1.x.

Best guess, the Eclipse project isn't configured correctly to compile the web 
application for Tomcat 10.1.x.

At this point the simplest solution is likely to be:

- take the WAR file that works on Tomcat 9
- drop in webapps-javaee in Tomcat 10 and let Tomcat convert it
automatically

Mark


On 08/02/2024 20:28, Rick Noel wrote:

No I cannot compile from command line.

But I do not really care how eclipse compiles my class anyway.
All I know is that eclipse compiles the class without errors. Using
the jars I tell it to. (all the jars run through the migration tool) But Tomcat 
10 can not compile the class using those same migrated jar files.

And my class has no use of javax.server  classes in it.
All the javax.server classes are only in the third part jar files
which are supposed to have been converted to use  jakarta.server
classes

Is this not a bug with Tomcat migration tool?

Again here is my class that does not compile on Tomcat 10...
It has no reference to  javax.server


package com.radiovoodoo.xmlrpc;

import java.io.IOException;
import java.net.MalformedURLException; import java.net.URL;

import org.apache.xmlrpc.XmlRpcException;
import org.apache.xmlrpc.XmlRpcRequest; import
org.apache.xmlrpc.server.AbstractReflectiveHandlerMapping.Authenticati
onHandler; import org.apache.xmlrpc.server.XmlRpcHandlerMapping;
import org.apache.xmlrpc.server.PropertyHandlerMapping;
import org.apache.xmlrpc.webserver.XmlRpcServlet;

import com.radiovoodoo.util.Log;

/**
   * @(#)RVXmlRpcServlet.java
   *
   * new XmlRpcServlet, which extends the default Apache XmlRpcServlet
   *
   * @author  Hank Zill 
   * @version 1.0
   *
   * Copyright(c) 2005 RadioVoodoo, Inc. All Rights Reserved.
   */

public class RVXmlRpcServlet
 extends XmlRpcServlet
{
 /**
  *  this init parameter defines the path to the property file from
  *  which to load the XML RPC handler mappings.
  *
  *  the path is relative to the CLASSPATH
  */
 public static final String RESOURCE_PATH = "property-file-path";

 protected XmlRpcHandlerMapping newXmlRpcHandlerMapping()

Re: [ANN] Apache Tomcat Native 1.3.0 released

2024-02-13 Thread Mark Thomas


On 13/02/2024 10:21, Michael Osipov wrote:

On 2024/02/13 08:46:42 Mark Thomas wrote:

The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 1.3.0 stable.

The key features of this release are:

- The minimum supported OpenSSL version is 1.1.1
- The minimum supported APR version in 1.6.3
- The windows binaries in this release have been built with OpenSSL
3.0.13

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html


This link is wrong, it leads me to Tomcat Native 2.0.x.


Sorry. Copy/paste error. The correct link is:

https://tomcat.apache.org/native-1.3-doc/miscellaneous/changelog.html

Mark

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

[ANN] Apache Tomcat Native 1.3.0 released

2024-02-13 Thread Mark Thomas


The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 1.3.0 stable.

The key features of this release are:

- The minimum supported OpenSSL version is 1.1.1
- The minimum supported APR version in 1.6.3
- The windows binaries in this release have been built with OpenSSL
  3.0.13

Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html

Downloads:
http://tomcat.apache.org/download-native.cgi


The Apache Tomcat Native Library 1.3.x provides portable API for 
features not found in contemporary JDK's. It uses Apache Portable 
Runtime as operating system abstraction layer and OpenSSL for SSL 
networking and allows optimal performance in production environments.


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

[ANN] Apache Tomcat Native 2.0.7 released

2024-02-13 Thread Mark Thomas


The Apache Tomcat team announces the immediate availability of Apache
Tomcat Native 2.0.7 stable.

The key features of this release are:

- Align default pass phrase prompt with httpd on Windows
- The windows binaries in this release have been built with OpenSSL
  3.0.13

The 2.0.x branch is primarily intended for use with Tomcat 10.1.x or 
later but can be used with earlier versions as long as the APR/native 
connector is not used.


Please refer to the change log for the complete list of changes:
http://tomcat.apache.org/native-doc/miscellaneous/changelog.html

Downloads:
http://tomcat.apache.org/download-native.cgi

The Apache Tomcat Native Library 2.0.x provides an API for using OpenSSL 
for SSL networking with Apache Tomcat.


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

Re: Tomcat not syncing existing sessions on restart

2024-02-09 Thread Mark Thomas


On 09/02/2024 07:51, Manak Bisht wrote:

On Fri, Feb 9, 2024 at 3:25 AM Mark Thomas  wrote:


Same JRE?


  Yes, 8.0.402

Generally, I wouldn't use 0.0.0.0, I'd use a specific IP address. I'm

not sure how the clustering would behave with 0.0.0.0


Using 0.0.0.0 as the address for the receiver is going to cause 
problems. I see similar issues with 11.0.x as 8.5.x. I haven't dug too 
deeply into things as a) I am short of time and b) I'm not convinced 
this should/could work anyway.


What seems to happen is that the use of 0.0.0.0 confuses the cluster as 
to which node is which - I think because multiple nodes are using 
0.0.0.0. That causes the failure of the initial state synchronisation.



That's the problem really. Using the DNS name or IP address causes the
following error -


I am as sure as I can be that the issue you are seeing is environmental. 
I have configured my test cluster with:


- your cluster configuration with changes to host names and IP addresses
- Java 8.0.402
- Tomcat 8.5.x

With the Receiver using address="0.0.0.0" I see the same issues you do. 
I'm not yet convinced that is a bug.


With the Receiver using address="hostname" the cluster starts but 
doesn't work. Examining the logs shows that is because the host name 
resolves to a loopback address. I'd class that as behaving as expected. 
I coudl always change the host's config if I wanted the name to resolve 
to the public IP.


With the Receiver using address="ip-address" the cluster start and log 
messages show that cluster state is exchanged within a few milliseconds.


That leads me to conclude that the BindException you see is a 
configuration and/or envornmental issue although I don't see why your 
simple test works but clustering doesn't. Perhaps a conflict with 
something else in your Tomcat configuration?


Somethign to try is starting Tomcat with the Receiver using 0.0.0.0 and 
then using nestat to see which address/port combinations are being used.


Mark

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

Re: Tomcat Instance unable to connect to DB with TCPS

2024-02-09 Thread Mark Thomas


On 09/02/2024 02:54, Kebret, Michael wrote:

Tomcat version 9.0.83 running on Linux  redhat 7 java 11.0.20.

When changing the protocol from TCP to TCPS in Catalina.properties and in 
server.xml we have attribute truststorePassword= (tested with both cleartext 
and encrypted) password connection is refused to the DB and get the below 
exceptions.


It isn't clear what configuration you are using. Please provide both the 
non-TLS and TLS configurations.



However, when we add -Djavax.net.ssl.trustStorePassword=cleartext to setenv.sh 
the connection is made successfully. Wanted to see if anyone has faced 
something similar or have any suggestions on how I can get TCPS working without 
having to use -D option in setenv.sh


My reading of [1] is that the property name is 
"javax.net.ssl.trustStorePassword" whether it is set as a connection 
property or as a system property. You seem to be using a connection 
property of "truststorePassword" which is a Tomcat property for HTTPS 
connections.


Mark

[1] https://www.oracle.com/docs/tech/wp-oracle-jdbc-thin-ssl.pdf

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

Re: Getting provider/properties from jaspic-providers.xml to my ServerAuthModule

2024-02-08 Thread Mark Thomas


On 08/02/2024 14:37, Ryan Esch wrote:

I'm using Tomcat 9. I have a provider in jaspic-providers.xml:





I am not sure how to get these properties to my
ServerAuthModule. I have a ServletContextListener and can see that the
jaspic-providers.xml file is being processed if I call:
AuthConfigFactory factory = AuthConfigFactory.getFactory()

It looks like
  I need to get the properties from the factory before calling:
factory.registerConfigProvider(
        new SimpleAuthConfigProvider(props, factory),
        "HttpServlet", null,
      "test");

I can't figure out how to get the properties from the
provider in the xml. If I hardcode the properties before passing them
into registerConfigProvider, the ServerAuthModule functions correctly.
Thanks!


You shouldn't need to call factory.registerConfigProvider() at all. That 
should happen automatically.


Are you sure the appContext is correct. The context path for the ROOT 
web application is "" (the empty string), not "/".


That would make the appContext "Catalina/localhost ".

Note that means it will only be applied to the ROOT web application.

Mark

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

Re: Persistent Manager Implementation Question

2024-02-08 Thread Mark Thomas


Try turning on ALL logging for the org.apache.catalina.session package.

Mark


On 08/02/2024 20:49, Miguel Vidal wrote:

  demo4.zip

Hello,

Specifications
Windows 10
Tomcat 8.5
this is a configuration question .
the tomcat specification that works :
https://tomcat.apache.org/tomcat-8.0-doc/config/manager.html

Im trying to configure correctly in 2 different applications : Persistent
Manager Implementation using a mysqldb as a datasource.

In one of them that is a legacy project i have some dependencies as


 org.springframework
 spring-core
 ${spring.framework.version}



 org.springframework
 spring-context
 ${spring.framework.version}


and it is already doing the registry of the sessions in my bd.
but in the other app im using a spring boot with the same configuration.
I'm not able to see any registration of the sessions in my db. After the
deploy of my app in a tomcat server and hit any resource example
/test/resource im able to see the response correctly but i just want to
know if this  Persistent Manager Implementation is only for legacy apps? or
why is running in one and in the other is not.

this is my xml for both




 
 
 

 
 jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;
 org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer;
 org.apache.tomcat.jdbc.pool.interceptor.ResetAbandonedTimer"

these 2  are the guides where i learn the mayority how to do it
https://svn.apache.org/repos/asf/tomcat/archive/tc4.1.x/trunk/container/catalina/docs/JDBCStore-howto.html
https://gerrytan.wordpress.com/2013/08/21/tomcat-7-jdbc-session-persistence/

im going to attach the code that im trying to know why is not working.



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

Re: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Mark Thomas


Confirmed this is user error. There is no bug in the migration tool.

Steps to demonstrate this:

- Create new, blank Eclipse dynamic web project
- Add provided servlet code
- Add required libraries
- Remove referenced to internal logging code
- Add web.xml with basic mapping to "/test"
- Export WAR file
- Deploy to Tomcat
- Start Tomcat
- Request servlet

Servlet loads and then reports an exception during init. That is fine. 
It proves that the servlet was loaded which is all we care about at this 
point.


- Use migration tool to migrate WAR
- Deploy migrated WAR to Tomcat 10.1.x
- Start Tomcat
- Request servlet

Servlet loads and then reports an exception during init. Again, this is 
fine as it proves that the Servlet has been converted correctly and can 
be loaded by Tomcat 10.1.x.


Best guess, the Eclipse project isn't configured correctly to compile 
the web application for Tomcat 10.1.x.


At this point the simplest solution is likely to be:

- take the WAR file that works on Tomcat 9
- drop in webapps-javaee in Tomcat 10 and let Tomcat convert it
  automatically

Mark


On 08/02/2024 20:28, Rick Noel wrote:

No I cannot compile from command line.

But I do not really care how eclipse compiles my class anyway.
All I know is that eclipse compiles the class without errors. Using the jars I 
tell it to. (all the jars run through the migration tool)
But Tomcat 10 can not compile the class using those same migrated jar files.

And my class has no use of javax.server  classes in it.
All the javax.server classes are only in the third part jar files which are 
supposed to have been converted to use  jakarta.server classes

Is this not a bug with Tomcat migration tool?

Again here is my class that does not compile on Tomcat 10...
It has no reference to  javax.server


package com.radiovoodoo.xmlrpc;

import java.io.IOException;
import java.net.MalformedURLException;
import java.net.URL;

import org.apache.xmlrpc.XmlRpcException;
import org.apache.xmlrpc.XmlRpcRequest;
import 
org.apache.xmlrpc.server.AbstractReflectiveHandlerMapping.AuthenticationHandler;
import org.apache.xmlrpc.server.XmlRpcHandlerMapping;
import org.apache.xmlrpc.server.PropertyHandlerMapping;
import org.apache.xmlrpc.webserver.XmlRpcServlet;

import com.radiovoodoo.util.Log;

/**
  * @(#)RVXmlRpcServlet.java
  *
  * new XmlRpcServlet, which extends the default Apache XmlRpcServlet
  *
  * @author  Hank Zill 
  * @version 1.0
  *
  * Copyright(c) 2005 RadioVoodoo, Inc. All Rights Reserved.
  */

public class RVXmlRpcServlet
extends XmlRpcServlet
{
/**
 *  this init parameter defines the path to the property file from
 *  which to load the XML RPC handler mappings.
 *
 *  the path is relative to the CLASSPATH
 */
public static final String RESOURCE_PATH = "property-file-path";

protected XmlRpcHandlerMapping newXmlRpcHandlerMapping()
   throws XmlRpcException
{
   PropertyHandlerMapping mapping = null;

   /* String resourcePath = getInitParameter( RESOURCE_PATH );
   
   if ( resourcePath == null )

   {
  throw new XmlRpcException( "No property file defined.  This servlet must have the 
init-param " + RESOURCE_PATH + " set." );
   } */
   String resourcePath = "somefile.properties";

   URL url = null;
  try {
url = getServletContext().getResource( resourcePath );
  } catch (MalformedURLException e1) {
throw new XmlRpcException( resourcePath + " " + e1 );
  }

   if (url == null)
   {
  throw new XmlRpcException("Failed to locate resource " + resourcePath 
);
   }
   try
   {
  mapping = newPropertyHandlerMapping(url);
   }
   catch (IOException e)
   {
  throw new XmlRpcException("Failed to load resource " + url + ": " + 
e.getMessage(), e);
   }

   if ( mapping == null )
  Log.debug( "HandlerMapping is null" );
   else
   {
  String[] methods = mapping.getListMethods();

  for ( int x = 0; x < methods.length; x++ )
  {
 Log.debug( "method: " + methods[x] );
  }
   }
   
   mapping.setAuthenticationHandler(new AuthenticationHandler() {

 //rick removed override annotaion so this class will compile on java 
1.5
//@Override
public boolean isAuthorized(XmlRpcRequest arg0) throws 
XmlRpcException {
return true;
}
   });

   return mapping;
}
}





Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Rob Sargent 
Sent: Thursday, February 8, 2024 1:54 PM
To: Tomcat Users List 
Subject: [EXT]Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

[You don't often get email from rsarg...@xmission.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]


On Feb 8, 2024, at 9:04 AM, Rick

Re: Tomcat not syncing existing sessions on restart

2024-02-08 Thread Mark Thomas


On 07/02/2024 11:43, Manak Bisht wrote:

I think I have narrowed down the problem. For Tomcat 9 (v9.0.85), using
0.0.0.0 for the local member and receiver works fine. However, the same
does not work in Tomcat 8.5 (v8.5.98).


Same JRE?

Generally, I wouldn't use 0.0.0.0, I'd use a specific IP address. I'm 
not sure how the clustering would behave with 0.0.0.0


Mark




Sincerely,
Manak Bisht


On Fri, Feb 2, 2024 at 9:41 PM Mark Thomas  wrote:


On 31/01/2024 13:33, Manak Bisht wrote:

I tried tweaking all the settings that I could think of but I am unable

to

sync sessions on restart even on a stock Tomcat 8.5.98 installation using
your provided war. I am unable to identify whether this is actually a bug
or something wrong with my configuration (this is far more likely). Could
you please share your server.xml? Did you make any other changes?

Sincerely,
Manak Bisht


Here is the cluster configuration from the first node my test environment:







  




  

  

  



  

  
  












-
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: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Mark Thomas


On 08/02/2024 14:38, Rick Noel wrote:

My code uses no javax.server  code other that what is in the third party jar.


Then you need to fix your build system that is compiling your code 
against the original xmlrpc-server3.1.3.jar rather than the migrated 
version.



Is it not the third part jar that needs to stop using javax.server ?


No. It is the compiled form of your code that has the issue.

When you compile your class it retains a reference to the version of 
org.apache.xmlrpc.webserver.XmlRpcServlet that it was compiled against. 
You can't just swap the xmlrpc-server3.1.3.jar at runtime. You have to 
use the migrated JAR at compile time as well.


Mark




Where in my code does it use javax.server, other than from classes in package 
org.apache.xmlrpc?

package com.radiovoodoo.xmlrpc;

import java.io.IOException;
import java.net.MalformedURLException;
import java.net.URL;

import org.apache.xmlrpc.XmlRpcException;
import org.apache.xmlrpc.XmlRpcRequest;
import 
org.apache.xmlrpc.server.AbstractReflectiveHandlerMapping.AuthenticationHandler;
import org.apache.xmlrpc.server.XmlRpcHandlerMapping;
import org.apache.xmlrpc.server.PropertyHandlerMapping;
import org.apache.xmlrpc.webserver.XmlRpcServlet;

import com.radiovoodoo.util.Log;

/**
  * @(#)RVXmlRpcServlet.java
  *
  * new XmlRpcServlet, which extends the default Apache XmlRpcServlet
  *
  * @author  Hank Zill 
  * @version 1.0
  *
  * Copyright(c) 2005 RadioVoodoo, Inc. All Rights Reserved.
  */

public class RVXmlRpcServlet
extends XmlRpcServlet
{
/**
 *  this init parameter defines the path to the property file from
 *  which to load the XML RPC handler mappings.
 *
 *  the path is relative to the CLASSPATH
 */
public static final String RESOURCE_PATH = "property-file-path";

protected XmlRpcHandlerMapping newXmlRpcHandlerMapping()
   throws XmlRpcException
{
   PropertyHandlerMapping mapping = null;

   /* String resourcePath = getInitParameter( RESOURCE_PATH );
   
   if ( resourcePath == null )

   {
  throw new XmlRpcException( "No property file defined.  This servlet must have the 
init-param " + RESOURCE_PATH + " set." );
   } */
   String resourcePath = "/WEB-INF/somefile";

   URL url = null;
  try {
url = getServletContext().getResource( resourcePath );
  } catch (MalformedURLException e1) {
throw new XmlRpcException( resourcePath + " " + e1 );
  }

   if (url == null)
   {
  throw new XmlRpcException("Failed to locate resource " + resourcePath 
);
   }
   try
   {
  mapping = newPropertyHandlerMapping(url);
   }
   catch (IOException e)
   {
  throw new XmlRpcException("Failed to load resource " + url + ": " + 
e.getMessage(), e);
   }

   if ( mapping == null )
  Log.debug( "HandlerMapping is null" );
   else
   {
  String[] methods = mapping.getListMethods();

  for ( int x = 0; x < methods.length; x++ )
  {
 Log.debug( "method: " + methods[x] );
  }
   }
   
   mapping.setAuthenticationHandler(new AuthenticationHandler() {

 //rick removed override annotaion so this class will compile on java 
1.5
//@Override
public boolean isAuthorized(XmlRpcRequest arg0) throws 
XmlRpcException {
return true;
}
   });

   return mapping;
}
}
Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Mark Thomas 
Sent: Thursday, February 8, 2024 9:27 AM
To: users@tomcat.apache.org
Subject: Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

[You don't often get email from ma...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

On 08/02/2024 14:17, Rick Noel wrote:

My class is RVXmlRpcServlet and below is the compile error that
happens when I use the xmlrpc-server3.1.3.jar after that jar has been
run through  the migration tool jakartaee-migration-1.0.7

That same class throws NO compile error on Tomcat 9 using
xmlrpc-server3.1.3.jar

Here is the compile error


The bug is your code. You need up update RVXmlRpcServlet to use 
jakarta.servlet.Servlet rather than javax.servlet.Servlet

Ditto for any other Java EE classes you have referenced in your code.

If you want your application to work with Tomcat 9 and Tomcat 10 I suggest you:

- write it for Tomcat 9
- package it as a WAR file
- process the entire WAR file with the migration tool
- use original WAR file with Tomcat 9 and the migrated WAR file with
Tomcat 10+

Mark



06-Feb-2024 15:48:53.044 SEVERE [http-nio-8588-exec-1] 
org.apache.catalina.core.StandardWrapperValve.invoke Allocate exception for 
servlet [XmlRpcSer

Re: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Mark Thomas


On 08/02/2024 14:17, Rick Noel wrote:

My class is RVXmlRpcServlet and below is the compile error that happens when I 
use the xmlrpc-server3.1.3.jar after that jar has been run through  the 
migration tool jakartaee-migration-1.0.7

That same class throws NO compile error on Tomcat 9 using xmlrpc-server3.1.3.jar

Here is the compile error


The bug is your code. You need up update RVXmlRpcServlet to use 
jakarta.servlet.Servlet rather than javax.servlet.Servlet


Ditto for any other Java EE classes you have referenced in your code.

If you want your application to work with Tomcat 9 and Tomcat 10 I 
suggest you:


- write it for Tomcat 9
- package it as a WAR file
- process the entire WAR file with the migration tool
- use original WAR file with Tomcat 9 and the migrated WAR file with
  Tomcat 10+

Mark



06-Feb-2024 15:48:53.044 SEVERE [http-nio-8588-exec-1] 
org.apache.catalina.core.StandardWrapperValve.invoke Allocate exception for 
servlet [XmlRpcServlet]
java.lang.ClassCastException: class 
com.radiovoodoo.xmlrpc.RVXmlRpcServlet cannot be cast to class 
jakarta.servlet.Servlet (com.radiovoodoo.xmlrpc.RVXmlRpcServlet is in unnamed 
module of loader org.apache.catalina.loader.ParallelWebappClassLoader 
@568750b7; jakarta.servlet.Servlet is in unnamed module of loader 
java.net.URLClassLoader @18769467)
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:865)
at 
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:649)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:115)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:115)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
at 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:673)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340)
at 
org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:391)
at 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
at 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:896)
at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1744)
at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:52)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
at 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.base/java.lang.Thread.run(Thread.java:833)


Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com

-Original Message-
From: Mark Thomas 
Sent: Thursday, February 8, 2024 8:54 AM
To: users@tomcat.apache.org
Subject: [EXT]Re: jakartaee-migration-1.0.7 migration tool failure

[You don't often get email from ma...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

On 08/02/2024 13:45, Rick Noel wrote:

Our application uses classes in this jar xmlrpc-server3.1.3.jar .(it is the 
latest version)

We are trying to migrate to Tomcat 10 but that  jar uses the   javax.server. 
package classes instead of the needed  jakarta.server. pacakage.


I have tried running this jar trough the latest Tomcat 10 migration
tool (jakartaee-migration-1.0.7) which is suppose to alter the jar to
make all classes use  jakarta.server.  classes

but the tool is not fully converting all the classes,  since I still get 
compile errors at run time.


Please provide details of the compilation errors that you see.


I think in addition to not using  javax.server.  the jar should use
this class

java.net.URI  instead of   java.net.URL


That seems ... unlikely.


anyone have ideas on how to make xmlrpc-server3.1.3.jar  tomcat 10 compliant?


I'd be surprised if the migration tool didn't process a JAR that old correctly.

Mark



BTW the jar in question has classes in this package
org.apache.xmlrpc.

Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com




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

CAUTION: This email originated from outside

Re: jakartaee-migration-1.0.7 migration tool failure

2024-02-08 Thread Mark Thomas


On 08/02/2024 13:45, Rick Noel wrote:

Our application uses classes in this jar xmlrpc-server3.1.3.jar .(it is the 
latest version)

We are trying to migrate to Tomcat 10 but that  jar uses the   javax.server. 
package classes instead of the needed  jakarta.server. pacakage.


I have tried running this jar trough the latest Tomcat 10 migration tool 
(jakartaee-migration-1.0.7) which is suppose to alter the jar to make all 
classes use  jakarta.server.  classes

but the tool is not fully converting all the classes,  since I still get 
compile errors at run time.


Please provide details of the compilation errors that you see.


I think in addition to not using  javax.server.  the jar should use this class

java.net.URI  instead of   java.net.URL


That seems ... unlikely.


anyone have ideas on how to make xmlrpc-server3.1.3.jar  tomcat 10 compliant?


I'd be surprised if the migration tool didn't process a JAR that old 
correctly.


Mark



BTW the jar in question has classes in this package
org.apache.xmlrpc.

Rick Noel
Systems Programmer | Westwood One
rn...@westwoodone.com




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

Re: Tomcat taglibs 2.0.0 release?

2024-02-05 Thread Mark Thomas


On 05/02/2024 15:49, Jeroen Hoffman wrote:

On Mon, Feb 5, 2024 at 4:05 PM Mark Thomas  wrote:



Are there plans to release the 2.0.0 version?


No plans.

Tomcat 10.1.x onwards uses the 1.2.5 taglibs release converted for
Jakarta EE using the Tomcat migration tool.



Thanks for the quick answer!

Could you share some details on the migration? In a standard Tomcat 10 I
see taglibs-standard-spec-1.2.5-migrated-0.0.1.jar and
taglibs-standard-impl-1.2.5-migrated-0.0.1.jar in the examples webapp, but
these are not published to Maven Central. So can an implementation reuse
already converted jars or should it also do a conversion?


We don't have any plans to publish the migrated JARs.

You can re-use those JARs if you wish or migrate them and publish the 
result in your local/company repo.


Mark

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

Re: Tomcat taglibs 2.0.0 release?

2024-02-05 Thread Mark Thomas


On 05/02/2024 14:16, Jeroen Hoffman wrote:

Hi everybody,

I have a question on Tomcat taglibs, I chose this mailing list because 
the taglibs-user one seems inactive.


We in the process of updating our application to use Java 17 and Tomcat 
10, including javax/jakarta change. It uses Tomcat Standard Taglibs. We 
noticed that the code base [1] has been reworked 4 years ago to use 
jakarta, development version is 2.0.0-SNAPSHOT.


Are there plans to release the 2.0.0 version?


No plans.

Tomcat 10.1.x onwards uses the 1.2.5 taglibs release converted for 
Jakarta EE using the Tomcat migration tool.


Mark

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

Re: Return a custom page in the event of a client requesting a non-existent resource on tomcat9

2024-02-04 Thread Mark Thomas


On 02/02/2024 18:48, Kaushal Shriyan wrote:

Hi,

I am running tomcat version 9.0.84 on Red Hat Enterprise Linux release 8.7
(Ootpa). Is there a way to configure the server to return a custom page in
the event of a client requesting a non-existent resource.


Yes.


Please guide me.


To do this at the web application level:

Read section 10.9.2 of the Servlet 4.0 specification


To do this globally, look at the errorCode.nnn attribute of the 
ErrorReportValve


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

Mark

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

Re: Tomcat not syncing existing sessions on restart

2024-02-02 Thread Mark Thomas


On 31/01/2024 13:33, Manak Bisht wrote:

I tried tweaking all the settings that I could think of but I am unable to
sync sessions on restart even on a stock Tomcat 8.5.98 installation using
your provided war. I am unable to identify whether this is actually a bug
or something wrong with my configuration (this is far more likely). Could
you please share your server.xml? Did you make any other changes?

Sincerely,
Manak Bisht


Here is the cluster configuration from the first node my test environment:



  

  



  

  






  





  

  

  

  

  



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

Re: How does the user principal get set on the servlet container session?

2024-02-01 Thread Mark Thomas





On 01/02/2024 17:48, Ryanesch@yahoo wrote:




On Feb 1, 2024, at 10:34 AM, Mark Thomas  wrote:

On 31/01/2024 00:15, Ryan Esch wrote:

 From what I understand, the container knows if a user is authenticated by 
using the session id passed to it and then looking up the user principal. If 
this is non-null, the user is authenticated. I am using web.xml with security 
constraints and UsersRoleLoginModule defined in jaas.conf which is working 
fine. I want to add an additional method of login.
How do I set the principal on the session in my custom login module?


Is this a JAAS login module or something else?


I have tried a number of things, including:
HttpSession session = request.getSession();
// Retrieve or create the Subject
Subject subject = (Subject) session.getAttribute("javax.security.auth.subject");
if (subject == null) {
 subject = new Subject();
 session.setAttribute("javax.security.auth.subject", subject);
}
subject.getPrincipals().size());
Principal customPrincipal = new CustomPrincipal("Random Username");
subject.getPrincipals().add(customPrincipal);All my calls to 
request.getUserPrincipal() are null so of course my custom login 
fails.Alternatively/additionally, can I configure the container to also check 
for an access token for authentication?
Thank you for any input or advice. I'd be happy to share additional details.Ryan


Take a look at AuthenticatorBase.register()

Mark

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



Yes, this is jaas. I’ve realized that if I use jboss’ SimplePrincipal to create 
my principal, the user principal is finally set on the subject. However, when I 
use a custom principal, it is not set on the subject correctly. Even if I copy 
SimplePrincipal exactly or extend it. Note that “correctly” means that I get 
something returned from request.getUserPrincipal. There must be something 
behind the scenes that checks for exactly SimplePrincipal?


https://tomcat.apache.org/tomcat-11.0-doc/config/realm.html#JAAS_Realm_-_org.apache.catalina.realm.JAASRealm

Search for userClassNames. You may also need roleClassNames.

Mark

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

Re: How does the user principal get set on the servlet container session?

2024-02-01 Thread Mark Thomas


On 31/01/2024 00:15, Ryan Esch wrote:

 From what I understand, the container knows if a user is authenticated by 
using the session id passed to it and then looking up the user principal. If 
this is non-null, the user is authenticated. I am using web.xml with security 
constraints and UsersRoleLoginModule defined in jaas.conf which is working 
fine. I want to add an additional method of login.
How do I set the principal on the session in my custom login module?


Is this a JAAS login module or something else?


I have tried a number of things, including:
HttpSession session = request.getSession();

// Retrieve or create the Subject
Subject subject = (Subject) session.getAttribute("javax.security.auth.subject");
if (subject == null) {
 subject = new Subject();
 session.setAttribute("javax.security.auth.subject", subject);
}
subject.getPrincipals().size());

Principal customPrincipal = new CustomPrincipal("Random Username");
subject.getPrincipals().add(customPrincipal);All my calls to 
request.getUserPrincipal() are null so of course my custom login 
fails.Alternatively/additionally, can I configure the container to also check 
for an access token for authentication?
Thank you for any input or advice. I'd be happy to share additional details.Ryan


Take a look at AuthenticatorBase.register()

Mark

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

Re: Session Cookie Logging

2024-02-01 Thread Mark Thomas





On 27/01/2024 14:38, Dan McLaughlin wrote:

Hey Mark,

If you see a bug report, then that will mean I was able to reproduce it.  I
see different behaviors in our local docker environment. Still, it's
nowhere as complex as our production environment--where everything is
clustered and behind load balancers, etc...  It probably would be easier
for me to reproduce in our pre-prod environment and attach a debugger to
see where the / is coming from.

I glanced at the code, and SessionConfig is the only place setting the
CookiePath to / might happen.  Would you agree?

} else {
 // Only handle special case of ROOT context where cookies require a
 // path of '/' but the servlet spec uses an empty string
 if (contextPath.length() == 0) {
 contextPath = "/";
 }


There are other places such as the RewriteValve. I think debugging is 
your best option here.


Mark

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

Re: Session Cookie Logging

2024-01-26 Thread Mark Thomas


On 26/01/2024 22:22, Dan McLaughlin wrote:

Hey Konstantin,

Thanks for the reply.

I synced the source last night. I haven't had a chance to step through with
a debugger yet. But the only way I could get the Cookie Path set was to
modify the context.xml and add sessionCookiePath to every application. I'm
pretty sure this wasn't how things worked in the past. And the
documentation even states (or how I interpret it) that the cookie path
should default to the context path if cookie path isn't set by the app or
in the context.xml. We don't set it anywhere in our code that I could find,
and it's not in our web.xml either. I also checked the server.xml and
context.xml in catalina base, and nothing sets anything related to the
session cookie.

Locally in docker, I could confirm that if you don't set anything except
the cookie processor, then you end up with a JSESSIONID with a cookie path
that is the same as the context if it's not the root context. But if you
try to set sessionCookie in the context.xml for the app to
_Secure-JSESSIONID and you don't set the sessionCookiePath, then your
cookie path will be / regardless of what the context path is.


I have tested this with a clean build of both 10.1.x and 11.0.x and both 
correctly set the path to "/examples" when I open the Servlet session 
example in the examples app with sessionCookieName="_Secure-JSESSIONID".



Seems like a
bug to me. If I have time to try some more tests and can confirm the same
using the examples web app, then I'll open a bug.   We do
set privileged="false" in our context.xml so the only thing I can think of
is that the cookie processor or whatever code is managing the cookies is
blocked from calling the api's needed to check the context path and so it
defaults to /.


Nope. Cookie processing doesn't require privileged.


Anyway, I'd have to do quite a bit more testing before I'd feel comfortable
opening a bug, but there looks to be changes in the areas related to
Sessions and Cookies lately, so I'm guessing at this point that one of
those changes introduced a behavior change.


There have been a few changes but nothing that is likely to affect this. 
I don't recall any changes that touched cookie paths in a long time.


This looks like an app issue (or an issue in a library the app uses) to 
me at the moment.


If you are able to reproduce this on a clean install of the latest 
10.1.x release (or any other currently supported version) I'd be happy 
to take another look. All we'd need would be the steps to recreate the 
issue from the clean install.


Mark

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

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 8838 matches

Mail list logo