On 12/05/2021 10:06, Mar Sil wrote:
Hi Mark,
We use both methods, file system (as part of deployment via Jenkins) and
Manager app when testing an application.
In both cases, the foo.xml is deleted once an app is deployed.
In regards to the settings for unpackWARs, we have the following.
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true">
Hmm. This is strange. I have just taken a default Tomcat install,
converted the examples directory to a WAR, removed the examples
directory and created
$CATALINA_BASE/conf/Catalina/localhost/exmaples.xml the content of which is:
<!-- This is a test -->
<Context />
Starting Tomcat,
- Logs show /examples is deployed from the descriptor
- $CATALINA_BASE/webapps/examples.war is unpacked to
$CATALINA_BASE/webapps/examples
If I then touch examples.war to simulate an update the context is
reloaded but examples.xml remains unchanged.
This is consistent with the docs for automatic deployment:
http://tomcat.apache.org/tomcat-10.0-doc/config/automatic-deployment.html
And there are unit tests that confirm that for the case:
- existing XML
- existing WAR
- existing DIR
updating the WAR results in:
- XML unchanged
- the new WAR
- old DIR removed and WAR unpacked to recreate new version of WAR
What do the logs show for the original deployment when Tomcat starts and
for when the WAR is updated?
Mark
Kind Regards,
On Tue, 11 May 2021 at 19:59, Mark Thomas <ma...@apache.org> wrote:
On 11/05/2021 17:09, Mar Sil wrote:
Hi Mark,
We replace the war file while tomcat is running.
We can't stop tomcat service while we deploy as there are multiple
applications running in the same server.
Just to be clear, you replace the WAR directly on the file system? You
don't use the Manager app? And what is the unpackWARs setting for the host?
Mark
Thanks
On Tue, 11 May 2021 at 16:50, Mark Thomas <ma...@apache.org> wrote:
How do you do the redploy? Do you simply replace the WAR? While Tomcat
is running or while it is shutdown?
Mark
On 11/05/2021 16:40, Mar Sil wrote:
Hello Mark,
Thanks for your email.
I have tried the option mentioned and the restriction to the
application
worked.
However, when I tried to redeploy the war file, the 'foo.xml' was
removed.
So, this leads me to the conclusion a foo.xml file will need to be
added
every time there is a new deployment.
According to the tomcat
doc, $CATALINA_BASE/<engine-name>/<host-name>/foo.xml should not be
affected by future deployments.
Am I missing something?
Thanks
On Mon, 10 May 2021 at 18:07, Mark Thomas <ma...@apache.org> wrote:
On 10/05/2021 17:32, Christopher Schultz wrote:
CidinhaDev,
On 5/10/21 09:46, Mar Sil wrote:
Hello,
I am using Apache Tomcat 9.0.45, running on CentOS 7 server.
On this server I have a couple of applications (apis mostly) that
need
to
have the access restricted to 2 specific servers.
SERVER A <------> api call <------>TOMCAT SERVER - OK 200
SERVER B <------> api call <------> TOMCAT SERVER - OK 200
If the request is not made by server A or B, tomcat should return a
403 or
404.
The manager page should be available to any machine on our internal
network
(the sysadmin would have access to the login credentials).
At the moment, I could only manage to:
1 - restrict the access globally (not just the apis but also the
manager
page);
2 - restrict the access to the manager page (credentials required).
3 - restrict the access to the apis only, but with login credentials
required (this is not what I need as the api call will be made by
servers,
not users)
For option 1 and 2, I have changed the server.xml
({$CATALINA_HOME}/conf),
and added the below:
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1"/>
Please note that I have amended the ips accordingly.
This was done in addition to existing configuration on
{$CATALINA_HOME}/
/webapps/manager/META-INF/context.xml with the following:
<Context antiResourceLocking="false" privileged="true" >
<CookieProcessor
className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
sameSiteCookies="strict" />
<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1 |.*" />
<Manager
sessionAttributeValueClassNameFilter="java\.lang\.(?:Boolean|Integer|Long|Number|String)|org\.apache\.catalina\.filters\.CsrfPreventionFilter\$LruCache(?:\$1)?|java\.util\.(?:Linked)?HashMap"/>
</Context>
I understand I can make use of the 'Context Fragment' can be added
to
individual applications, however this is not ideal for us because:
1 - Instead of me (one of the sysadmin) to manage access, this
responsibility would be handed over to the api developer to add to
his/her
code to be deployed to;
2 - This would also require to save credentials at code level
I am exploring now the options on 'Security-Constraint' on IP
restrictions,
but could not work it out quite yet.
There is also another option that is firewall rules. However, it
does
not
seem to help as the servers involved are in our internal network and
the
restrictions seem to be applied to servers, not different paths.
I hope I have provided clear details of the issue I am trying to
solve.
Thank you very much in advance for any idea/suggestion.
It sounds like the tools available aren't able to meet your needs. In
short:
1. IP/port-based firewalls can't distinguish between "paths" of a URL
2. RemoteAddrValve can be applied at <Host> or <Context> level, but
you
do not want to configure these in server.xml and/or an application's
META-INF/context.xml file
I want to double-check on #2 above: you said you wanted the developer
of
the APIs to determine who can call them. If that developer bundles a
META-INF/context.xml file with the RemoteAddrValve configured in it,
would that meet your needs?
There is another option. Extract the context.xml from the foo.WAR
file,
add the RemoteAddrValve and then place the context.xml file in
$CATALINA_BASE/<engine-name>/<host-name>/foo.xml
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
