Re: Virtual directories, PostResources, and DefaultServlet

[Christopher Schultz]

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 .

 Before I do that, I was thinking that maybe I could point
  at a (private) URL that points back to the location
 where these files were already available. I was kind of hoping that
 simply doing 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

Re: Virtual directories, PostResources, and DefaultServlet

[tomcat]

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 .

Before I do that, I was thinking that maybe I could point
 at a (private) URL that points back to the location
where these files were already available. I was kind of hoping that
simply doing 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).


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.





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..


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

Re: Virtual directories, PostResources, and DefaultServlet

[Christopher Schultz]

Woonsan,

On 4/10/18 11:11 AM, Woonsan Ko wrote:
> On Tue, Apr 10, 2018 at 9:53 AM, 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 .
>>
>> Before I do that, I was thinking that maybe I could point
>>  at a (private) URL that points back to the location
>> where these files were already available. I was kind of hoping that
>> simply doing 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?
> 
> How about Reverse Proxy Servlet Filter?
> - http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html

I had thought about that, but in the end, I ended up just adding a build
target called "download-stuff" that puts the files into my web
application on each app server. Too bad 'ant' is really bad at
downloading multiple files over HTTP. :(

-chris

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

Re: Virtual directories, PostResources, and DefaultServlet

[Christopher Schultz]

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 .
>>
>> Before I do that, I was thinking that maybe I could point
>>  at a (private) URL that points back to the location
>> where these files were already available. I was kind of hoping that
>> simply doing 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Virtual directories, PostResources, and DefaultServlet

[tomcat]

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 .

Before I do that, I was thinking that maybe I could point
 at a (private) URL that points back to the location
where these files were already available. I was kind of hoping that
simply doing 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 ?

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..




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

Re: Virtual directories, PostResources, and DefaultServlet

[Woonsan Ko]

On Tue, Apr 10, 2018 at 9:53 AM, 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 .
>
> Before I do that, I was thinking that maybe I could point
>  at a (private) URL that points back to the location
> where these files were already available. I was kind of hoping that
> simply doing 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?

How about Reverse Proxy Servlet Filter?
- http://portals.apache.org/applications/webcontent2/reverse-proxy-module.html

Regards,

Woonsan

>
> Thanks,
> -chris
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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