Requirements:
Domain A has page a.html, which contains an iframe containing page b.html of domain B. Now we need to pass the value of a text box on page a.html to b.html through a button on a.html. The text box of the page.
Note: b.html here is an html web page and cannot receive values posted from other websites, so you cannot use the direct post method to pass values. However, if the receiving page is b.aspx or b.asp, you cannot post directly. Already? The answer is yes, it is indeed possible, but b.asp or b.aspx must be refreshed. How can we dynamically change the elements or values of the receiving page without refreshing? (IE's local projects can achieve cross-domain access, but cross-domain access from the external network is denied by default. FireFox local projects and cross-domain access from the external network are denied.)
Principle:
The browser prohibits cross-domain access Data access, but the browser does not prohibit cross-domain and cross-frame post value transfer. We can post in domain A to the frame of a page in domain B, and then use the frame page of domain B to achieve data access in this domain. This is actually a little trick in HTML applications, and it achieves cross-domain data submission without using other advanced knowledge.
Method:
Add two pages in domain B to achieve cross-domain data access, post.aspx and main.aspx.
The page relationship is as follows. a.html in domain A contains a frame. The frame page address is main.aspx in domain B. main.aspx is a frameset containing two frames, (frmMain)b.html and (frmPost)post.aspx. .
a.html of domain A:
<form action=" http://www.b**.com/post.aspx " method="post" target="frmPost">
<input id="cmd" type=" text" size="20">
<input type="submit">
</form>
<iframe src=" http://www.b**.com/main.aspx"></iframe >
Main of domain B .aspx:
<frameset rows="*,0" frameborder="no" border="0" framespacing="0">
<frame src="b.html" name="frmMain">
<frame src="post. aspx" name="frmPost">
</frameset>
We first save the data to be passed to domain B into the form of a.html, and then post to post.aspx in domain B.
At this time, post.aspx receives the value, and then executes the parent frame in this domain to access b.html.
string cmd = Request.Form["cmd"];
if (null != cmd && string.Empty != cmd)
{
Response.Write("<script language="JavaScript" for="window" event= "onload"> if (parent && parent.frames["frmMain"]) {Add the execution code to control b.html here} </script> ");
}
It is not difficult to find that jumping across frames is used here ( That is, a layer of frame is jumped in the middle) to achieve cross-domain data access. That is, post to the subframe of the frame.
Postscript:
This example is just a solution for cross-domain access under some special circumstances, which may be helpful to you. Because the method is simple, its application has many limitations. (However, I think this is very similar to ajax. The page is not refreshed and the server-side data processing is also completed^o^).
Related web-text materials:
Cross-domain access solution for web applications.
Friends who have done Ajax development across multiple websites know that if in website A, we want to use Ajax to obtain specific content in website B, if website A and Website B is not in the same domain, so cross-domain access problems arise. The cross-domain access problem of Ajax is a common problem encountered by existing Ajax developers.
IE handles cross-domain access by popping up a warning box to remind the user. If the user includes the website as a trusted website or lowers the security level, IE will not remind you of this problem.
When FireFox and other non-Microsoft browsers encounter cross-domain access, the solution is to deny access.
Some people say that IE is a mainstream browser, as long as it can be used normally. This is a bad statement. Although IE can handle it, there are prerequisites. Either the user takes the trouble to click Yes after the warning box pops up on the page (clicking No will not execute the Ajax call), or the user includes the website as a trusted site. These two approaches are relatively common in enterprise management system applications, because system administrators can use administrative means to ensure user behavior. But for website or portal development on the Internet, this approach does not work.
I encountered this problem recently. I needed to make some special effects appear on the main window after the cross-domain access. I searched for some information and found several feasible solutions through constant attempts and compatibility testing in different browsers:
1. Web proxy method. That is, the cross-domain access requests to website B generated when the user visits website A are submitted to the designated page of website A, and the page completes the interaction instead of the user page, thereby returning appropriate results. This solution can solve most of the cross-domain access problems that can be thought of at this stage, but it requires website A to provide Web proxy support. Therefore, website A and website B must cooperate closely, and each interaction process, the server of website A The burden increases, and the session state cannot be saved on behalf of the user.
2. On-Demand method. MYMSN's portal uses this method, but MYMSN does not involve cross-domain access issues. Dynamically control the generation of script tags and complete the call to cross-domain pages by modifying the src attribute of the script tag. The flaw in this solution is that the src attribute of the script uses the get method to complete the call. If the string passed during the request is too large, it may not run properly. However, this solution is very suitable for aggregation portals.
3. iframe method. I checked a post about cross-domain access by Waking up on javaeye. He mentioned that he had solved the cross-domain access problem using iframe. It is indeed possible to use iframe for data submission and acquisition, but since the parent window and the child window cannot interact (in the case of cross-domain access, this interaction is rejected), the effect on the parent window cannot be completed.
(I found this article, please add the address: http://www.javaeye.com/topic/15641 )
4. User local dump method: IE itself relies on the characteristics of the windows platform to provide us with an iframe-based, The solution of using memory to "bypass" is that data can be transmitted between two windows through the windows clipboard on the client. You only need to set the Interval on the side receiving the data for polling, and clear the Interval after getting the result. . FF's platform independence determines that it does not support the clipboard method, and the plug-in vulnerability in previous versions of FF has been fixed, so FF cannot complete the secret crossing through memory. Since FF does not provide support for file operations (data transfer across domains cannot be completed through cookies), this technical method can only be used in IE.
5. My own method for solving this type of problem: Combining the previous methods, when visiting website A, first request website B to complete data processing, and then obtain the required results based on the returned identification. The shortcomings of this method are also obvious. The load of website B increases. The advantage is that the session is also maintained, and the interaction ability between the pages of website A and website B is enhanced. Most importantly, this solution meets all my needs.
To sum up, among the above options, I most recommend the on-Demand method. This method can solve most of your problems without submitting a large amount of data.
Cross-domain access solution address for web applications: http://www.newbooks.com.cn/info/37166.html
http://www.cnblogs.com/lgamoy/archive/2006/11/23/569633.html