The Twitter input box is much more than your average INPUT or textarea. First off, it isn't an input or textarea at all. They are instead using a well crafted DIV with a "role" attribute. for the entire text; likely capturing keystokes as they occur.
If a user is logged in, they can compose a tweet. If during that very cautious 140 character sprint, they accidentally click somewhere on the page, the browser GETs another page.
But when the user hits "back", the DIV then repopulates (after a second), with the users partially drafted tweet.
In terms of browser capability, how is this "saved form field" being accomplished?
I'm guessing to achieve this, one could implement either:
local-storage
This would just involve writing to the local storage upon each keystroke. Upon loading the page, the JS populates the tweet composer with the session local storage. See a live example of utilizing local storage. This would be nice and slick, but a major limitation is that this is limited to HTML5 browsers.
AJAX callback
Similar to the first method, but instead of writing to local-storage, the draft tweet is written to a web service. Upon loading the page, a callback is made to retrieve the content; populating the tweet composer.
Cookie approach.
Similar to the local-storage, but would write to cookie cache. The benefit with this method might be more ubiquitous browser support.
I'd love for someone to explain the pro's/con's of each method along with some sample code. Bonus if it's under 140 characters for each code sample :) (j/k).
Related
I am creating a website using HTML (no visual editors at all - please do not suggest me one), and I want to add an accounts system. I have already made an example database, a signup/login form but I wonder about something. Is there a stable address that can be received and processed, and every device has one? I am asking this because I also want to make a connections table where all the devices' addresses will be located, along with the account they are linked to.
Is there a way to receive this address, and keep it even after the browser, device, and everything is closed?
If it is, please tell me. I prefer pure JavaScript, but, if there is only a way to do it in jQuery, then, I'll have to learn jQuery :(.
There is no unique stable identifier for each device or user (unless you generate one, and store it in e.g. local storage/cookies, and even then it could always be removed by the user and you'd regenerate one).
You seem to be looking for cookies, though, if you want to keep an user logged in on their device after having created an account.
I have a web application used internally by users to enter data. The product owners decided they want to remove the users ability to paste data into a prompt that is used to make them dual key the data entered. I know of no way (and found nothing through my searching) to implement this behavior in a prompt. The application does not use jQuery, just straight JS.
I recommended just disabling copy functionality for the entire page, but they specifically want to disable pasting into the prompt. Is this feasible? If so, how can I go about implementing it?
Not possible I'm afraid. prompt() is an API built by the browser, and much like alert(), once the popup window is opened it blocks processing on the page itself, so you have no way of knowing what keys/clicks the user has carried out on the popup, other than the text they enter into it which you receive in the response.
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. :)
I have a requirement to paste text from a textarea into the DOM as a preview area, much like the one you get on Stackoverflow when you make a comment etc.
I allow users to insert any and all html tags, including javascript tags. I know this will allow embedded javascript and flash content etc, but I then remove all of this server side so no other user will see, they just see plain text.
However are there any security issues in letting the user insert these things in there own page?
My guess is there isn't otherwise tools like firebug would be a security risk, but I'm not sure.
However are there any security issues in letting the user insert these things in there own page?
I can't see any - the DOM is freely manipulable in the client's browser, anyway. Whether they do it using a tool like Firebug or your JavaScript function, doesn't matter.
As long as the data isn't shown unfiltered in other users' browsers, I think you're safe doing this.
Actually in rare set of circumstance, it might be an issue. It highly depends on how this particular feature works, but I can imagine making first use of CSRF to 'post' in the preview area some malicious javascript/ajax, and use that to steal cookies, change account password or whatever tickles your fancy.
So the attack would go something like this; I send a user a link to a 'legitimate' website. On that website there is a hidden payload (eg via img tag in case of GET, or hidden iframe with auto-submitting form for POST) which silently redirects the user to your website with the XSS payload, which then will be executed by the user through the injection in the preview area, for instance logging user's cookies, without him ever knowing.
Again it all depends how your preview feature works, and if you for instance use form tokens etc., but the point is that it in fact could be an issue.
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.