Andrew Winter wrote:
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.
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
