tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: basic auth required on https but not required on http
Date Wed, 20 Feb 2013 10:13:13 GMT
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 :
>> server.xml :
>> ....
>>   <Engine ...>
>>     <Host name="" appBase="/some/dir/number1" ..>
>>        ...
>>     </Host>
>>     <Host name="" 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" <> 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
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 ( 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).

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message