"Noun interpretation" cross-domain: Https://developer.mozilla.org/en-US/docs/JavaScript/Same_origin_policy_for_JavaScript homology strategy (note network Access section): Http://www.w3.org/Security/wiki/Same_Origin_Policy "problem description" Browser for security reasons (avoid malicious websites to easily read the content displayed by other sites, Because the content may contain sensitive information, imagine the IFRAME nesting bank pages)
in principle allows cross-domain writes to restrict cross-domain reads。 Write refers to the data uplink/sending (sending request), read refers to the data downlink/receive (receiving response). (However, cross-domain writes are also very insecure and prone to csrf/clickjacking attacks.) The browser has limited the cross-domain read, and then limit the cross-domain write, every page of the Internet becomes an island. To avoid illegal cross-domain write requires token, this article does not discuss. ) Consider the following situation:
- Link to the external domain name and to the external domain through the form of a GET request is the same, is also allowed, click that moment, the browser's current domain name to the target site, is completely in the domain write, read.
- It is also permissible to initiate a POST request through a form-one-way external domain, with the same reason that the source Web site could not read any content from the target site.
- The cross-domain Get/post of Ajax (with the help of XMLHttpRequest objects) is forbidden because Ajax is used to read the contents of the response, which touches the restriction of cross-domain reading.
- Jsonp is a cross-domain read and is limited to a GET request because it takes advantage of the features of the script tag (the browser considers the cross-domain read scripts to be an exception, similar to IMG, IFRAME, and so on, noting their common SRC attributes).
So for browsers: 1 and 2 have no cross-domain, 3 follow the principle of restricting cross-domain reads, and 4 are allowed exceptions.
Although the JSONP is very useful, it is destined to be a GET request, a GET request has a semantic requirement (idempotent), a length limit (for compatibility limit of 255 bytes), a security risk (vulnerable to CSRF attacks, CSRF resolution must be a POST request with token use).
So, how do you implement cross-domain post requests? "Solution" 1, cors Overview: Cross-origin Resource sharing,w3c established cross-site resource sharing standards. An options sniff (called a preflight, but not a simple request) is generated before the post to confirm that there are no cross-domain requests, and the client post takes the origin header to indicate the source site, The service-side response is required to match the value of the origin header with the Access-control-allow-origin header to signify the license. IE8 provides a packaged Xdomainrequest object that partially implements the standard, while other browsers provide a XMLHttpRequest (level 2) object. Requirements: IE8 (xdomainrequest)/ie10/safari4/gc/ff3.5 reference: Cross-site XMLHttpRequest with CORS
Reference: Https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS Reference (Chinese): http://www.zfkun.com/394.html (Simple reuest definition description is not complete) Advantages: Standard solution disadvantage: incompatible with the old browser,The Mobile browser is not yet supported. Desktop and mobile browser compatibility NOTE: If you cross-domain communication across multiple iframe, prioritize window.postmessage 2, invisible IFRAME Overview: Dynamically generate non-visible forms and iframe via JS, set the target of the form as the name of the IFRAME to do post submission via the IFRAME. The response content cannot be read directly after submission because of cross-domain. The general practice is that the IFRAME through the JS to change the location of the fragment, the external monitoring iframe onload event, read the contents of fragment. There are ready-made cross-domain IFrame communication class libraries, such as jquery PostMessage Plugin. Requirements: IE6/SAFARI/GC/FF4 Reference: http://stackoverflow.com/questions/298745/ how-do-i-send-a-cross-domain-post-request-via-javascript#answer-6169703 Reference: http://softwareas.com/ Cross-domain-communication-with-iframes Reference: http://thomas.bindzus.me/2007/12/24/ adding-dynamic-contents-to-iframes/Advantages: Good compatibility, Facebook,google, Sina has/has adopted the disadvantage: rely on hack implementation, the response data is large, you need to slice, set up the fragment and polling multiple times, May fail when the response is frequent.  3, Server proxy Overview: The current domain implements a proxy, and all requests to the external domain name are routed by the agent. Disadvantage: Each user needs to deploy agents, data transfer inefficient, JS intrusion.  4, Flash Proxy Overview: Using an invisible SWF to submit data across a domain post, you need to deploy crossdomain.xml. For example, Alirte automatically detects if a user installs Flash, which enables cross-domain communication. Requirements: FLASH9 reference: http://flxhr.flensed.com/advantages: Adobe standard scheme, relative cors compatibility is good, relative invisible iframe response data is large when the advantage is obvious. Cons: Rely on flash. http://www.asp.net/web-api/overview/seCurity/enabling-cross-origin-requests-in-web-apihttps://developer.mozilla.org/en-us/docs/web/http/access_ control_cors#preflighted_requests
Post cross-domain request