I need to update a pair of old classic asp pages— a search.asp page that provides a simple form which is then posted to a results.asp page. One of the form options on the search page is a drop down list (<select) for the "format". If the user chooses the excel format the results page just sets the Response.ContentType to application/vnd.ms-excel and adds a content-disposition header to set the file name and make it an attachment. That's it: it's up to excel to then correctly render the html, and it generally does a pretty good job.
All that works pretty well, except for one thing. The reason for the Excel option is that in this case the users really do want to see as many as 10,000 items or even more for a single search. They'll use Excel to do some additional analysis on the results. So the search operation typically takes just over a minute and I can't change that.
The user experience during that minute is less than ideal. Not only is the user just sitting there with little to no feedback, but there are often enough results that the page overflows the response buffer. This means the page has to flush periodically, and therefore the file starts downloading right away but the download manager isn't able to provide meaningful feedback by itself. My mission is to improve the situation.
The first step is to just show a simple processing... message on the search page when the form submits, and I can do that easily enough. In fact, it's been doing this already for the "HTML" format option. The problem is that when downloading the Excel file I don't know how to tell anything about the download so I can hide the message again, and the existing implementation doesn't provide any feedback on download progress at all. Any ideas? If I can just get a javascript function to fire when the download completes I can hook just about anything to that, but I can't even do that yet.
Update:
I re-worded the question to try to present the problem more clearly.
As far as I know, browsers don't offer you any hooks as to how far a download has progressed. In theory, you could do something on the server side and use AJAX to query the server to see how much of the download has been sent, but I don't know how to do it.
hmm, would it be possible to do this via ajax maybe? ie, user selects the format, query is sent via ajax, and the appropriate document is loaded into an iframe on search.asp for example. you could then pick up the succesful event in your ajax call and appropriately deal with the messages.
I would recommend looking into modifying your upload method to use something like SWFUpload which allows for JavaScript callback on the code. Once the file is uploaded (assuming you are storing it), I would look into passing the filename and type to your Results.asp page where it would then retrieve it form the file store. It's not as secure as keeping it in memory which you elude to in your question; however, would provide a better user experience and may provide the callback solution you need.
http://swfupload.org/
Here's a jQuery plug in example that makes the upload process and SWFUpload integration easy:
http://blog.codeville.net/2008/11/24/jquery-ajax-uploader-plugin-with-progress-bar/
You could have the file download as an attachment by adding a header, so that the user's browser remains operational. I realize this isn't exactly what you're asking for; but if you combine this with the interstitial page you are using for the HTML version, it might be an improvement for user experience.
Response.AddHeader "Content-Disposition", "attachment; filename=report.xls"
The user would see the interstitial page with the processing graphic which would then re-post the search form. This would allow the "Processing..." graphic to display until the page popped up with a download prompt for the Excel file.
Update: I tried using an iframe, having the page periodically check the document object and trapping the "interface does not exist" error for when it switches to Excel, but it still locks the browser while the Excel document is downloading in the iframe... I don't think a pure js solution is going to work. After that I think the next best avenue to pursue is (unfortunately) Flash. Good luck.
Related
Is a very simple page, that have some buttons redirecting to external links. That external links have to change arbitrarely when certain people decides it.
I was wondering about making a login screen in other page and depending which user logs in, set the link writting it in a txt file that would be recovered by the main page. Don't need security so i just would make the user go to the other page and login and that would change the link in a txt file hosted in the same directory that the index.html is.
The problem is that i cannot make that idea (writing a .txt in the project folder) with JavaScript (or i think so), and i don't think that using a database worth it (neither want to because i read that would have to use node.js or something like that and i really don't know those tecnologies, only some python and sql server -that is in fact not supported by my hosting service-), cause are just 3 people associated to 1 link each. I can easily make that task with python but don't know how to call it from JS and neither if Ajax request would be useful for this case.
I hope someone can help me!
edit - the changes have to apply for the page itself not in the user session, so everyone who enters see the page with the changes
edit 2 - absolutely all the info (users and links) are always the same, doesnt change so i can put it in variables, are just 4 or 5 so i can easily use an array, the only thing that i would have to register is which one to pick (since it depends on who decides it).
IT seems you want to use some sort of client side storage across different html pages - for that, you can use cookies, localSotrage or sessionStorage.
I have a program where the user does some actions (i.e. clicking on several buttons). I want to record their clicks and the buttons that they click to allow the user to then download a text file with a record of their clicks when they click a separate "download" button. I looked at the File-system APIs for HTML 5, but they seemed to not have cross-browser support. I would ideally like to have this entire file generation and download scheme be entirely client-side, but I am open to server-side ideas as well.
TL;DR: Essentially I'm looking for an equivalent to Java's FileWriter, FileReader, ObjectOutputStream, and ObjectInputStream within Vanilla JS or jQuery (would like to stay away from php, but I'll use it as a last option).
Also, why don't all browsers support the filesystem api? (I'm guessing that it would make MSWord and Pages go out of business with all the open source clientside text editors that could come out.)
Unfortunately the HTML5-File-system is no longer a part of the spec, long story short FF refused to implement because they claimed everything you could do in the File-System API was doable in the HTML5 Indexeddb (which was mostly true). Please see this blog post for more on why FF didn't implement. I do not know IE's story. (I may have exagerated why FireFox didn't implement, I'm still bummed because you cannot actually do everything in indexeddb that you can do in the noew "Chrome File-system API")
Typically if two of those three browsers implement a spec, it stays in the spec. Otherwise that spec gets orphaned. However, I'm fairly certain a large reason the file-system api didn't take off is because of the IndexedDB API (caniuse IndexedDB) really took off when both specs were introduced. If you want cross browser support, check this api out.
That all said if you are still set on the file-system api some developers wrote a nice wrapper around the IndexedDB, the File-system api wouldn't actually supply you with a stream anyway. You would have to keep appending events to a given file given a fileWriter object. you'd then have to read the entire file and send to the server via an ajax request and then downloaded from the server once successfully uploaded.
The better route would be to use the IndexedDB apiwhich as stated on developer.mozilla
Open a database.
Create an object store in upgrading database.
Start a transaction and make a request to do some database operation, like adding or retrieving data.
Wait for the operation to complete by listening to the right kind of DOM event.
Do something
with the results (which can be found on the request object).
Here are a couple tutorials on the IndexedDB.
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB
http://www.html5rocks.com/en/tutorials/indexeddb/todo/
As for giving the user that file, as mentioned briefly before you would have to upload the file to the server and download upon the "download" request. Unfortunately you have to trick the user into giving them the data already on their machine. Anyway, hope this all helps.
I have created a webpage but my friends or collegues always copy the source code and copy all the data easily, so is there any way to hide page source option from browser ?
As a rule, if you are putting information on another user's computer (whether because you made a document or they viewed your webpage), you really can't control what they do with it.
This is an issue that larger companies deal with often. Have you heard of DRM? It's a mechanism that companies like to try to use to control how people can connect to their services, use their content and in general, try to exert control over their data while it's on your system.
Now, a web page is a relatively simple container for holding information. You expressed an urge to prevent your friends from copying the source code. You could try to encrypt it, but if it's using local data to decrypt itself, there still isn't going to be anything that stops them from just copying what's in the View Source window and running it again (even if they can't really read it).
I'd suggest that you don't worry about it. If what you have on your page is so important that others shouldn't be able to see it, don't put it on a webpage.
Finally, Google doesn't much care that you're able to view the source to their home page. Why not? Because the value of the search engine isn't in what the home page looks like, but in the data on the back-end that you don't have direct access to. The value is in the algorithms that execute on the server when you hit that Google Search button that queries that data and returns the information you're looking for. There's very little relative value in the generated HTML that you see in the page. Take a leaf from their book and don't stress that they copy your HTML.
No , there isnt any way to do it, however you can disable right clicking in browser via javascript, but still they can use shortkeys to open developer view (in chrome F12) and see the source. You cannot hide html or javascript from client, but maybe you can make it harder to read.
No. Your HTML output is in the user's realm. Even if there was a way to disable view source in one client, a user could use a different one
Always assume that your site's HTML is fully available to end users.
Yes and no. You can definitely make HTML and JS harder to intrepret by obfuscating your code - that is, taking your code and making it look confusing. Here is a tool that can do that: http://www.colddata.com/developers/online_tools/obfuscator.shtml
However, these things all use code, and code can be decrypted through any number of methods. If you post a song to the internet, even if they cannot find the mp3, they can simply record their speakers. If you upload an image and prevent users from downloading it, they can take a screenshot or use their camera. In order for HTML and Javascript to work, it has to be intrepreted by their computer, and even if you do find a way to disable "View Source" there are others ways, like a DOM inspector (F12 in IE/Chrome, Ctrl+Shift+K in Firefox).
As a workaround, use copyright, warn your users they will be punished if they copy your code, and put watermarks, labels and logos over any mp3s or images you don't want stolen. In the end, disabling right clicking (which is also possible, see How do I disable right click on my web page? ) or disabling selection (also possible) does nothing, because there is more than one way to get your code, like searching through temporary internet files.
However, you ask "what if I want a site where my users can log in and I need security? How can I make it so nobody can see my code then? Doesn't it have to be secure and not out in the open?"
And the answer is, yes, it needs to be secure. That's what server-side languages, like PHP, are for. PHP does all the work on the server itself so the user cannot see it. PHP is like a pre-rendered language - rather than doing it in real-time, PHP does all the work beforehand so the user's computer doesn't have to, making the code safe. The code is never put onto the user's computer, because the user's computer doesn't need it. The work is done by the website itself before the page is sent. SSL is often paired with PHP to make absolutely sure that websites have not been hacked.
But HTML and Javascript have to be done in real time on the user's computer, so you cannot disable View Source because it is useless. There are many, many ways that users could get around it, even if View Source is disabled, and even if right clicking is disabled.
If your code doesn't need to be secure, however, I'd recommend you consider keeping it open source. :)
Some Javascript on a page gets a large wad of data from a server. At some point, I'd like to allow the user to click to download this data in, say, a format digestible to Excel.
My belief is that this will require the data to be on the server and re-fetched by the browser, but I am hoping that there's something I'm missing, and that there's some way for Javascript to get the browser to offer the 'save as' dialog to save away some content generated righ there.
The data URI method is probably the most direct. Although there are alternatives, for example, https://github.com/dcneiner/Downloadify achieves this with flash. pimvdb's comment links to his nice HTML5 implementation.
I have sensitive files to download to users, and each user is permitted to download a given file exactly once. If the download fails, I want to permit the re-download, but not otherwise.
It's not sufficient to rely on logging/processing the file download request at the server - I need to know deterministically when the file is complete and in place at the client, since many of my users work in an environment with frequent connectivity drops.
The most straightforward way for this to work would be if the browser exposed a "file saved" event from the Save As... dialog that could be wired to a JavaScript function on the download page (which could post back to the server). But, intuition suggests there might be security holes if browsers exposed this functionality, as it sneaks somewhat outside the sandbox. I'm not sure this is even possible.
I found several other questions in this area, but nothing about this problem specifically.
Any ideas?
Edit: I should not have used the word "security" in the original question, sorry for triggering the red herrings.
Edit 2: My "security" phrasing misled folks into offtopic technical security issues, but both of you confirmed my suspicion that "no, there's no browser support for that." I'm marking the first commenter with the answer since his first sentence had what I was looking for. Thanks all.
This is a good solution:
http://gruffcode.com/2010/10/28/detecting-the-file-download-dialog-in-the-browser/
It basically works by setting a cookie in the reponse header of the downloaded file, so javascript periodically can check for the existence of this cookie...
There's no such browser event in JavaScript and even if there was you can not trust the user's browser to provide security for you.
You're better off using a GUID to generate a unique URL for each download. You can then for example:
let the URL be valid only for a specific time period
allow transfers only from a specific IP address associated with the unique URL
let your server-side code detect when the content for a unique URL has been fully transferred and then invalidate the URL.
Let me clarify the last bullet. Say you're using Java - you will in.read(buffer) and out.write(buffer) in a loop until EOF. If the client disconnects you will receive an IOException during out.write() and will be able to tell a successful download from an interrupted one. On other platforms, I'm sure there are ways to tell whether the connection was lost or not.
EDIT: You could actually fire a browser event using the trick outlined in the accepted answer of one of the questions you linked to. That would however not be a reliable solution to limit the number of downloads.
Why is it important that the file can be downloaded "exactly once"? Once the file is downloaded it could be copied, so is there really a security issue with letting the same user download the file more than once?
If not, could you do something like this:
Generate a unique URL to download a given file. (Use a GUID to obsfucate if necessary)
Associate that URL with USER INFO (browser type, IP address, etc) AND A TIME WINDOW. Only allow downloads from that user and during the window.
The window should be long enough for the user to notice the transfer failed and to re-try once or twice, but no longer.
The end result is:
You can be reasonably sure the file is only being downloaded by the intended recipient.
You can be sure that recipient can only download the file during a short window.
The same user could download the file more than once, but who cares? It's no different than making a local copy of the first file.
If you're really worried about it, log each download request and run a scheduled report for files that were downloaded more than once. If anything looks fishy you can then examine security logs, talk to the user, etc.