Web development under AJAX and XmlHttpRequest (1)

I. Introduction

Many people like XMLHttpRequest because it provides functions that programmers really want. Because of this new technology, Web application software has become similar to desktop applications. Nowadays, the problem is always like "if it is ...... "That's simple. This allows naive end users to understand the server, customer, send back, and submit buttons as needed. "Submit? What do I submit? .

Countless terrible cases have exploded on the Web recently. They fully explain why remote scripts (or "AJAX", if you like) it is the greatest thing since the single-pixel gif technology. In fact, The string of cool and useful application software is growing, as posted by sites such as Flickr, Google Maps, and The WebORB Presentation Server.

These sites and many other places publicize AJAX capabilities. To be fair, this technology has considerable potential in improving the quality of online operations. However, despite its many advantages, there is still a strange smell in this holy Web communication cup; like beer and chocolate that swing in front of us, there is still an evil aspect in it-how pure and naive it looks on the surface.

This potential evil exists in the important functional gaps behind the user's familiar operation interface. Many of you may have been using the Internet for nearly 10 years, and you know how it works: You click around, fill the form, modify your input; when you finish all this, you can click Submit. You all know these excellent experiences-they are transferred from the Internet generation to the new generation, for example: "Do not click the submit button twice-otherwise, the form may have to be submitted twice "or" wait a little longer, it is processing "or" after you submit the form, do not click the 'backward' button ", and so on.

However, since AJAX has become an entry, you can throw the basic knowledge out of the window. It's like "everything is okay"-suddenly there is a new type of Tracked data-it can be sent at any time without the user's understanding, even the user does not know that this may happen.

Ii. XMLHttpRequest: Advantages and Disadvantages

Just as many technologies have advantages and disadvantages, the purpose of this technology is to take advantage of its advantages. Until now, XMLHttpRequest has brought so many advantages, such as input verification without rollback, spelling check in the text area, and Gmail. Interfaces created based on AJAX technology are very interesting to use and even more interesting to code. It is hard to believe that such a magical technology can do something wrong.

However, even if no major security vulnerability is found, the XMLHttpRequest may fail due to its external elegance. It is likely to fail in the application of "user profile"-for better description purposes. Currently, the user profile graph helps the Web site master detective trend, tracking Web browsing habits and helping eliminate usage problems. However, until now, developers can only analyze the returned data-the user decides to make the data obtained by the server happy to be processed after submission.

However, through a microsecond method, this kind of energy balance will be transitioned. By using AJAX technology, a user's behavior can be continuously and carefully monitored. Because it can be done, it will be done; this brings people a considerable headache, it is not just a waste of bandwidth, MB of junk information, or a slower number of web page loads.

Imagine that here is only an example to illustrate the problem. You dropped a newly purchased iPod to the ground and it stopped working. With the idea of a free replacement, you sent an email to Apple's after-sales service department, saying, "I just bought a new iPod. I accidentally dropped it to the stairs and it suddenly stopped working. "Then, you decided to delete the second sentence to support your reasons. It's too late! If the website uses AJAX technology, your reflection may have been killed at your Complaint Desk!

Or-a more malicious and destructive example-consider this situation: Most people have one or two usernames/passwords used for their "unimportant" sites, such as news sites, blogs, and forums. They may also have several reserved combinations for more sensitive websites-banking, Web emails, and work accounts. Inputting incorrect logon details on a given page is a common and easy mistake. Although the effects of their previous habits are primarily responsible for this, people often realize what they are doing before clicking the submit button.

Unfortunately, it is quite troublesome to implement an AJAX key logging program. Using such a key logging program, you can use code to collect incorrect logon attempts, and then experiment with a series of "important" sites-of course, you can also use the XMLHttpRequest object.

Iii. Malicious suggestion

To be fair, most of the "malicious" applications referenced above can be reasonably handled, even before the emergence of XMLHttpRequest technology. Indeed, the request object is a more elegant method for successfully submitting form data than the previous IFrame technology. However, XMLHttpRequest works in a more natural way, which can make the interaction between the client and the server disappear.

It is ironic that, with the popularity of Firefox Web browsers, many users have learned the depth and breadth of information that can be stored and controlled by Web clients. With the widespread adoption of tools such as Greasemonkey, Web Developer extensions, and cookie editors, people are more confident than ever that if the problem occurs on the client, the responsibility is generally attributed to the user.

But now, even arrogant people like us are no longer simply right-clicking the mouse and looking at the source code to be sure what is happening. Consider the following OnReadyStateChange JavaScript statement to respond to an XMLHttpRequest:

xmlReq.onreadystatechange ={if( xmlReq.readyState == 4 ){eval( xmlReq.responseText );}}

The above code is executed in the JavaScript code contained in the response from XMLHttpRequest. In other words, this may happen: even if a page is loaded, it is possible to add or modify JavaScript Functions and code in the background! Therefore, even if you observe the source code of the page code-it may have sent a key-click or mouse-move event to the Web server, you cannot be sure that the code you see is the only code currently executed. By combining these features with some daunting confusions, you can see that the combination of malicious purposes and XMLHttpRequest objects cannot steal information from Web customers!