from:"Mark Thomas"

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:

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

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

2024-01-26 Thread Mark Thomas


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

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


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

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

Mark

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

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

2024-01-25 Thread Mark Thomas


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

Hello together,

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

We are running tomcat on Windows Server 2019

Our Tomcat Version is delivered with SAP BusinessObjects.

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


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


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


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


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


Mark


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

Re: Getting wrong value calling request.getScheme()

2024-01-24 Thread Mark Thomas


On 24/01/2024 15:48, joan.balagu...@ventusproxy.com wrote:




Any help would be really appreciated.


Configuration error.

Someone has done the equivalent of 

Or possibly a mis-configured RemoteIpFilter (or Valve).

Or similar.

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-01-23 Thread Mark Thomas

I have configured my standard cluster test environment for a 2-node 
cluster, using DeltaManager and static membership. httpd is configured 
for non-sticky load-balancing.


Each node has the Manager web application and my simple cluster-test 
deployed.

https://people.apache.org/~markt/dev/cluster-test.war

Starting both both nodes and connecting directly to each manager 
instance shows no sessions in cluster-test as expected.


Requesting the cluster index page via httpd triggers the creation of a 
single session in cluster-test. Requests alternate between node 1 and 
node 2 as expected. Examining the session via the manager app shows that 
the changes to the session are being correctly replicated.


Stopping node 2 causes further requests to be directed to node 1 only.

Starting node 2 shows that the session is replicated correctly from node 
1. I see the updated session in both nodes via the Manager app.


Also the following test works:
- create a session
- stop node 2
- further requests (handled by node 1)
- stop requests
- start node 2
- stop node 1
- resume requests (handled by node 2)

One difference is that I am using the StaticMembershipService rather 
than the StaticMembershipInterceptor. I don't think that will make any 
difference.


The other difference is that you don't appear to have defined the local 
member of the cluster. You should define all members of the cluster, 
including the local member, on each node. The local member can be 
defined explicitly as LocalMember or as an ordinary Member and Tomcat 
will figure out it is the local one.


Mark


On 22/01/2024 08:39, Manak Bisht wrote:

I thought that this https://marc.info/?l=tomcat-user=119376798217922=2
might be the problem.
*"The uniqueId is used to be able to differentiate between the same node
  joining a cluster, then crashing and then rejoining again. if the uniqueId
didn't change in between this, there is no way to tell  the difference
between a node going down, or just leaving the cluster  and rejoining."*
So, I tried creating a session when one of the nodes was down, but that did
not sync as well when the other node came online again.
In that case, I would also expect org.apache.catalina.ha.
session.DeltaManager.waitForSendAllSessions to proceed with no state sync
rather than timing out.

I have also checked the time on both the servers using the Linux date
command and they seem to be in sync. The timezone flag passed to the
JAVA_OPTS argument in catalina.sh is also the same. Please let me know if
any more information is required to help debug this issue.

Sincerely,
Manak Bisht

On Sun, Jan 14, 2024 at 11:09 PM Manak Bisht  wrote:


Hi,
I am using DeltaManager (static membership) with non-sticky load balancing
on two nodes. I have observed even load, and requests with the same
JSESSIONID being served successfully by both tomcats. This leads me to
conclude that session replication is working as expected when both nodes
are up.

However, when I restart any one of them, the newly restarted tomcat is
unable to serve requests from old sessions. The logs indicate that node
discovering is working but the session sync timeouts. New logins/sessions
work just fine though, implying that replication is working successfully
again.

*tomcat1.log*
13-Jan-2024 14:16:35.713 INFO [GroupChannel-Heartbeat-1]
org.apache.catalina.ha.tcp.SimpleTcpCluster.memberDisappeared Received
member
disappeared:org.apache.catalina.tribes.membership.StaticMember[tcp://tomcat2:8090,tomcat2,8090,
alive=0, securePort=-1, UDP Port=-1, id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 },
payload={}, command={}, domain={}, ]
13-Jan-2024 14:44:16.457 INFO [GroupChannel-Heartbeat-1]
org.apache.catalina.ha.tcp.SimpleTcpCluster.memberAdded Replication member
added:org.apache.catalina.tribes.membership.StaticMember[tcp://tomcat2:8090,tomcat2,8090,
alive=0, securePort=-1, UDP Port=-1, id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 },
payload={}, command={}, domain={}, ]
13-Jan-2024 14:44:16.457 INFO [GroupChannel-Heartbeat-1]
org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.performBasicCheck
Suspect member, confirmed
alive.[org.apache.catalina.tribes.membership.StaticMember[tcp://tomcat2:8090,tomcat2,8090,
alive=0, securePort=-1, UDP Port=-1, id={0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 },
payload={}, command={}, domain={}, ]]
*13-Jan-2024 14:45:24.354 WARNING [Tribes-Task-Receiver-4]
org.apache.catalina.ha.session.DeltaManager.deserializeSessions overload
existing session *


*tomcat2.log*
13-Jan-2024 14:45:24.290 INFO [localhost-startStop-1]
org.apache.catalina.ha.session.DeltaManager.startInternal Register manager
localhost# to cluster element Engine with name Catalina
13-Jan-2024 14:45:24.291 INFO [localhost-startStop-1]
org.apache.catalina.ha.session.DeltaManager.startInternal Starting
clustering manager at localhost#
13-Jan-2024 14:45:24.363 INFO [localhost-startStop-1]
org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor.report

Re: EOL - Tomcat versions

2024-01-19 Thread Mark Thomas


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

@Mark Thomas,

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


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


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


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

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


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


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

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

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

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


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


Mark





Thanks.



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



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

https://endoflife.date/tomcat

Am 08.01.24 um 07:39 schrieb Deshmukh, Kedar:

Hello,

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


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


    1.  8.5.X


EOL 31 March 2024


    2.  9.0.X


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


    3.  10.0.X


Already EOL as of 31 October 2022


    4.  10.1.X


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

Mark

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



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



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

Re: [SECURITY] CVE-2024-21733 Apache Tomcat - Information Disclosure

2024-01-19 Thread Mark Thomas


Correcting the CVE reference in the text (the subject line is correct)

Mark


On 19/01/2024 10:17, Mark Thomas wrote:

CVE-2023-21733 Apache Tomcat - Information Disclosure

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0-M11 to 9.0.43
Apache Tomcat 8.5.7 to 8.5.63

Description:
Incomplete POST requests triggered an error response that could contain 
data from a previous request from another user.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.44 or later
- Upgrade to Apache Tomcat 8.5.64 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by xer0dayz from Sn1perSecurity LLC.


History:
2024-01-19 Original advisory

References:
[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-21733 Apache Tomcat - Information Disclosure

2024-01-19 Thread Mark Thomas


CVE-2023-46589 Apache Tomcat - Information Disclosure

Severity: Important

Vendor: The Apache Software Foundation

Versions Affected:
Apache Tomcat 9.0.0-M11 to 9.0.43
Apache Tomcat 8.5.7 to 8.5.63

Description:
Incomplete POST requests triggered an error response that could contain 
data from a previous request from another user.


Mitigation:
Users of the affected versions should apply one of the following
mitigations:
- Upgrade to Apache Tomcat 9.0.44 or later
- Upgrade to Apache Tomcat 8.5.64 or later

Credit:
This vulnerability was reported responsibly to the Tomcat security team 
by xer0dayz from Sn1perSecurity LLC.


History:
2024-01-19 Original advisory

References:
[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: Consultation on disabling insecure HTTP requests in Tomcat

2024-01-18 Thread Mark Thomas


On 18/01/2024 09:22, 2460873257 wrote:

Hi Tomcat Experts：
       I'm trying to Looking for a solution to disable the tomcat * 
Options request,


Why?

but upon checking the source code, it seems that it is 
directly defined in the code. Is there a configuration provided to 
disable it?


No.


Attached are the questions and the source code found


Attachments are removed automatically. Please use plain text.

Mark

-
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-M16 (alpha) available

2024-01-09 Thread Mark Thomas


The Apache Tomcat team announces the immediate availability of Apache
Tomcat 11.0.0-M16 (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-M16 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-M15 include:


- Fix virtual thread support for the NIO2 connector

- Correct a regression in the fix for 67675 that broke TLS key file
  parsing for PKCS#8 format keys that do not specify an explicit
  pseudo-random function and rely on the default. This typically affects
  keys generated by OpenSSL 1.0.2.

- Allow multiple operations with the same name on introspected mbeans,
  fixing a regression caused by the introduction of a second
  addSslHostConfig() method.

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: Regarding Tomcat is creating the zombie processes

2024-01-09 Thread Mark Thomas


On 09/01/2024 10:11, Vaidya, Omkar wrote:

Hi Mark,

Thanks for the response. For mainly related to our Thingworx IOT-based 
application, we are using the Tomcat 9.0.62 server. So for that, we are getting 
zombie or defunct processes.

"Please provide the steps you used to recreate this issue in a clean installation of a 
standalone Tomcat instance." -> So for this,  We have executed our installer, which 
itself installs the Tomcat server. So, there are no manual steps that we ask the user to 
execute.


That is not a clean installation of a standalone Tomcat. That is your 
installer which could, frankly, be doing anything.


Your original post claimed that this issue was reproducible on a 
standalone Tomcat installation. You need to provide details of how to 
reproduce this on a clean standalone Tomcat installation - i.e. starting 
with an installer provided by the ASF.



As per the previous response, "A default Tomcat install does not create parent and 
child processes, so zombie processes cannot occur." -> So we have raised a support 
case with Tomcat to just understand the reason why defunct processes are created.

Is anybody already raised case similar to defunct or related to zombie 
processes. If yes, can you please share which resolution you have provided to 
them to prevent creation of those.


This is open source support, provided by volunteers, for free. Not a 
commercial support agreement. If you want a commercial support agreement 
then there are plenty of vendors offering them (of varying quality). And 
you'll need to pay for it.


So far, you have claimed a problem exists without providing any evidence 
to back up that claim.


You need to provide the steps to re-create the problem from a clean 
installation of a current Tomcat package provided by the ASF.


Given that the issue is with zombie process (which require parent/child 
process) and that a standard Tomcat installation is a single process 
that never forks any children, this currently looks like something that 
is not a Tomcat issue.


At this point the onus is on you to provide the steps necessary for 
someone on this list to recreate the problem you are seeing starting 
from a Tomcat distribution downloaded from tomcat.apache.org


Mark




Thanks,
Omkar V.

-Original Message-
From: Mark Thomas 
Sent: Friday, January 5, 2024 6:00 PM
To: users@tomcat.apache.org
Subject: Re: Regarding Tomcat is creating the zombie processes

[You don't often get email from ma...@apache.org. Learn why this is important 
at https://aka.ms/LearnAboutSenderIdentification ]

You will need to provide more details.

A default Tomcat install does not create parent and child processes so zombie 
processes cannot occur.

I'll also note that zombie process do not consume system resources (apart from 
a process ID).

Please provide the steps you used to recreate this issue in a clean 
installation of a standalone Tomcat instance.

Mark


On 05/01/2024 09:48, Vaidya, Omkar wrote:

Adding information -
Tomcat Version - 9.0.62
Platform - Linux Platform


From: Vaidya, Omkar 
Sent: Friday, January 5, 2024 3:15 PM
To: users@tomcat.apache.org
Cc: Shriwardhankar, Varun 
Subject: Regarding Tomcat is creating the zombie processes

Hi Team,

This is regarding like we have one customer issue where on Linux platform, we 
have configured our IOT-application (Thingworx), which is using Tomcat as a 
server.
So we are able to identify that even when we remove our application, Tomcat is 
creating a zombie (defunct) process, which is creating 200+ processes under the 
process table, which ultimately occupy all the OS resources and the application 
goes in a hung state. This issue is also reproducible on the Standalone Tomcat 
server also.
There are two scenarios mentioned below -
1.If this is relatable to Tomcat can you please suggest any article 
or documentation so that we can stop zombie process creation, if this is a 
known issue or there is only way to clear zombie (defunct) process from 
Processes table of linux.
2.Also, let us know if this is a Operating System specific issue 
like as it is reproducible only on Linux, So Linux os is the thing that creates 
the zombie (defunct) processes?
we are eagerly waiting for the response.

Thanks,
Omkar Vaidya.




-
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: EOL - Tomcat versions

2024-01-08 Thread Mark Thomas





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

https://endoflife.date/tomcat

Am 08.01.24 um 07:39 schrieb Deshmukh, Kedar:

Hello,

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


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


   1.  8.5.X


EOL 31 March 2024


   2.  9.0.X


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


   3.  10.0.X


Already EOL as of 31 October 2022


   4.  10.1.X


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

Mark

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

Re: Regarding Tomcat is creating the zombie processes

2024-01-05 Thread Mark Thomas


You will need to provide more details.

A default Tomcat install does not create parent and child processes so 
zombie processes cannot occur.


I'll also note that zombie process do not consume system resources 
(apart from a process ID).


Please provide the steps you used to recreate this issue in a clean 
installation of a standalone Tomcat instance.


Mark


On 05/01/2024 09:48, Vaidya, Omkar wrote:

Adding information -
Tomcat Version - 9.0.62
Platform - Linux Platform


From: Vaidya, Omkar 
Sent: Friday, January 5, 2024 3:15 PM
To: users@tomcat.apache.org
Cc: Shriwardhankar, Varun 
Subject: Regarding Tomcat is creating the zombie processes

Hi Team,

This is regarding like we have one customer issue where on Linux platform, we 
have configured our IOT-application (Thingworx), which is using Tomcat as a 
server.
So we are able to identify that even when we remove our application, Tomcat is 
creating a zombie (defunct) process, which is creating 200+ processes under the 
process table, which ultimately occupy all the OS resources and the application 
goes in a hung state. This issue is also reproducible on the Standalone Tomcat 
server also.
There are two scenarios mentioned below -
1.If this is relatable to Tomcat can you please suggest any article 
or documentation so that we can stop zombie process creation, if this is a 
known issue or there is only way to clear zombie (defunct) process from 
Processes table of linux.
2.Also, let us know if this is a Operating System specific issue 
like as it is reproducible only on Linux, So Linux os is the thing that creates 
the zombie (defunct) processes?
we are eagerly waiting for the response.

Thanks,
Omkar Vaidya.




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

Re: EOL for Tomcat 9.0.x and Tomcat 10.1.x

2023-12-19 Thread Mark Thomas


On 19/12/2023 12:32, Kaluva S wrote:

Hi,
We are planning to migrate from tomcat 9.0.x to Tomcat 10.1.x but want to
know about EOL  for both the releases. On the official tomcat website, we
couldn't find any information about this.
If anyone knows, please share so that we will plan accordingly.


There are currently no firm EOL dates for either 9.0.x or 10.1.x.

Based on past experience, 9.0.x is likely to be EOL some time around 31 
March 2027 and 10.1.x is likely to be EOL some time around 31 March 2030.


However those dates are driven by the expected stability dates of Tomcat 
12 and Tomcat 13 (neither of which have even been started yet) and which 
in turn depend on the release dates for Jakarta EE 12 and Jakarta EE 13 
which also have not been started. So the dates above really are just a 
best guess at this point.


Further, since 9.x is the last branch to support Java EE, it is our 
intention to continue 9.x support beyond the 9.0.x EOL. The current 
expectation is that there would be a 9.10.x release branch that would 
track 10.1.x with the minimal changes required to implemented to Java EE 
API rather than the Jakarta EE API.


When 10.1.x reaches EOL so will 9.10.x which would then be replaced by 
9.11.x which would track 11.0.x. And so on for as long as there was 
(sufficient) demand for Java EE support. Sufficient is deliberately 
subjective. It will depend on the level of demand and the effort 
required. As volunteers, there is only so long we can support things for.


Mark

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

Re: Clarification on CVE-2023-46589

2023-12-18 Thread Mark Thomas


On 18/12/2023 09:50, purtrator wrote:

There are many types of things one can do with HTTP Request Smuggling,
is this an attack where header theft, cache poisoning or even response
queue poisoning is possible?

What are the possible damage scenarios?


Assume that any attack enabled by request smuggling is possible.


And finally I wonder what the restrictions of this issue are
Does it work over HTTP/2 or HTTP/1.1 or both?


HTTP/1.1 only.

The use of separate streams in HTTP/2 for each request prevents this 
type of attack.


Mark

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

Re: JSP EL - How to

2023-12-18 Thread Mark Thomas


17 Dec 2023 21:31:10 Chuck Caldarale :




On Dec 16, 2023, at 23:05, Arbol One  wrote:

Hello.

In my NetBeans IDE, I have a ANT web project, to which I have added 
under Libraries the JSTL 1.2.7 - jstl-impl.jar and the JSTL 1.2.7 - 
jstl-api.jar libraries. However, when adding this code :


*
Hello JSP EL!
*



Tags are not allowed inside  elements. The following should 
work:





Hello JSP EL!




  - Chuck


The JARs you added are for JSTL, not EL. And your example uses neither 
JSTL nor EL.


Confused.

Mark

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

Re: Tomcat with IIS

2023-12-18 Thread Mark Thomas

18 Dec 2023 05:31:24 Mohammed Ramadan Ghallab 
:



Hello

I’m using tomcat and I want to create a virtual directory but I can’t 
do that
if it isn’t possible can you please tell me how to integrate tomcat 
with IIS


https://tomcat.apache.org/connectors-doc/webserver_howto/iis.html

Tested and confirmed working with all currently supported (by Microsoft) 
versions of Windows. And probably working with a lot of the out of 
support versions too.


Mark

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

Re: Should allowHostHeaderMismatch be case sensitive

2023-12-15 Thread Mark Thomas


On 15/12/2023 14:48, Christopher Schultz wrote:

Do we need to argue over encoding and/or rules of 
case-insensitive-matching?


Could we? Probably. Do we need to? Unlikely.

My expectation is that most clients aren't even including the host in 
the request line these days.


Non-ASCII hostnames are allowed these days. Depending upon when this 
comparison is done, the strings may or may not have been normalized. 
Case-normalization can be expensive if you want to be as encoding, 
language, etc. agnostic as possible.


Yes this is a theoretical risk but one I don't expect to materialize. My 
expectation is that clients new enough to use non-ascii host names also 
don't put the header in the request line or if they do, they make sure 
it matches the Host header.


Perhaps we could perform a byte-wise comparison first (which is very 
likely to succeed quickly) and, if that fails, fall-back to a more 
thorough normalization/comparison?


That is probably the way to go if we decide in the future that we do 
need to do the normalization first. In which case I'd lean more towards 
using toString() and then getting Java to do the comparison.


Mark

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

Re: security-constraint url-pattern question

2023-12-15 Thread Mark Thomas


On 14/12/2023 17:28, ResSoft wrote:

Chris,

I figured out how to make this work.  It works in my dev dox but not in 
my prod box.  Both have the same version of tomcat.  Here is the web.xml entry. 
 I any ideas would be great.


Those constraints look correct to me and a quick test using the examples 
webapp with a default Tomcat install confirms that.


I think you need to look for differences between dev and prod.




 securedapp
 /*
 
 
   CONFIDENTIAL
 
   

 
  



HTTP-Protected-Resource-1
Description here
/path to directory/*
GET
POST


You *really* don't want to be specifying HTTP methods here.

Google for "uncovered HTTP methods"









Mark

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

Re: Should allowHostHeaderMismatch be case sensitive

2023-12-15 Thread Mark Thomas


On 11/12/2023 17:20, Mark Thomas wrote:

On 11/12/2023 17:08, David Cleary wrote:
Just want to check if this is by design. The above property default 
was changed to better secure the default configuration. We started 
having some tests fail due to this.


In our scenario ( as shown below ), the Host header value in the HTTP 
request is case-sensitive difference compared to the Request Line, and 
it's crucial that Tomcat, our web server, does not block or reject 
requests based on variations in the letter case within this header.


Request Line: GET http://HZN-OE-A079:8080 HTTP/1.1
Host header: hzn-oe-a079:8080

Just want to confirm that this property, now with a default of false, 
is supposed to reject requests based on the case of the host name.


David,

Host names are case insensitive so I can see the argument for making 
this comparison in a case insensitive manner.


However, the language in RFC 9112, section 3.2 is:

A client MUST send a Host header field (Section 7.2 of [HTTP]) in all 
HTTP/1.1 request messages. If the target URI includes an authority 
component, then a client MUST send a field value for Host that is 
identical to that authority component, excluding any userinfo 
subcomponent and its "@" delimiter (Section 4.2 of [HTTP]).



The key word for me in the above is identical.

We probably need to go back to the HTTP working group and clarify 
whether then intention was for that "identical" to be in a case 
sensitive or insensitive manner.


https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0247.html

Based on that discussion, I am going to relax the check to case insensitive.

Mark

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

Re: [EXTERNAL] - Re: Partitioned cookies

2023-12-15 Thread Mark Thomas

On 14/12/2023 21:15, André van der Lugt wrote:

From: Chuck Caldarale 
Sent: Wednesday, November 15, 2023 9:48 AM
To: Tomcat Users List 
Subject: [EXTERNAL] - Re: Partitioned cookies

On Nov 15, 2023, at 08:06, Adam Warfield
 wrote:

The Rfc6265CookieProcessor supports setting the SameSite cookie attribute
but starting in 2024, browsers will begin enforcing the newer "Partitioned"
attribute for third-party cookies. Is there a way to set this attribute within
Tomcat for things like the JSESSIONID and XSRF-TOKEN cookies? This affects
any webapps that are embedded within iframes across domains where those
cookies will be rejected if not partitioned.

Looks like the CHIPS proposal:

https://datatracker.ietf.org/doc/draft-cutler-httpbis-partitioned-cookies/

expired this past May and no updated version has been submitted to IETF. Is
there some other active standards document describing cookie partitioning?

   - Chuck

Standard or not, Google/Chrome is moving on and will (as noted above) soon 
start to gradually reject third-party cookies without the Partitioned attribute.

I'm kindly asking the experts: is Tomcat support for this feature being planned?

No.

If not, what can be done to modestly prioritize it?

Open an enhancement request in Bugzilla. Better still, provide a PR to 
implement the change.

Mark

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

Re: Clarification on CVE-2023-46589

2023-12-14 Thread Mark Thomas


On 14/12/2023 16:13, Benny Prange wrote:

Am Do., 14. Dez. 2023 um 16:51 Uhr schrieb Mark Thomas :


On 14/12/2023 15:33, Benny Prange wrote:

Hi all,

I am having trouble understanding the description of CVE-2023-46589.
Does this CVE affect scenarios where the Apache Tomcat is the reverse
proxy, or or when the Apache Tomcat is running behind a reverse proxy?
Is the Tomcat vulnerable to request smuggling, or other applications
running behind the Tomcat?


Tomcat does not provide reverse proxy configuration.

This CVE applies when Tomcat is behind a reverse proxy.

Mark

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

Thanks for the quick response.


I'm afraid I still can't grasp it:
 From my understanding, the trailer header is used in HTTP responses. How
can this lead to request smuggling?


Trailer headers are valid for both requests and responses.

I am not going to describe how to attack Tomcat using this CVE.


Why is it important that there is a reverse proxy in front of the Tomcat,


Request smuggling occurs when two different HTTP servers (in this case 
the reverse proxy and Tomcat) process an invalid request in different 
ways. This typically results in the invalid request incorrectly being 
treated as more than one request by one of those servers.



or would the CVE also be applicable without a reverse proxy?


No.

Mark

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

Re: Clarification on CVE-2023-46589

2023-12-14 Thread Mark Thomas


On 14/12/2023 15:33, Benny Prange wrote:

Hi all,

I am having trouble understanding the description of CVE-2023-46589.
Does this CVE affect scenarios where the Apache Tomcat is the reverse
proxy, or or when the Apache Tomcat is running behind a reverse proxy?
Is the Tomcat vulnerable to request smuggling, or other applications
running behind the Tomcat?


Tomcat does not provide reverse proxy configuration.

This CVE applies when Tomcat is behind a reverse proxy.

Mark

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

Re: Should allowHostHeaderMismatch be case sensitive

2023-12-11 Thread Mark Thomas


On 11/12/2023 17:08, David Cleary wrote:

Just want to check if this is by design. The above property default was changed 
to better secure the default configuration. We started having some tests fail 
due to this.

In our scenario ( as shown below ), the Host header value in the HTTP request 
is case-sensitive difference compared to the Request Line, and it's crucial 
that Tomcat, our web server, does not block or reject requests based on 
variations in the letter case within this header.

Request Line: GET http://HZN-OE-A079:8080 HTTP/1.1
Host header: hzn-oe-a079:8080

Just want to confirm that this property, now with a default of false, is 
supposed to reject requests based on the case of the host name.


David,

Host names are case insensitive so I can see the argument for making 
this comparison in a case insensitive manner.


However, the language in RFC 9112, section 3.2 is:

A client MUST send a Host header field (Section 7.2 of [HTTP]) in all 
HTTP/1.1 request messages. If the target URI includes an authority 
component, then a client MUST send a field value for Host that is 
identical to that authority component, excluding any userinfo 
subcomponent and its "@" delimiter (Section 4.2 of [HTTP]).



The key word for me in the above is identical.

We probably need to go back to the HTTP working group and clarify 
whether then intention was for that "identical" to be in a case 
sensitive or insensitive manner.


Mark

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

Re: JAVA -tomcat- Request header is too large

2023-12-11 Thread Mark Thomas


On 08/12/2023 22:01, Christopher Schultz wrote:




Are request-ids always allocated, or only if they are "enabled"?


Always allocated.

I think adding the request-id to this exception detail message might be 
helpful, even if the request-id hasn't been enabled in the access-log.


WDYT?


Good point. More widely, we should probably be adding the request ID to 
every request related error message.


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 8814 matches

Mail list logo