tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Winter <andrewcwin...@gmail.com>
Subject Re: basic auth required on https but not required on http
Date Wed, 20 Feb 2013 11:30:22 GMT
On Feb 20, 2013 5:13 AM, "André Warnier" <aw@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" <aw@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).
>
>
>
>
The problem I ran into earlier with the URLRewriteFilter servlet is that it
broke the asynchronous request operation. It may be worth another try as
that was when I was using the comet implementation and I have since
rewritten it in the servlet api 3 version. I guess my only other option at
this point would be to modify the tomcat source to add a port attribute to
the web.xml section that defines which resources are too be secured with
basic auth?
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message