Setting up a second container with a different port was easy enough.
However I got stuck on the URL mapping/rewriting. Using nginx as a
proxy, I don't think it's possible to rewrite headers with the
upstream module:
https://nginx.org/en/docs/http/ngx_http_upstream_module.html
As I understand it just forwards raw traffic, so the URL rewriting
would have to be done on the Tomcat's side. Basically I want to
rewrite:
https://localhost:5443/ => https://localhost/
which requires rewriting the Host request header, I think.
I was looking at the RewriteValve, but it says:
"Unlike newer mod_rewrite versions, the Tomcat rewrite valve does not
automatically support absolute URLs (the specific redirect flag must
be used to be able to specify an absolute URLs, see below) or direct
file serving."
Is there a way to rewrite the hostname/port in configuration?
Something placed in context.xml would be ideal.
On Thu, Feb 27, 2020 at 11:52 AM Martynas Jusevičius
<marty...@atomgraph.com> wrote:
>
> Tomcat is deep within the Docker image configured with a single
> connector and a single ROOT webapp, so it's easier to deploy a second
> container than to add a second connector or context :)
>
> Thanks for your help.
>
>
> On Thu, Feb 27, 2020 at 11:36 AM Mark Thomas <ma...@apache.org> wrote:
> >
> > On 27/02/2020 10:28, Martynas Jusevičius wrote:
> > > Yes, that could be an option. Or, since we're on Docker, a second
> > > instance of the webapp on a different port would be easier.
> > >
> > > But we would need to add some URL rewriting proxy before that
> > > connector to strip that port number to make the webapp see the
> > > canonical URLs. That should be doable with nginx which we are using
> > > anyway.
> > >
> > > So essentially 2 webapps on different ports, one configured without
> > > the clientAuth for the end-users, and one with clientAuth for the API
> > > access, correct?
> >
> > It depends on what you can / want to change.
> >
> > The approach you describe should work.
> >
> > If you can change the clients, a second Connector for the same
> > Service/Engine/Host/Context is all that should be required.
> >
> > Depending on the URLs used, you might be able to deploy two versions of
> > the web application to different Contexts, remap the internal servlets
> > and still have clients see the same URLs. In that case you could move
> > the client auth requirement to the web application.
> >
> > There are quite a few options. It really comes down to want you can
> > control, and what is easiest for you to change.
> >
> > Mark
> >
> >
> > >
> > > On Thu, Feb 27, 2020 at 11:18 AM Mark Thomas <ma...@apache.org> wrote:
> > >>
> > >> On 27/02/2020 09:58, Martynas Jusevičius wrote:
> > >>> Hi list,
> > >>>
> > >>> I'm using a Docker image based on tomcat:8.0-jre8. It serves as an
> > >>> end-user facing webapp but also as a REST API which authenticates
> > >>> using client certificates. The same URLs serve both purposes, however
> > >>> only administrators are using the API.
> > >>>
> > >>> The Connector is configured using clientAuth="want".
> > >>> This works fine with API calls which are run from shell scripts.
> > >>> In the browser however it prompts a certificate selection (if there
> > >>> are any client certs). This would not be a problem if the webapp would
> > >>> not be user-facing, but since it is the certificate prompt can be
> > >>> confusing to many users and increase our bounce rate.
> > >>>
> > >>> I'm looking for some workaround that would not require changing the
> > >>> whole design. For example asking for the client cert only when a
> > >>> certain flag is set, such as a query param or request header.
> > >>> Or somehow not asking for it but still accepting it :) But I guess
> > >>> that's not how TLS works...
> > >>>
> > >>> Any ideas? Thanks.
> > >>
> > >> Can you configure a separate connector on a different port for the shell
> > >> scripts to use?
> > >>
> > >> 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
