This is the 7th day of my participation in Gwen Challenge

  • Document.domain is set as the master domain to achieve cross-domain operation of the same subdomain. At this time, cookies under the master domain can be accessed by the quilt domain name. If the document contains an iframe with the same primary domain name and different subdomains, we can also operate on this iframe. If you want to solve the problem of communication between different cross-domain Windows, such as a page that wants to communicate with iframes from different sources within the page, you can use location.hash or window.name or postMessage to solve the problem
  • Using the location.hash method, we can dynamically change the hash value of the iframe window on the home page, and then implement a listener function in the iframe window to achieve such a one-way communication. Since there is no way to access the parent Windows of different sources in iframe, we cannot directly modify the hash value of the parent window to achieve communication. We can add another IFrame to the iframe, and the content of this iframe is the same as that of the parent page. So window.parent. Parent can change the SRC of the top-level page to achieve two-way communication.
  • The method of using WindowName is mainly based on the same window set window.name page of different sources can also access, so the child pages of different sources can first write data in window.name, and then jump to a page of the same origin as the parent. At this point, the level page can access the data in the window.name of the same child page. The advantage of this method is that it can transfer a large amount of data.
  • The solution is to use postMessage, an API new to H5. Through it, we can realize the information transfer between multiple Windows, by obtaining the reference of the specified window, and then call osMessage to send information, in the window, we receive information by listening to the message information, so as to realize the information exchange between different sources. If it is a problem like ajax not being able to submit cross-domain requests, we can use JSONP, CORS, WebSocket protocol, server proxy to solve the problem.
  • Jsonp is used to implement cross-domain requests. Its main principle is to implement cross-domain requests by dynamically building Script tags, because there are no cross-domain access restrictions on the introduction of script tags by browsers. Through the request after u specify a callback function, then the server at the time of return data, build a json data packaging, the packaging is a callback function, and then returned to the front, front end receives the data, because the request is a script file, so will be executed directly, so that we previously defined callback function can be invoked, Thus, cross-domain request processing is realized. This can only be used for GET requests. Using CORS, a W3C standard that stands for “Cross-domain Resource Sharing.” CORS requires both browser and server support. Currently, all browsers support this feature, so we only need to configure it on the server side. Browsers classify CORS requests into two categories: simple and non-simple. For simple requests, the browser issues CORS requests directly. In particular, an Origin field will be added to the header information. The Origin field indicates the source from which the request came. Based on this value, the server decides whether to approve the request or not. The server returns a normal HTTP response if Origin specifies a source that is not within the license scope. When the browser sees that the response header does not contain the Access-Control-Allow-Origin field, it knows something has gone wrong, throws an error, and Ajax does not receive the response. If successful, it will contain fields starting with access-Control -. For non-simple requests, the browser sends a pre-check request to check whether the domain name is in the whitelist of the server. The browser sends a pre-check request only after receiving a positive reply.
  • Use the WebSocket protocol, which has no origin restriction.
  • Using a server to proxy cross-domain access requests, that is, when there is a cross-domain request operation to send the request to the back end, let the back end for the request, and then finally get the result back.