Niklas Johansson wrote:
I guess the link you sent is pointing to a similar way of doing it as I did. This
is my reference: http://sheetalshundori.blogspot.com/2008/02/struts2-dynamic-file-download.html
It's unclear to me what this code does that the normal stream result
does not, but let me point out a couple issues that might have been
causing you problems, and another that still might in the future:
On your page you have this snippet of XML:
<result name="success" type="stream">
<param name="contentType">image/jpeg
<param name="inputName">imageStream
<param name="contentDisposition">filename="document.pdf"
<param name="bufferSize">1024
</result>
but it's *not* XML. The each param needs a </param> at the end.
The contentDisposition (both there and hard coded in your class) is
invalid: http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1
This is a common mistake and therefore many browsers can deal with
invalid values, which is why you didn't notice this bug before. Another
small issue which one commenter on your blog page mentioned is the
missing specification of contentLength.
More importantly you seem to let the URL presented determine the
filename this code will ask the browser to use for the downloaded file,
and this is a potentially dangerous security hole. If you know anything
about the application domain, it would seem much safer to restrict the
range of potential downloads here, hard-coding the extension based on
(already verified) mime-types. For example, this is where you could
replace the dots in the filename with dashes so that your hardcoded
extension is the only one that the browser/destination OS might use to
determine what to do with the file. (For example this is where a file
named "struts.2.1.6.tgz" might get renamed "struts-2-1-6.tgz".)
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
