André, On 4/11/18 5:47 PM, André Warnier (tomcat) wrote: > On 11.04.2018 16:36, Christopher Schultz wrote: >> 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. > > Ah, but that is something which you did not mention before (that the > authentication/authorization must be done by Tomcat).
I tried to mention that: On 4/10/18 9:53 AM, Christopher Schultz wrote: > 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. I neglected to mention that "Tomcat is providing the authentication/authorization, here". I guess I thought it was implied. Apologies. >> 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. > > Exactly. That's not available off-the-shelf, but feasible at the Apache > level. > (In fact, I have something just like that (mod_perl based) which uses > Tomcat as an "authenticator" for resources deployed at the Apache level). > So let me know if your current solution is still unsatisfactory and you > want to move these things back out from your app servers deployments. Hah, it might be worth taking a look. Care to post the code somewhere? >>> 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. > > Thinking further about this, you are certainly not the only person who > has that kind of requirement. > And it would probably not be a big deal for the people who developed > mod_proxy_ajp at the Apache httpd level, to create such an Apache httpd > "authentication provider" based on tomcat as a back-end. (See : > http://httpd.apache.org/docs/2.4/howto/auth.html). > I'm just saying.. Are you raising your hand? ;) -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
