On Wed, Feb 20, 2013 at 5:13 AM, André Warnier <a...@ice-sa.com> wrote:
> The standard modus operandi of this list is to not top-post (makes it more > difficult to follow the logical flow of conversation). > So I've copied your response and my further comments at end. > > >> Andrew Winter wrote: >>> >>> I work on an intranet type application. While on the local network >>>> calls >>>> are made to regular http and authentication is not allowed due to a >>>> large >>>> number of established services that call the server without providing >>>> authentication. However, the server accepts calls from the outside over >>>> SSL (regular http port is blocked by firewall). In these cases the use >>>> of >>>> basic authentication is required. I don't see a way to have work like >>>> this. With our older setup we used Apache as a front end and had a >>>> virtual >>>> host file for each port. One used https and basic auth and the other >>>> didn't. Both pointed to the same web app. Now I must send calls >>>> directly >>>> to Tomcat as we are implementing asynchronous requests. What can I do >>>> here? >>>> >>>> >>>> Do the same as under httpd (except one thing) : use separate <Host>'s >>> within the Tomcat configuration (same as <VirtualHost> under Apache). >>> Deploy a separate copy of your webapps within each <Host>'s "appBase". In >>> one <Host>, you protect them via Basic Auth, in the other <Host> you do >>> not. >>> >>> Under Tomcat, it is not recommended to use the same "appBase" (roughly >>> the >>> same >>> as Apache's "DocumentRoot") for two separate <Host>'s, because this >>> creates problems of double deployment etc. So use two separate sets of >>> webapps. They are still the same webapp, just deployed twice, in >>> different >>> locations. Is that a problem for you ? >>> >>> Roughly (check the proper syntax on tomcat.apache.org) : >>> >>> server.xml : >>> >>> .... >>> >>> <Engine ...> >>> >>> <Host name="host1.company.com" appBase="/some/dir/number1" ..> >>> ... >>> </Host> >>> >>> <Host name="host2.company.com" appBase="/some/dir/number2" ..> >>> ... >>> </Host> >>> >>> ... >>> >>> /some/dir/number1 >>> |- ROOT/ >>> |- webapp1 >>> |- webapp2 >>> >>> /some/dir/number2 >>> |- ROOT/ >>> |- webapp1 >>> |- webapp2 >>> >>> the 2 "webapp1" are the same (same code, same files,..) (*) >>> the 2 "webapp2" are the same >>> >>> (*) actually, almost the same, since their WEB-INF/web.xml will be >>> different : one has to be accessed via HTTPS and use Basic Auth, the >>> other >>> one not. >>> >>> >>> Andrew Winter wrote: > > Thanks. A lot of file IO goes on with this app. There are a couple of > files > > in particular that are held open for the life of the app and written to > > sporadically. I am thinking that having the same code as two web apps > would > > lead to those files getting clobbered. Is there a way to make the 'same > > appbase with 2 hosts' version work? > > On Feb 19, 2013 5:57 PM, "André Warnier" <a...@ice-sa.com> wrote: > > Well, at first I'd say no. Even if you were to point both appBase's at > the same disk location (and turn off "auto-deploy" !), you would still > logically have different "instances" of the webapp running at the same time > (one for each host, at least). > > There are certainly other ways to achieve what you want to do, but I am > getting a bit out of my depth here, so be careful of what I'm saying next, > and maybe wait for other more qualified people's comments. > > One way that I could imagine would be to have a single <Host> with an > alias, and wrap your webapp inside of a "servlet filter", which would check > the host/port that the request came in from. If it came in through the > HTTPS connection (or the appropriate HTTPS hostname, or a not-from-Intranet > IP address), the filter would allow the request to proceed only if it is > authenticated, and otherwise redirect it to a login page e.g. > Maybe the URLRewriteFilter servlet filter (www.tuckey.org) would allow > such a thing. It's a bit like the workhorse for things like that. > Otherwise you'd have to write your own (or get it written). > As a servlet-filter based solution, that would not require any > modification to your webapp. It would not even know that it is being > "wrapped" that way. > There are certainly people on this list who would be available for a > little job like that. > (Not me though). > > > > > Okay, I have this resolved, now. I went with the FORM authentication method and created a servlet that will create a login screen on an isSecure() connection. For standard HTTP requests I pass over a self submitting form with the credentials included. This will work for the human interfaces and I will just have to deal with any programmatic access problems as I find them. Thank you for all your help!
