Implement data exchange between different domains)

Document directory

• File Uploaded successfully!
• Solution 2
• Solution 3

Introduction

I encountered a problem when I revised the company's original web applications a few days ago. At that time, I needed to extract some of the original applications and replace them with a more general one, the original application interfaces are retained. The original application belongs to the news.mycompany.com domain, and the new application will be deployed to upload.mycopany.com. When I tried to transfer data from a new domain to news.mycompany.com, I encountered an "Access Denied" error message returned by the browser at the front end, find the problem by referring to a large number of English documents found in Google, and specify docment for pages in two domains. the domain attribute partially solves the problem. Later, Google was launched to search for and document. domain-related Chinese documents, but most of the obtained articles are about network security. Few articles mention the document on the specified page. the domain attribute can realize data exchange between two domains, so I decided to write this article, hoping to implement it.

Keywords: JavaScript, domain, Access Denied
Date: 2003-07-06

Question proposal

When developing a web application, you often encounter the need to transmit data between two frames. The frame here can be a frame in the frameset or an independent window. A common case is that one frame is the subject of the application, and the other frame provides some options for the user to choose. After the user selects the frame, this frame sends the user's choice to the server and transmits some information to the main frame. The information here may be the user's choice or the data returned by the server. It is easy to implement when the content in two frames belong to the same domain, but the problem becomes complicated and tricky when they belong to different domains, this involves the security of data access. If the problem is not solved, an error message "Access Denied" is returned by the browser.

Possible solutions

The following describes how to transmit data between frames in different domains through several experiments.

• Transmit data between two frames using client scripts (such as JavaScript) and window handles
• Transmit data between two frames using the dialog box provided by MSIE
• Transmit data through session using server applications

Solution 1

Using client scripts to implement data exchange between two frames should be one of the most lightweight methods. This will not increase server load or occupy network bandwidth, and data exchange will be completed on the client. Next let's take a look at how client scripts (taking JavaScript as an example) and window handles implement data exchange in a domain.

We use an example to describe the following: If you need to provide a news input interface, you can use it to enter the original news content and embed an image in it. To implement this functional interface, we have designed two frames, or two windows:

• Main Window: The main editing interface of news content. You can enter the news title, author, news subject, and other content in it. You can also preview the uploaded picture in an image box.
• Pop-up window: processing image upload interface. You can select a local image for upload. After the upload is successful, it returns the URL of the file on the server to the main window for preview.

For the sake of simplicity, we assume that the content in both windows is static and the file corresponding to the main window is newsedit.html, the file corresponding to the pop-up window is imgupload.html (in most cases, the content of both windows should be dynamically generated ).

Newsedit.html is located in the home directory of news.mycompany.com, and its source code is as follows:

Edit your content here

Imgupload.html is located in the upload subdirectory of news.mycompany.com. Its source code is as follows:

Image Upload

Here are two background applications:

• Newsedit: In the home directory of news.mycompany.com, receives POST requests and stores the news elements on the editing interface to the background database.
• Imgupload: Located in the upload sub-directory of news.mycompany.com, receives the user's POST request, uploads the local image file to the server, and returns the complete URL of the image file.

The following is the page content returned by imgupload after processing the POST request. The content is displayed in the pop-up window occupied by imgupload.html:

File Uploaded successfully!

In addition to the success information, the returned page also uses scripts to pass the URL of the uploaded file to the main window. The specific process is as follows:
First, use "self. opener "obtains the handle of the main window (that is, the window where newsedit.html is located), and then assigns a value to the src attribute of the userimg element in the Main Window using the URL of the uploaded file, in this way, you can see the uploaded image in the main window.

Now, our first experiment has been successful. The experiment results show that when the content in the two frames belongs to the same domain, there is no problem in using client scripts and window handles to transmit data. Next we extract imgupload.html and imgupload from news.mycompany.com, deploy them to the corresponding directory of img.mycompany.com, and modify the URL when imgupload.html is referenced in newsedit.html. In this way, when we try to use JavaScript to transmit data from img.yourcompanu.com to bbs.yourcompany.com, the "Access Denied" error box will pop up in the browser, indicating that we have violated his security policy, and the data cannot be transmitted normally.

In fact, you can directly Save the content returned by imgupload in the experiment as a file and deploy it to img.mycompany.com. In newsedit.html, you can call the window. open () method to directly reference this file for testing.

The error message "Access Denied" is displayed because:

Initially, for security reasons, browser developers and development groups are not allowed to exchange data and call methods between pages in different domains by default, in this case, the browser returns the "Access Denied" error.

"Why do I still encounter the" Access Denied "error even if my two pages belong to the same domain ?"
If this is the case, check whether the content in the pop-up window always belongs to the same domain. Check whether your imgupload.html calls applications in other domains, and the application re-writes the content in the window. If so, your pop-up window will deteriorate and it will last belong to another domain, of course, you will encounter an "Access Denied" error.

"In this case, if two pages belong to different domains, we cannot transmit data between the two windows ?"
This is basically the case-a frustrating message.
But the answer is not an absolute one-as if there is still hope.

Yes, some browser developers and development groups have made some adjustments to the original policy when developing high-version browsers. These adjustments have brought us a glimmer of vitality:
When two pages exchange data, the browser first compares the domain attributes of the two pages. If the domain attributes are the same, the Browser allows data exchange between them, otherwise, the error "Access Denied" is returned.

"How can we blind the browser and make it think that the domain attributes of the two pages are the same ?"
This depends on the script. In JavaScript, we can force the specified domain of the page by adding the following declaration to the page.

By adding the above statement, you can blind the browser and exchange data between pages in two different domains. However, it should be noted that the preceding statement is valid only when it is added to all files for data exchange. It does not work if it is added only to files in a domain. In addition, it is recommended that the declaration part be inserted into the mark of the page, which is also promoted during development using scripts. For information about document and domain in Javascript, see http://www.werelight.com/docs/JavaScript_Quick_Reference.htm

"What is the limit code for using this method ?"
There are still many restrictions on using this method to transfer data between different domains, mainly as follows:

• The document. Domain attribute cannot be set at will. It can only be set as the upper-level domain of the file's domain. For example, if imgupload.html belongs to img.mycompany.com, its document. Domain attribute can be set to "mycompany.com", but not "IMG. mycompany" or others, such as "foo.com ".
• Only when the two domains have the same upper-level domain can the data exchange between them be realized by specifying document. domain, and the document. Domain attribute must be set as the public domain of the two. For example, if newsedit.html belongs to news.mycompany.com and imgupload.html belongs to img.yourcompany.com, no matter how you set document. domain cannot exchange data between them. For example, if imgupload.html belongs to img.mycompany.com, we can set the document of the two pages. the domain attribute is set to "mycompany.com", but cannot be set to "IMG. "mycompany" or other domains, such as "foo.com ".
• Not all browsers support setting the document. Domain attribute. For example, MSIE and Netscape versions earlier than 4.0 do not support setting this attribute. It is also interesting that although Netscape began to support setting domain after 4.0, however, in versions 4.03 and 4.04, netscapre canceled the above functions.

Using other scripts, such as VBScript or JScript, to implement cross-domain data exchange is the same as using JavaScript. You can refer to relevant materials for implementation.

Solution 2

Next, let's take a look at whether the dialog box provided by MSIE can solve the problem of data exchange between two domains.
First, let me briefly introduce the MSIE dialog box: the showmodaldialog and showmodelessdialog methods provided by MSIE can be used to display a modal or non-modal dialog box in a single frame, both methods use a URI parameter to specify the content in the dialog box frame. The optional parameter varguments is used to pass Parameters of any type (including array type) to the dialog box frame; in addition, an optional parameter sfeatures is used to define the Display Effect of the dialog box frame, such as the position and font;

Note that the Netscape Navigator, Mozilla, and opera Browsers Do not have corresponding methods. That is to say, the showmodaldialog or showmodelessdialog display dialog boxes are not supported in other browsers except MSIE, if you are interested, here is an article to teach you how to simulate a modal dialog box in other ways. For details, see Simulating Modal Dialog windows.

"Because a modal dialog box can include a URL to a resource in a different domain, do not pass information throughVargumentsParameter that the user might consider private.VargumentsParameter can be referenced within the modal dialog box usingDialogargumentsProperty ofWindowObject. "-- reference from msdn showmodaldialog
The above section describes how to use the Surl parameter to use the resources of another domain as the content of the dialog box. However, in this case, we can no longer pass any parameters to the dialog box, window can be used only when the referenced resource belongs to the same domain as the page that references it. dialogarguments obtains the parameters passed from the reference page.

"So I can not blind the browser by forcibly specifying the document. Domain attribute of two pages as in solution 1, so that the two pages belong to the same domain ?"
Some people have put forward this idea, and I have tried to do so, but it still ends in failure: forcibly specify document on two pages. after the domain attribute is configured, the dialog box does not recognize the parameters passed from the home page, no matter whether the two pages belong to the same domain or not.

In this experiment, I used three files

• Main.html: deployed in a.mycompany.com. Two other files are referenced by calling showmodaldialog.
• Localdialog.html: deploy it with main.html at a.mycompany.com
• Remotedialog.html: deployed on B .mycompany.com. Its content is exactly the same as that of localdialog.html.

When main.html calls the showmodaldialog method, varguments passes the parameter "Can you hear me? ", You want the dialog box to receive this parameter. If the dialog box receives this parameter, it calls window. the Alert () method prints the message and returns a result to main.html: "Yes I do, I hear you from" + document. domain; If main.html receives the result returned by the dialog box, it also calls window. alert () prints the result.

The source code of main.html is as follows:

I will open a remote dialog from news.soufun.com I will open a local Dialog

The source code of localdialog.html(remotedialog.html) is as follows:

Im here, Im a dialog I will return something to the Main Window

Experiments show that:

1. Main.html can normally receive the results returned from the dialog box. Whether the dialog box is a.mycompany.com or B .mycompany.com, or whether the document. Domain attribute is set or not;
2. When document. domain parameters are not set, localdialog.html can normally receive parameters passed from main.html. However, if the document. Domain attribute is set, the parameters read by localdialog.html become null.
3. Regardless of whether the document. Domain attribute is set or not, the parameters passed from main.html in remotedialog.html are always null.

Unfortunately, the results of the experiment tell us that this cross-domain data exchange cannot be achieved through the dialog box.

If some vulnerabilities exist in my experiment or the parameters passed from main.html are read in the dialog box of your experiment, please email me. Thank you!

Solution 3

It should be said that using server-side applications to implement cross-Origin data exchange is the most reliable method, because it is almost not restricted by the client, unlike the previous two methods: Some clients do not support document. domain attribute, some do not support the dialog box, and so on. So is it the best solution to solve data exchanges between different domains using server applications? The answer is no, because the server-side application also has its fatal impact: that is, the party receiving data cannot display the data transmitted from the other party in real time, it can display data only after the get or POST request is processed. If no special processing is performed in this process, the content edited by the user in this frame will be cleared, this is often what we don't want to see. We will not give an example about cross-domain data exchange using server applications. If you are interested, you can check related information on Google.

Summary

Among the three solutions described above, except solution 2 cannot implement data exchange between frames in different domains, it has been proved that solution 1 and solution 3 are feasible, however, the two solutions have their own advantages and disadvantages:

• Solution 1 has the following advantages: client scripts and window handles do not occupy server resources and network bandwidth, so data can be displayed in real time without affecting the existing content in the other frame, the disadvantage is that the application scope is small and it is limited by the browser of the client;
• Solution 3: because it is a server-side application, it is almost unaffected by the client. Its disadvantage is that it cannot display data in real time, sometimes you need to take some measures to maintain the existing content in the target frame.

For these two feasible solutions, you should choose flexibly when using the application. If you pay more attention to real-time data presentation, you can consider using the former; if the platform independence of the application is your measure of the application, you should consider using the latter.
From: http://blog.csdn.net/lhelper/archive/2003/08/11/18720.aspx