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 18:40:06 GMT
Andrew Winter wrote:
> On Wed, Feb 20, 2013 at 5:13 AM, André Warnier <> 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".
>>>> 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 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 ( 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.
You could probably just "force" an authenticated user into Tomcat (userPrincipal and that

kind of thing) when the connection is internal. That would also probably solve your 
programmatic access case.

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

View raw message