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).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
