Summary of cross-origin POST request implementation solution -- Transfer

[Terminology] Cross-Domain: Attention (pay attention to network access this section): http://www.w3.org/Security/wiki/Same_Origin_Policy [Problem description] browser for security considerations (to avoid malicious websites easily read the content of other sites, because the content may contain sensitive information, imagine IFRAME nesting a bank webpage) In principle, cross-origin write is allowed and cross-origin read is restricted.. Write is the sending request of the index data, and read is the downlink/receipt of the index data ). (However, cross-origin write is also insecure, which can easily lead to csrf/clickjacking attacks. If the browser limits cross-origin reading and cross-origin writing, every page on the Internet becomes an isolated island. Token is required to avoid illegal cross-origin write, which is not discussed in this article .) Consider the following situations:

1. The link pointing to the external domain name is the same as the GET request sent to the external domain through the form. From the moment you click it, the current domain name of the browser is directed to the target website, it is completely intra-domain write and read.
2. A form can also be used to initiate a POST request to an external domain for the same reason. The source Website Cannot read any content of the target website.
3. Ajax (with XMLHTTPRequest object) Cross-origin get/post is forbidden, because Ajax is used to read the response content, which touches the cross-origin read restrictions.
4. Jsonp is a cross-origin read, and its form is limited to get requests because it utilizes the features of the script tag (the browser considers cross-origin read scripts as exceptions, such as IMG and IFRAME, note the common SRC attributes ).

  Therefore, for browsers: 1 and 2 do not have cross-origin; 3 follow the principle of limiting cross-origin read; 4 is an exception allowed.
Although jsonp is easy to use, it is destined to be a GET request. GET requests have semantic requirements (idempotence), length restrictions (255 bytes for compatibility), and security risks (vulnerable to csrf attacks, the csrf must be used by the POST request with the token ). So, how to implement cross-origin POST requests?[Solution] 1. CORS Overview: Cross-origin resource sharing, a cross-site resource sharing standard developed by W3C. Before post, an options sniffing (preflight, but simple requests do not appear) will be generated to check whether there are any cross-origin request permissions. The origin header will be included in the post client to indicate the source website, when the server responds, the value of the access-control-allow-origin header must match with that of the origin header. IE8 provides encapsulated xdomainrequest objects, partially implementing this standard, while other browsers provide XMLHttpRequest (level 2) objects. 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: http://www.zfkun.com/394.html (definition of simple reuest is incomplete) Advantage: W3C standard solution disadvantage: not compatible with old browsers, Mobile browsers are not yet supported.Desktop and mobile browser compatibility Note: If cross-origin communication is performed between multiple IFRAME, window is preferred. postmessage 2 and invisible IFRAME Overview: the invisible form and IFRAME are dynamically generated through JS, and the target of the form is set to the name of IFRAME, so as to submit the post through IFRAME. After submission, the response content cannot be directly read due to cross-origin. Generally, IFRAME changes the fragment of its own location through JS, while the external server listens to the onload event of IFRAME and reads the fragment content. There are ready-made cross-domain IFRAME communication class libraries, such as jquery postmessage plugin. Requirements: IE6, Safari, GC, and ff4. 3. Server proxy Overview: the current domain implements a proxy. All requests sent to the external domain name are forwarded by this proxy. Disadvantage: each user needs to deploy a proxy, Which is inefficient in data transfer and can intrude JavaScript. 4. Flash proxy Overview: to submit data using an invisible SWF cross-origin post, you need to deploy crossdomain. xml. For example, alirte performs automatic detection. If Flash is installed, cross-origin communication is implemented. Requirements: For details about Flash 9, refer to http://flxhr.flensed.com/ :adobestandard solution. This solution is more compatible with corsand has obvious advantages over the large amount of invisible IFRAME response data. Disadvantage: It depends on flash. Original article: http://blog.csdn.net/doraeimo/article/details/7329779

Summary of cross-origin POST request implementation solution -- Transfer