I'm trying to download a file using a servlet. If I make use of Content Disposition response Header,an open/save dialog box would appear. Is there a way that I could save the file directly to a folder instead of selecting the destination from the dialog box. I would need this approach since. the file is being downloaded from a batch rather than a webapp.
If it were possible, any arbitrary website would theoretically be able to silently write malware to visitor's disk without any notification. Would you as being the visitor appreciate it?
I don't think so.
It's fortunately not possible to write anything to visitor's disk without confirmation by standard HTTP/HTML means. The world wide web would have looked very different.
If you have really a hard head in this, then your best bet is creating a signed(!) Java applet for the job of file downloading and saving. You see this also often on those "large" websites as so-called "Download Managers" which can easily annoy endusers. Again, do this only if you have really a hard head in this.
Related
I am trying to restrict the user from downloading the page as .html or .aspx file from browser.
Or is there a way to change the content of file if its downloaded?
This is a complex area, with lots of moving parts. The short answer is "there is no way to do this with 100% success; there are a few things you can do which make it harder".
Firstly, you can include JavaScript to disable the right click context menu. This doesn't stop Ctrl+S, but might discourage casual attempts.
Secondly, you can use DRM in the browser (though this is primarily aimed at protecting media content. As browser support is all over the show, this isn't realistic right now.
Thirdly, you could write your site as a single page web application, and build some degree of authentication into the "retrieve content" logic. This way, saving the page to disk wouldn't bring the content along, just the "page furniture". However, any mechanism you include to only download content when you think you should is likely to be easily subverted by anyone who is moderately motivated.
Also, any steps you take to stop people persisting your pages locally are likely to break the caching mechanisms on which the internet depends for performance, so your site would likely be dramatically slower.
No you can't stop them.
Consider how the web actually works here: once the user has visited your website and loaded your page into their browser, they have already downloaded it - the web page was transmitted from your server to their computer and appeared on their screen.
All they have to do then is click the Save button to keep it permanently on their disk. That doesn't involve downloading it again, it just copies the page data from a temporary folder to a permanent one. Of course it's also possible for people to use another HTTP client (i.e. not a browser, but maybe an existing program, or some code they wrote themselves) to visit the URL of your page and save the returned contents.
It's not clear what problem think you would solve by stopping people from saving pages. Saving the page is something done within the browser - you as a site developer don't control the user's browser, so you can't prevent that. And if you stop them from downloading your page in the first place then - by definition - you also stop them from using your website...which kind of defeats the point of having one :-).
If you've got some sort of worry about security, you'll have to clarify exactly what you are concerned about, and maybe you can get advice about a sensible way to deal with it.
As I understand it, when a link to a file is clicked in the browser, the file is silently downloaded to a temporary directory on the computer. Then the prompt is displayed which shows Open, Save, Cancel... Then if the user clicks Save, they are prompted to save it somewhere, and finally the file is basically transferred to that location when confirmed.
Assuming that is correct, I'm looking for a way to determine if the user actually downloaded the file. So basically determine if they clicked the Save button.
The bit of research that I've done leads me to believe this is not possible, because there is no standardized way of capturing that event, however I could be wrong. And the only possible solution I can come up with is to create an actual client application. Any thoughts on that?
Also, if there are any other off the wall ideas, I'm open to those as well.
And in case it makes a difference, I'm working within an ASP.NET environment.
How about turning this whole problem around and audit the file that actually being downloaded. You can turn on file/folder auditing and capture onlyt the success and failures of the IIS process. Then correlate the audit event with the pieces parts in the IIS log to get the particulars of who actually downloaded the file.
Just my $0.02 YMMV
Yes, I'm still using Classic ASP.
I'm about to write a script that checks a directory on the server, every 5 minutes, for newly uploaded photos, by my office, and to transfer the photos to another location. I'm using ASP and the FileSystemObject as the application and a Windows Schedule calls it.
What I would like to know is: If the user is sending 150 photos, by FTP, my application is not going to know if the user has finished uploading, or not. So then the application will go through the files one-by-one and transfer them. If my user has a slower connection than the speed of my application, the script may eventually come across the file that is currently being uploaded...
Will my application grab that file thinking it's complete or will it know that it's in the middle of upload and leave it alone? If it DOES grab it and transfers half a photo, how can I stop this from happening?
There is no good way to test for that, much depends on how the uploader is working.
Its highly unlikely that a file currently open for write access while the uploader creates it is going to allow your code to move it. An attempt to move it will result in a sharing violation or similar error. So protecting that section of code with an On Error Resume Next would do it. Have your code skip that file in the knowledge that it will be picked up again when the next poll comes round.
I have a hyperlink to an executable like so: Run Now
I'm trying to make the download dialog box appear without the save function as it is to only run only on the user's computer.
Is there any way to manipulate the file download dialog box?
FYI: Running on Windows Server '03' - IIS.
Please no suggestions for a WCF program.
Okay I found it for anyone stumbling upon this conundrum in the future.
Add the following tag to your head section: <meta name="DownloadOptions" content="nosave" /> and the file download dialog box will not display the "save" option.
For the user to not open/run but save replace "nosave" with "noopen"
Not unless you have some control over a user's machine. If your application can run on limited resources, you might want to consider doing it in Silverlight.
IMO, having a website launching an executable is a pretty bad idea.... even worst if that website is open to the general public (not on intranet). I don't know what that app is doing but it sure is NOT, 1) cross browser, 2) cross platform, and 3) safe for your users.
If you are on intranet, you might get away with giving the full server path (on a shared drive) to the executable and change security settings on your in-house machines.
Other than that, you won't succeed in a open environment such as the Internet.
From your comments, if the user downloading the file is the issue, then there's no way to get around it, as they have to download the file in order to be able to run it.
There's any number of ways to get around whatever you could manage in browser, from proxies like Fiddler intercepting the data, or lower level things like packet sniffing. Or even simply going into the browser's temp/cache folder and copying the file out once it's running.
You could probably get around most laymen by having a program that they can download that registers a file extension with Windows. Then the file downloaded from this site would have the URL of the actual data obfuscated somehow (crypto/encoding/ROT-13/etc). The app would then go and grab the file. The initial program could even have whatever functionality provided by what you want to download, but it needs the downloaded key.
But this is moving into the area of DRM and security by obscurity. If an attacker wants your file, and it's on the Internet, they will get the file.
I need to add a file upload function to an ASP.NET website and would like to be able to read a small portion of the file on the server while it's still uploading. A peek or preview type function so I can determine contents and give some feedback to the user while it is still uploading (we're talking about large files here). Is there any way to do this? I'm thinking worst case of writing a custom control which uploads only a fixed number of bytes of the file once chosen and then under the covers starts another upload of the full file. Not totally sure even this is possible, but I'm looking for a more elegant solution anyway... Thanks!
It sounds like you want to avoid the "white screen of death" during large file uploads. If so, you might want to look into Telerik's RadUpload control , which provides a progress bar during upload.
If you want to roll your own, I'd decompile their trial copy for ideas. I've peeked at their source in this way, and they accomplish the progress bar through a combination of a custom HttpModule and HttpHandler along with their control. The handler routes the file in a streamed fashion while the module provides "percent complete" information--or the other way round; it's been a few years since I looked at it.
Edit:
Actually, I'm trying to do server-side processing as the file is still being uploaded. I want to import user data via HTTP, but want to present the user with preview/options of how we'll process their data while the file is still uploading (column definitions, etc.). No matter what, we'll take the file as is, so the upload doesn't need to be interrupted. Given that I actually want interaction during the upload based on reading a relatively small portion of the file as it is being uploaded, would you still recommend the same approach?
Well... it'd be very difficult to do, and it might not work cross-browser, but it could be done with this approach.
Since it's entirely possible to work with the incoming file as a stream as I mentioned, you could have your intial processing update some state as part of that stream processing. If you don't process as a stream, you have to wait for the full file upload before you can do anything with it.
The problem is this: during the file upload, you cannot have any more HTML-based interaction. The post must continue unabated or the upload will fail. The control I linked only works at all because most browsers allow javascript to continue to execute and update page DOM during the post.
So in order to make this work, you have to update some standardized state server-side during your file processing in the HttpModule, which is transmitted back to the client via XmlHttpRequest calls handled by the HttpHandler. You have to use pure javascript/DOM to update the UI for the user.
So, as I said, it's complex and likely to be buggy cross-browser, but it could theoretically be done.
There are alernatives that might be more stable, but might not necessarily be feasible: you could build an ActiveX control or a Click-Once .NET application that pre-processes the file before upload, and maybe even asynchronously transfers the file while the user continues browsing. Some users may not like that option, and I don't know the particulars of your deployment scenario, but it's an option.
There is an HTTP HEAD method but not PEEK.
HEAD will give you information and headers about the file.
Of course you can make a special request handler that does anything you want. You don't have to work with static resources, you can dynamically create any response you want.