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

Reply via email to