RE: RE: Witango-Talk: return protected file

[Simon Boddy]

Title: RE: Witango-Talk: return protected file

Hi Trevor,   There is another approach to this which I prefer. When your app has validated the user's right to see the file, create a directory with a long name, ie the user reference, in a temporary area. Write the file to the new directory, giving it a meaningful name, then redirect the user with an url that points to the file. This solution is logically **as secure** as serving the binary file through Witango, because it relies on the security of the session reference, just as the Witango session does.   This solution has the disadvantage that you need to take care of cleaning up the files afterwards, but it has a couple of advantages... 1. You are not serving large binary files through Witango, which it was not really intended for. 2. You don't have to fiddle with setting the http headers. 3. If I remember, IE takes the extension on the url as an indication of the content type of the response, so no matter what http headers you set, you may find IE will not deal with a pdf, say, if the url with which it is requested does not contain the .pdf extension.   Good luck.   Simon Boddy. -----Original Message----- From: Trevor Green [mailto:[EMAIL PROTECTED]] Sent: 05 June 2002 14:23 To: Multiple recipients of list witango-talk Subject: RE: RE: Witango-Talk: return protected file Thanks Henning, this is exactly what I was looking for. T.   -----Original Message----- From: Henning Sittler [mailto:[EMAIL PROTECTED]] Sent: 05 June 2002 03:10 PM To: Multiple recipients of list witango-talk Subject: RE: Witango-Talk: return protected file   Trevor, this is what Scott Cadillac sent me on the list, and I'm using it now (with the exception that I'm not reading anything about the file from a database, so I get the values for Content-Type, Content-Length, etc from other places. Try the site Scott mentions below: http://xml-extra.net/webpage.xmlx?node=38   #############   Hi Henning, You are missing a couple of important bits like the 'encodeResults' variable setting to prevent your binary characters from being converted to HTML entities and the 'Content-Length' of the download file. Also, I find that for secure downloads adding the <@userreferencecookie> prevents Witango from issueing a new UserReference which could break your user session. <@assign name="encodeResults" scope="local" value="false"> <@assign name="httpHeader"     scope="local"     value="Content-Type: <@var local$resultSet[1,MimeType]><@crlf>Content-Length: <@var local$resultSet[1,FileSize]><@crlf>Content-Disposition: inline; filename=<@dq><@var local$resultSet[1,Filename]><@dq><@crlf><@userreferencecookie><@crlf>"> Then where you do your output, it should look like the following to clean out any whitespace that Witango will sometimes through in between the HTTP Header and the content: <@PURGERESULTS><@VAR local$dlfile ENCODING="NONE"> I wrote a short article about this kind of procedure and there is a sample file for download. http://xml-extra.net/webpage.xmlx?node=38 Hope this helps. Cheers... Scott Cadillac http://xml-extra.net [EMAIL PROTECTED] VP, Research and Development Plus International Corp. 604-460-1843 [EMAIL PROTECTED] http://www.plusinternational.com Vancouver, BC, Canada Does your company have an Enterprise Information Portal? Check out Salsa at www.plusinternational.com/flash/salsa.htm ----- Original Message ----- From: "Henning Sittler" <[EMAIL PROTECTED]> To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]> Sent: Friday, May 24, 2002 12:00 PM Subject: Witango-Talk: Contstrained File Downloads   > Ok, I tried asking this last week or so, but I'm not sure I ever saw my own > post get to the list, nor any replies. > > I'd like to offer file downloads without linking directly to an openly > avialable file. > > <@COMMENT> > <a href="http://www.thesite.com/files/thefile.zip">Download the file</a> > This works but won't suit my needs, because anytime can just download the > file without any validation. > </@COMMENT> > > I'd like to store the file in a non-webserver accessible folder, and > reference them indirectly through Tango.  The link to download the file > shown by one taf would point at another taf (opened in a new window let's > say) which verifies the user is ok to download the file, then reads the file > from disk and ouputs only the file. > > Given the proper Content-Type headers are output by the second taf before > outputing the file contents, this should prompt the user to download or open > the file, right? > > Now all my files will be (or most likely be) .zip, so: > Content-Type: application/zip > > should do it, right?  Well, it's not.  The attached taf's h.taf and i.taf > illustrate.  They have been kept super minimal for experimentation purposes. > Checking procedures and complexity can come once the downloads work. > > Also, IE likes to download the taf file instead of the zip file, which I > understand is a documented IE bug. > > Any thoughts?  Thanks much, > > > Henning Sittler > www.inscriber.com > > ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]                 with unsubscribe witango-talk in the message body Henning Sittler www.inscriber.com   -----Original Message----- From: Trevor Green [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 05, 2002 8:13 AM To: Multiple recipients of list witango-talk Subject: Witango-Talk: return protected file   Is there a way for Tango to return a file (contents unknown - may be a word doc or an excel file, etc.) from a protected location to a user? The application is such that there would be a directory on the webserver containing files that must not be accessed through a URL but may need to be returned to a user within the application that has rights to view the files. Windows based installation using IE. Regards Trevor Green ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been checked for the presence of computer viruses. **********************************************************************