There are a couple of other points that might need clarification...
To set the appropriate content type header, implement the getContentType()
method as shown below. You may also want to send a Content-Disposition
header so that the browser knows what the file name is.
The following sample ignores error checking, etc., but should illustrate
the important points. You would navigate to a URL that looks something like
this:
http://<server>:8080/app/servler/app?screen=Download&fileID=12345
public class Download extends RawScreen
{
private String fileID = null;
/** Determine the content type of the file */
protected String getContentType(RunData data)
{
// Determine what file is requested.
ParameterParser params = data.getParameters();
fileID = params.getString("fileID", "");
// determine the content type based on what file is requested
String contentType = "application/pdf"; // OR WHATEVER
return contentType;
}
/** Write the file content into the browser reponse */
public void doOutput(RunData data) throws Exception
{
// Check if this action should be allowed on this file
if (isAuthorized(data))
{
data.getResponse().setHeader("Content-Disposition", "inline;
filename=<filename here>");
ServletOutputStream responseStream =
data.getResponse().getOutputStream();
// open the file and write its content to responseStream
...
}
else
{
// Handle user not authorized
...
}
}
/** Determine if the user is allowed to perform this download */
protected boolean isAuthorized(RunData data)
{
User currentUser = data.getUser();
// check user authorization for the given fileID and return true or
false
...
}
Kevin
> -----Original Message-----
> From: Eric Dobbs [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 15, 2002 10:06 AM
> To: Turbine Users List
> Subject: Re: PDF Files within Turbine Framework
>
>
>
> On Monday, April 15, 2002, at 06:47 AM, Darin Wilcox wrote:
>
> > Ben,
> >
> > Any kind of example would be greatly appreciated.
> >
> > - Darin
> >
> > <<< [EMAIL PROTECTED] >>>
> > You could, however, write a ServePDF Action that brings
> back the PDF
> > file to
> > the browser after it has successfully validated that the
> user has the
> > proper
> > rights. The PDF file to serve could be propagated via a PATH_INFO
> > variable, so
> > that from a URL point of view you could make this fully transparent.
> > Still, this solution will never reach the performance of
> serving the
> > PDF directly.
>
> I don't think an action is the right place for this.
>
> Back in February I posted a message about how to use
> a RawScreen to authenticate a user before allowing
> them to download a file:
>
> http://nagoya.apache.org:8080/eyebrowse/ReadMsg?listName=turbine-
> [EMAIL PROTECTED]&msgId=76060
>
> Hope that helps.
> -Eric
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
