tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Virtual directories, PostResources, and DefaultServlet
Date Wed, 11 Apr 2018 14:36:06 GMT
André,

On 4/10/18 11:38 AM, André Warnier (tomcat) wrote:
> Hi.
> 
> On 10.04.2018 15:53, Christopher Schultz wrote:
>> All,
>>
>> I've been asked to take some static files we already have on our
>> (reverse-proxied) web servers and require authentication before allowing
>> the resources to be fetched by a client.
>>
>> One way to do that would be to physically (electronically?) move the
>> files from the web servers to the application servers, either as a part
>> of the web application itself (tricky due to licensing issues of these
>> documents) or as a separate set of files in an arbitrary place on the
>> disk e.g. using <PostResources>.
>>
>> Before I do that, I was thinking that maybe I could point
>> <PostResources> at a (private) URL that points back to the location
>> where these files were already available. I was kind of hoping that
>> simply doing <PostResources base="http://static/files/here/"
>> webAppMount="/static" /> or something like that.
>>
>> It looks like the existing WebResourceSet implementations are all
>> disk-based resource providers.
>>
>> It also seems like writing a simple, read-only, "non-listable"
>> implementation of an HTTPResourceSet might work for me.
>>
>> So I'm looking for opinions on what I should do, here. I might be able
>> to hack-together an HttpResourceSet, but it probably won't benefit from
>> e.g. range-requests (the files I am serving are PDFs, which often
>> benefit from being able to perform range-requests) and might be fragile.
>>
>> I could move the files to the application servers, but then I need to
>> make that a part of my app-server build process and I'd like that to
>> remain as simple as possible.
>>
>> Finally, the files cannot go into revision-control due to licensing
>> restrictions, so we basically have to keep them ... "safe" until they
>> are deployed.
>>
>> Any ideas or suggestions?
>>
> 
> I know that when you have a hammer, everything looks like a nail but why
> not set up a separate Apache httpd webserver for these things, and have
> your reverse-proxies direct the calls there for them ?

Well, my reverse-proxies are already httpd instances, so there's no need
for ANOTHER instance.

The problem is that I need Tomcat to enforce
authentication/authorization for these resources. The reverse-proxy
cannot do that, and neither can some other web server that isn't in
communication with Tomcat.

Unless there is a mod_is_user_logged_in_to_tomcat that can ping Tomcat
to see if a user is indeed logged-in and then only serve the resource if
it gets back a positive response.

> Or, use URLRewriteFilter to redirect these calls to wherever you want.
> I'm saying that because it doesn't really sound like you want to mix
> this up too much with your Java apps..

Directing the traffic isn't the problem. Enforcing authentication is.

Thanks,
-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message