Hi Mark,
I was away and that's why I did not provide an outcome.
For whatever reason, despite following the steps you have provided, the
foo.xml file was removed after the deployment.
However, I did some work around it and added a piece of code on Puppet. So,
this makes sure the file is always at
{$CATALINA_HOME}/conf/Catalina/localhost.
I found an article about adding more than one 'context' element to
'context.xml' at, but could not make it work.
So, for the time being, I will keep using the individual foo.xml files (one
for each application).
Thank you very much for all the attention given to this post.
Kind Regards
Mar Sil
On Wed, 12 May 2021 at 11:20, Mark Thomas <ma...@apache.org> wrote:
> 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
>
>
