How to solve Javascript cross-origin access in Controllable cases on the server side _ Javascript tutorial

Javascript: Javascript cross-origin access solution under Controllable conditions on the server side, Javascript tutorial

In a recent web project, I encountered a javascript cross-origin access problem to implement the bookmark function. At first, many solutions searched on Google were not suitable for me. I only saw the hope of solving the remote loading javascript method mentioned in an article. However, it is a pity that the author did not use examples to describe it in detail, so I had to explore for a while to solve this problem. In this article, we hope to provide a solution for friends who are also troubled by this problem as a reference. If any error occurs, please correct it!

Bookmark is a popular feature provided by many Web websites (such as http://del.icio.us/, www.diigo.com. It can add favorite web pages on the Internet to the Bookmark server. The problem solved in this article occurs when the user submits a webpage URL (including Tag and Notes) to the Bookmark server.

There are at least three methods for URL submission:

1. log on to the submit page of the Bookmark server and submit the favorite URL to the server through this page.

2. Install the browser plug-in and submit the URL to the server through the plug-in.

3. dynamically load the javascript tool from the Bookmark server to the current page and use it to complete the submission. (Refer to the diigo example to add a webpage to the favorites folder of the browser. The URL of the link is a piece of javascript code, which loads a section of javascript from the server and injects it into the current webpage)

The first method is the easiest to develop, but it is troublesome for users. You need to log on to the Bookmark server each time before submission. The second method is not familiar with plug-in development, in addition, users do not like too many plug-ins to fill their browsers. The third method is difficult to develop and avoids the trouble of logging on to the server every time, so I finally adopted it.

In the third method described above, the javascript gadgets dynamically load not only need to generate the UI for users to fill in information (URL, tag, notes, etc.), when users click to submit, it also needs to complete the function of communicating with the server. Without cross-origin access experience, ajax is the first thing that comes to mind! But soon we will find that it does not work.

Cross-origin access is simply the javascript code of website A tries to access website B, including submitting content and obtaining content. For security reasons, cross-origin access is disabled by various browsers by default. I believe all my friends who have written cross-origin access to ajax have been notified of "no permission. An error occurred while sending data to the Bookmark server through XMLHttp. As a result, I started to use javascript gadgets to dynamically create a hidden iframe on the user's webpage. The src of iframe points to a servlet on the server, it tries to call the javascript provided in iframe to communicate with the server. However, unfortunately, the javascript code in the user's webpage accesses iframe, which is also classified as cross-origin access by the browser (especially when the src of iframe points to another website), and the attempt fails again.

In the end, we can see in an article that, unlike iframe, if website A loads javascript from website B, website A can freely access the javascript content, it is not considered by the browser as cross-origin access. Following the iframe idea, when you click Submit, You can dynamically create a javascript Object whose src points to a servlet on the Bookmark server. Note: URL, Tag, Notes, User, Password, and other information are transmitted to the server as the src URL parameter. See the following code:

The following is a reference clip: Var url = "http: // localhost: 8080/Deeryard/BookmarkServlet? "+ "Url =" + url_source + "&" + "title =" + title + "&" + "Tag =" + tag + "&" + "notes =" + notes + "&" + "user =" + user + "&" + "password =" + password; Url = encodeURI (url ); // Submit to server with a trick Var js_obj = document. createElement ("script "); Js_obj.type = "text/javascript "; Js_obj.setAttribute ("src", url ); // Get response from server by appending it to document Document. body. appendChild (js_obj );

In the preceding example, js_obj.setArrribute () submits the information to the Bookmark servlet as the src URL parameter. How can users obtain the server response information? The answer is the last line of code. The servlet output must be javascript code. It can call other javascript Functions on the user's webpage and operate on dom objects. The following servlet code generates a javascript function call:

Out. write ("onServerResponse (INADEQUATE_INFORMATION );");

After document. body. appendChild (js_obj) is executed, onServerResponse (INADEQUATE_INFORMATION) will be executed to make the client webpage respond to the server results. This complete communication process is complete.

To sum up this case, first of all, it is different from many cross-origin access situations. The cross-origin access mentioned in this article requires control over the server side, that is, to allow the server-side Servlet to adapt to the javascript requirements of the client webpage; some other common examples do not have control over the server, for example, the hacker program that captures content from other websites. In addition, you must note that the get method is actually used in this method to submit information. From some information, we can see that the information submitted by the get method each time cannot exceed.