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