If the content is available from another servlet context then hasn't this added 
(only) more obscurity rather than security?  It seems for the security the 
servlet must do the authorization check before serving hence, again, I don't 
see how it relates to Tapestry.

Thanks, 

Ezra Epstein 


-----Original Message-----
From: Murray Collingwood [mailto:[EMAIL PROTECTED] 
Sent: Friday, July 28, 2006 2:14 PM
To: Tapestry users
Subject: RE: Streaming files from Tapestry

Hi Ezra

I did look at doing this as a work around, however it has one major flaw - it 
doesn't provide any security.

In a CRM system, for example, if the document download link is 
http://webserver/MyOtherWebContext/images/000001.doc then it's not going to 
take somebody long to realise they can type in other numbers and retrieve 
documents that they may not have access to.

With a servlet running inside my application I can check the users security 
immediately before I stream the document.

The other benefit of keeping the servlet as part of my application is that I 
can store the external directory name in one location rather than two.  A small 
benefit.

My final argument is that the faq should be providing the recommended solution. 
 Obviously lots of people have already asked for this (that's why it's in a 
faq) so I'm not alone out here...

I have written a small servlet to do what I want.  It has limited functionality 
but it serves my immediate purpose.  I am still hopeful that somebody will 
deliver a servlet or library that does serve this purpose in a better and 
generic method, I am happy to be the first to test and implement it.

Cheers
mc


On 28 Jul 2006 at 9:53, Epstein, Ezra wrote:

> I'm not sure I really followed, but your option "c" doesn't seem to have 
> anything to do with a web framework (tapestry or otherwise).  Rather you're 
> just dynamically generating some text a la:
> 
> <img src="/MyOtherWebContext/images/my-dynamically-named-image.gif" />
> 
> Or whatever.  The only part of that which is dynamic is the image name.  And 
> "Any" tag can give you this no sweat.  Maybe the name of the other web 
> context is a config param and so is "dynamic" too.  Again, no sweat.
> 
> As for the serving of the static files themselves (the name of a given file 
> is "dynamic" in that if you're showing the details of a CD then the image 
> name may depend on the product, but the image itself is in a web servers file 
> system) any web server will do.  Apache, Tomcat, JBoss, etc.   I think the 
> problem is with the word "stream".  Stream implies dynamically feeding data 
> into the response.  I think your question is about serving images.  If so, 
> it's a snap.  For example, I serve my "Tapestry" javascript files (same 
> applies to images) simply as:
> 
> <script type="text/javascript" 
> src="/MyTapestryAppName/js/myJavaScriptFile.js"></script>
> 
> Works great.
> 
> Perhaps I misread the question.
> 
> Thanks,
> 
> Ezra Epstein
> 
> 



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.10.4/402 - Release Date: 27/07/2006


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to