Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to solve the js cross-domain problem, the article is very detailed, has a certain reference value, interested friends must read it!

The cross-domain problem of Js is one of the most common problems encountered by web developers. The so-called cross-domain problem of js refers to accessing data objects in another domain through js in a page under one domain. For security reasons, almost all browsers do not allow such cross-domain access. As a result, in some ajax applications, using cross-domain web service will become a problem. To solve the cross-domain problem of js, there are some ready-made solutions on both the client and the server, but these solutions can not solve all the problems. Let's first take a look at the common solutions, and give a space's own solution to the cross-domain problem of space products, hoping to be of reference to other product groups.

Client solution

How to solve the js cross-domain problem on the client side is the first consideration for almost all web developers. At present, there are two most commonly used methods: setting document.domain and loading through the script tag.

Set up document.domain

The premise of this approach is that the two pages involved in the cross-domain request must belong to the same underlying domain (for example, both xxx.com or xxx.com.cn), using the same protocol (for example, both 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-domain calls. In addition, it is important to note that this approach can only be used in parent and child pages, that is, it is only useful when using iframe for data access.

Load through the script tag

For browsers, the resources pointed to by the src attribute of the script tag are the same static resources as the resources pointed to by the src attribute of the img tag. Browsers will automatically load these resources at an appropriate time without the so-called cross-domain problems. In this way, we can bypass the js cross-domain problem by referencing the data object to be accessed by this property into the current page. For example, in my space project of space, we need to randomly recommend several popular modules to users in the management center page under the hi domain. Because the relevant information of the hot modules is maintained in the php module under the actdomain, there will be a js cross-domain problem if you directly get the list of recommended modules under the actdomain through the ajax request in the hi domain. The easiest way to solve this problem is to access the http interface provided by the act domain through the script tag under the hi domain:

Of course, the premise is that the http interface of the act domain must return a js script, such as a script defined by an array of json objects:

Modlist = [

{"modname": "mod1", "usernum": 200,200, "url": "/ widget/info/1"}

{"modname": "mod2", "usernum": 300, "url": "/ widget/info/2"}

...

]

However, script tags also have some limitations, which can not solve all js cross-domain problems. The src attribute value of the script tag cannot be dynamically changed to meet the needs of obtaining different data under different conditions, and more importantly, the data organized in the form of xml content cannot be correctly accessed in this way.

Server-side solution

As you can see from the above instructions, the client solution is too limited, and ajax cross-domain requests cannot be resolved on the client side, regardless of whether the two domains belong to the same underlying domain or not. That is, if we want to access data from other domains in an ajax request, we have to process it through the server. The basic principle of the server-side solution is that the client sends the request to the local domain server, and then the agent of the local server requests the data and returns the response to the client. The most common server solution is to take advantage of the proxy capabilities provided by the web server itself, such as apache and lighttpd's mod_proxy module. In the inner part of Baidu, the diversion function of transmit can also solve some cross-domain problems. However, these methods have some limitations. In view of security and other issues, space finally developed a spproxy module for managing cross-domain request proxy services, which is used to thoroughly solve the cross-domain problem of js. Next, we will take the open platform of space as an example to briefly introduce how to solve the cross-domain problem through the mod_proxy of apache, the shunt of transmit and the spproxy module of space, and briefly introduce some features, shortcomings and next improvement plans of spproxy. Before showing each UWA open module, the space must request the xml source code of the module for parsing, and the source code files of each module are stored in the / ow/uwa directory under the actdomain, so there will be a js cross-domain problem when requesting the xml file in the user space homepage (hi domain). To solve this problem, js can only request xml files from the web server in the hi domain, while the web server in the hi domain requests files from the web server in the act domain through certain proxy mechanisms (such as mod_proxy, transmit shunt, spproxy).

Using the mod_proxy module of apache

If apache is a 2.0 series version, you can solve this by adding the following configuration to the httpd.conf file:

ProxyRequests Off

Order deny,allow

Allow from all

ProxyPass / ow/uwa http://act.hi.baidu.com/ow/uwa

Among them, the ProxyRequests directive turns off the forward proxy function of mod_proxy and enables the reverse proxy function, the Proxy directive makes the configuration effective for all access, and the ProxyPass directive enables access to any resource in the / ow/uwa directory of the domain to be internally converted into a proxy request for the corresponding resource under the / ow/uwa directory in the act.hi.baidu.com domain. In this way, js can obtain the 10001.xml file located in the / ow/uwa/0/1/0/ directory under the act domain directly by accessing http://hi.baidu.com/ow/uwa/0/1/0/10001.xml.

If apache is version 1.3 modified by each product line of Baidu, then mod_proxy and mod_rewrite modules need to work together to achieve the same goal. First, you need to add the following Location directive to httpd.conf:

SetHandler proxy-server

Order allow,deny

Allow from all

In this way, the access to any resources under the / ow/uwa directory in this domain will first be handled by proxy-server (a handler defined within the mod_proxy module), but this configuration alone is not enough, because proxy-server does not know what to do yet, just know that it needs to be handled by itself. At this point, you need to add a rewrite rule to the configuration section:

RewriteRule ^ / ow/uwa/ (. *) $http://act.hi.baidu.com/ow/uwa/$1?%{QUERY_STRING} [PJL]

The last [PMagel] of the Rewrite rule indicates that the rewrite is passed through the mod_proxy proxy, not through external redirection. If the P flag is removed, the following rewrite rules are adopted:

RewriteRule ^ / ow/uwa/ (. *) $http://act.hi.baidu.com/ow/uwa/$1?%{QUERY_STRING} [L]

Then the resource uri indicated when the response is returned to the client will be the redirected uri. In our example, it is the uri of the act.hi.baidu.com domain, and the browser will still have js cross-domain problems. The above is just a simple application of apache's proxy function. For a better and more powerful introduction, please refer to references [1] and [2]. Mod_proxy is powerful, but we don't use it to solve cross-domain problems. First of all, to use it, we must require that each of our front-end machines can access the public network, otherwise we can only delegate the request to one of the front-end machines (rewrite or proxy through the machine name as the private network domain name), which is obviously not desirable, because one of our domain names is usually made up of many front-end machines, and only one of them will cause the pressure on that machine to be very uneven compared with other machines. It can't even stand the pressure, and adding access to the public network to all front-end machines may have some security policy problems (the exact reason is not clear, but op and sa obviously won't approve of this approach). Secondly, because apache itself does not have a good anti-ddos*** mechanism, once someone goes to the target domain (such as our competitor's website) through an agent, then in the web server of the target domain, the * * person will become us. When this happens, we will be unable to defend ourselves and jump into the Yellow River.

The above is all the content of the article "how to solve the cross-domain problem of js". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.