imrank wrote:
Hey,
Thanks for ur prompt reply.
Unfortunately, the approach you described wouldn't work in our case because
our app needs to do some custom authorization logic before a file can be
downloaded (sorry should've mentioned that). I dont think I can get httpd to
perform this authorization logic.
I have not yet met an authorization logic that can be done with Tomcat
and can't be done with Apache httpd (but I would be curious about the
details of yours, just to verify).
This being said, with us being on a Tomcat forum and that sort of thing,
it is maybe not the right place for that kind of discussion.
(I am available off-list if you would like to explore this however).
So let's for now suppose that the authorization logic is unmovable and
has to happen at the Tomcat level..
Can I use the approach of having all the files sitting on a single NFS file
server and have the different tomcat instances read/write the files to that
server's filesystem? I guess theres gonna be some cost in terms of network
latency...
You can certainly do that on the base of symbolic links and NFS mounts
for instance. Each Tomcat would contain something like :
(tomcat_dir)/webapps/your_app/the_docs --> /mnt/NFS/somedir_with_docs
Unless your network is really slow or these files really large, nowadays
network latency is probably not going to be the main concern.
The problem may be file and directory locking however, in a multi-user
and multi-Tomcat instances context.
You would have to make sure that no two Tomcats (and webapps within
these Tomcats) could conceivably be one reading, one writing the same
file at the same time. Through NFS this is not so easy. Note that you
would have the same kind of issue even if you did this through NFS at
the Apache level, but it may be easier because there is only one Apache
host.
Also, just to get you thinking on the subject of
authentication/authorization :
1) It is possible to conceive an AAA method at the Apache level, that
uses Tomcat as the AAA back-end. The basic idea is this :
- at the Tomcat level, you create a webapp that is basically a dummy,
and does nothing else than authentication/authorizing a request to it.
Its answer is a simple plain text response "yes" or "no".
- at the Apache level, whenever you need an authorization, you send a
background request to Tomcat and this dummy webapp, and read the
response (which could also be the user-id, instead of just "yes").
Then if the response is positive, you proceed; else you return "forbidden".
2) if you have an Apache front-end anyway, you can do /all/ the
authentication/authorization at the Apache level, thus freeing Tomcat(s)
for more interesting things. If Apache authenticates a request, it can
forward the obtained user-id to Tomcat when it proxies the request.
Check the "tomcatAuthentication" attribute to the <Connector> tag.
What ultimately makes more sense and is more efficient and is easier to
maintain, is a decision for you to make in function of your knowledge of
the setup and the usage patterns of the application.
Instinctively, if your configuration is as follows :
browser <--> Apache + connector <--> Tomcat + NFS <--> NFS fileserver
then the megabits have to circulate through more network and more code
than if the configuration is like this :
browser <--> Apache + NFS <--> NFS fileserver
For example, in the first case, if your Apache front-end and Tomcats and
the NFS fileserver are on the same network cable, then the same file may
end up being transferred several times over that cable, before it is
sent to the browser.
Also, if the serving of the static files is done at the Apache level,
you may be able to use one of the caching modules available at the
Apache level, to avoid even more network traffic.
But again that depends on the application, and how often the same files
would be requested over a period of time.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
