How to solve js cross-origin problems

Javascript cross-origin is one of the most common problems for web developers. 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 leads to some ajax applications... syntaxHighlighter. all ();

Javascript cross-origin is one of the most common problems for web developers. The so-called js cross-origin problem refers to the Access to Data Objects in another different domain through js on a page in one domain. For security consideration, almost all browsers do not allow this cross-origin access, this causes cross-origin web services to become a problem in some ajax applications. Currently, there are some ready-made solutions on the client and server to solve js cross-origin problems, but these solutions cannot solve all problems. Next, let's take a look at some common solutions and provide a space solution based on the Cross-Domain problem requirements of space products. We hope it can be used for reference by other product groups.
Client Solution
Almost all web developers will first consider how to solve js cross-domain issues on the client. Currently, there are two most common methods: setting document. domain and loading through script labels.
Set document. domain
The premise of using this method is that the two pages involved in the cross-origin request must belong to a basic domain (for example, both xxx.com and xxx.com.cn) and use the same protocol (for example, all pages are http) and the same port (for example, both 80 ). For example, if a page in aaa.xxx.com needs to call an object in bbb.xxx.com, set the document. domain of both pages to xxx.com to implement cross-origin calls. In addition, you must note that this method can only be used in parent and child pages, that is, it is only useful when using iframe for data access.
Load with script labels
For the browser, the src attribute of the script tag points to the resource, just like the src attribute of the img Tag points to the resource, it is a static resource, the browser automatically loads these resources when appropriate, without the so-called cross-origin issue. In this way, we can reference the data object to be accessed through this attribute to the current page and bypass the js cross-origin issue. For example, in space projects, you need to randomly recommend several popular modules on the Management Center page under the hi domain to users, because the related information of popular modules is maintained by the php module in the act domain, if you directly obtain information about the list of Recommendation modules in the act domain through ajax requests in the hi domain, the js cross-origin issue occurs. The simplest way to solve this problem is to access the http interface provided by the act domain through the script tag in the hi domain: