The so-called js cross-origin issue refers to the Access to Data Objects in another different domain through js on a page in one domain. For security reasons, almost all browsers do not allow this cross-origin access, this causes cross-origin webservice to become a problem in some ajax applications. To solve the cross-origin problem, we need to discuss what is cross-origin?
Concept: as long as the Protocol, domain name, and port are different, they are regarded as different domains.
The Code is as follows:
URL indicates whether communication is allowed
Http://www.a.com/a.js
Http://www.a.com/ B .js allowed under the same domain name
Http://www.a.com/lab/a.js
Different folders under the same domain name allow http://www.a.com/script/ B .js
Http://www.a.com: 8000/a. js
Http://www.a.com/ B .js with the same domain name, different ports not allowed
Http://www.a.com/a.js
Https://www.a.com/ B .js for the same domain name, different protocols are not allowed
Http://www.a.com/a.js
Http: // 70.32.92.74/B. js domain name and the corresponding ip address of the domain name are not allowed
Http://www.a.com/a.js
The primary domain of the http://script.a.com/ B .js is the same and different subdomains are not allowed
Http://www.a.com/a.js
The same domain name of the http://a.com/ B .js, different second-level domain names (same as above) are not allowed (cookie in this case is not allowed to access)
Http://www.cnblogs.com/a.js
Different http://www.a.com/ B .js domain names are not allowed
Different ports and protocols can only be solved through the background.
Cross-origin Resource Sharing (CORS)
CROS (Cross-Origin Resource Sharing) Cross-Origin Resource Sharing defines how the browser communicates with the server when accessing Cross-Origin resources. The basic idea behind CROS is to use a custom HTTP header to allow the browser to communicate with the server and decide whether the request or response should succeed or fail.
The Code is as follows: