By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,369 Members | 1,188 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,369 IT Pros & Developers. It's quick & easy.

Downloading/opening file in client application window

P: n/a
The following code added to Page_Load works a treat:

Response.ContentType = "application/zip"
Response.AppendHeader("Content-Disposition", "attachment;
filename=DesktopChange.pdf")
Response.WriteFile("C:\Inetpub\wwwroot\Download\De sktopChange.pdf")
Response.Flush()

But *only* if the document exists in the web site or is accessible by the
ASPNET account. However, it fails if the document is stored on the network,
e.g. s:\temp\desktopchange.pdf. This isn't surprising as the ASPNET can't
access s:\Temp.

One workaround we've though of is using the upload file functionality to
upload from the client to the server into a temporary file and then serve up
this temporary file.

But this requires an upload and a download which is waste.

Anyone got any ideas how to solve this?

Cheers, Rob.
Nov 19 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
> One workaround we've though of is using the upload file functionality to
upload from the client to the server into a temporary file and then serve up this temporary file.


Ahh, we've realised the flaw in this paragraph as it goes like this:

BEGIN
Server knows the name of a file stored either on the client or on a network
share accessible from the client
Automatically upload it to the server [A]
Use Response.AppendHeader("Content-Disposition", "attachment; filename=XYZ")
to fire it back at the browser
END

The flaw is step [A] which is in effect giving the server the ability to
upload *any* file at will. Dangerous...

A workaround is to display a popup window which is in effect a <input
type=file> form which allows the uses to click "Upload" to upload the file
to the server so the server can then throw it back via
Response.AppendHeader.

All very clumsy! This is why I don't like webapps :-)

Rob.
Nov 19 '05 #2

P: n/a
Hi,
Assuming that you are running on Windows2003, in order that aps.net to
access the netowork resources, service should be running under network
service acount. also the folder being accessed should be configured to allow
the netowrk service account.
Regards
Sambathraj
"Rob Nicholson" <in******@community.nospam> wrote in message
news:eM**************@TK2MSFTNGP15.phx.gbl...
The following code added to Page_Load works a treat:

Response.ContentType = "application/zip"
Response.AppendHeader("Content-Disposition", "attachment;
filename=DesktopChange.pdf")
Response.WriteFile("C:\Inetpub\wwwroot\Download\De sktopChange.pdf")
Response.Flush()

But *only* if the document exists in the web site or is accessible by the
ASPNET account. However, it fails if the document is stored on the
network,
e.g. s:\temp\desktopchange.pdf. This isn't surprising as the ASPNET can't
access s:\Temp.

One workaround we've though of is using the upload file functionality to
upload from the client to the server into a temporary file and then serve
up
this temporary file.

But this requires an upload and a download which is waste.

Anyone got any ideas how to solve this?

Cheers, Rob.

Nov 19 '05 #3

P: n/a
Thanks for your posting Rob,

As for web application, the clientside ability is very restricted and web
application can't access most of the clientside resource. For example, we
can't alert or retreive any file on the clientside's local disk.(If not
using ActiveX control or other strong-typed code) The only means to
retrieve file stream from clientside is using the <input type="file" ../>
as you mentioned, this will need the client user to select file
interactively. So I don't think there will exit any security concern when
uploading file from client to server.

In addition, as for your scenario, you'd like to upload file from client to
server and write out the file to client again as attachment? I'm not sure
what's your application's detail logic, would you provide some further info
so that we may have a look to see whether there're any other potential
approachs?

Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)


Nov 19 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.