Ajax cross-Domain

Outline

About cross-domain, there are n types, this article only focus on ajax请求跨域 (, Ajax cross-domain is only part of the browser "same-Origin policy", the other is also a cookie cross-domain iframe cross-domain, Localstorage cross-domain, etc.), the content is probably as follows:

• What is Ajax cross-domain
  • Principle
  • Performance (sorting out some of the problems encountered and solutions)
• How to troubleshoot Ajax cross-domain
  • Jsonp Way
  • Cros Way
  • Proxy Request method
• How to analyze Ajax cross-domain
  • Analysis of HTTP packet capture
  • Some examples

What is the principle of Ajax cross-domain ajax across domains

Ajax request cross-domain error problem, the main reason is because the browser "homologous policy", you can refer to the browser Origin policy and its avoidance method (Nanyi)

Cros Request principle

Cors is a universal standard, with the name "cross-domain resource sharing" (cross-origin resource sharing). It allows the browser to issue XMLHttpRequest requests to cross-origin servers, overcoming the limitation that Ajax can only use the same origin.

Basically all browsers now implement the Cors standard, in fact, almost all of the browser Ajax requests are based on the cors mechanism, but it is possible that the front-end developers do not care about it (so that its implementation in the Cros solution is mainly to consider how to implement the background of the problem).

About Cros, read more about cross-domain resource sharing CORS detailed (Nanyi)

In addition, an implementation schematic (simplified version) is also organized here:

How can I tell if it is a simple request?

The browser divides the Cors requests into two categories: simple request and non-simple (Not-so-simple request). As long as the following two conditions are met, it is a simple request.

• The request method is one of the following three methods: Head,get,post
• The header information for HTTP does not exceed the following fields:
  • Accept
  • Accept-language
  • Content-language
  • Last-event-id
  • Content-type (limited to three values application/x-www-form-urlencoded, Multipart/form-data, Text/plain)

It is a non-simple request that does not satisfy the above two conditions at the same time.

The performance of the Ajax cross-domain

To tell the truth, I remember finishing an article, and then as a solution, but later found that there are still many people still do not. Helpless only time-consuming and laborious debugging. However, even if I analyze it, it is important to judge whether it is cross-domain based on the corresponding performance.

Ajax requests, if there is a cross-domain phenomenon, and is not resolved, there will be the following: (Note that is the AJAX request, please do not say why the HTTP request can, and Ajax does not, because Ajax is accompanied by the cross-domain, so just HTTP request OK is not possible)

Note: For the specific backend cross-domain configuration, please see the topic location.

The first of these phenomena: No ‘Access-Control-Allow-Origin‘ header is present on the requested resourceAnd The response had HTTP status code 404

This situation occurs for the following reasons:

• This AJAX request is a "non-trivial request", so a pre-check request (OPTIONS) is sent before the request
• The server-side background interface does not allow the options request, resulting in the inability to find the corresponding interface address

Solution: Back-end allow options requests

The second phenomenon: No ‘Access-Control-Allow-Origin‘ header is present on the requested resourceAnd The response had HTTP status code 405

This behavior differs from the first, in which case the background method allows the options request, but some configuration files (such as 安全配置 ) block the options request, which can cause this behavior

Solution: The backend shuts down the corresponding security configuration

The third phenomenon: No ‘Access-Control-Allow-Origin‘ header is present on the requested resourceAnd status 200

This behavior differs from the first and second, in which case the server-side background allows the options request, and the interface allows the options request, but there is a mismatch in the head match

For example, Origin header check mismatch, such as the lack of some head support (such as the Common X-requested-with head), then the server will return response to the front end, the front end detects this trigger Xhr.onerror, leading to the front console error

Solution: Back end adds corresponding head support

The fourth kind of phenomenon: heade contains multiple values ‘*,*‘

The behavior is that there are two HTTP header messages for the background responseAccess-Control-Allow-Origin:*

To be honest, the main reason for this problem is that people who cross-domain configuration do not understand the principle, resulting in duplicate configuration, such as:

• Common in. NET background (typically an origin is configured in Web. config, and then the origin is added manually in the code (for example, the code manually sets the return *))
• Common in. NET background (set origin:* in both IIS and Project Webconfig)

Solution (one by one corresponds):

• It is recommended to remove the code from the manually added *, only in the project configuration
• It is recommended that you remove the configuration under IIS *, only in the project configuration

How to troubleshoot Ajax cross-domain

The general Ajax cross-domain solution is solved by JSONP or Cros, such as the following: (note, now almost no longer use JSONP, so Jsonp understand the next can)

Jsonp Way to solve cross-domain problems

Jsonp solving cross-domain issues is a relatively ancient scenario (not recommended in practice), here is a brief introduction (in real-world projects if you want to use JSONP, you will typically use the JQ and other JSONP-encapsulated class libraries to make AJAX requests)

Implementation principle

The reason why JSONP can be used to solve cross-domain scenarios is mainly because

Implementation process

The implementation steps of JSONP are as follows (refer to the articles in the source)

• Client Web page by adding a

function addScriptTag(src) {  var script = document.createElement(‘script‘);  script.setAttribute("type","text/javascript");  script.src = src;  document.body.appendChild(script);}window.onload = function () {  addScriptTag(‘http://example.com/ip?callback=foo‘);}function foo(data) {  console.log(‘response data: ‘ + JSON.stringify(data));};

When requested, the interface address is the SRC of the built-in script tag, so that when the script tag is built, the final SRC is the content returned by the interface

• The interface corresponding to the server adds a function wrapping layer outside the return parameter

foo({  "test": "testData"});

• Because

Use note based on the implementation principle of JSONP, so JSONP can only be "GET" request, not more complex post and other requests, so in that case, you have to refer to the following Cros resolution cross-domain (so now it is basically eliminated)

Cros resolving cross-domain issues

The Cros principle is described above, and here is the main introduction to how the backend should be configured to solve the problem (since a large number of project practices are addressed by the backend), here are some common back-end solutions:

PHP Background Configuration

PHP backend configuration is almost all the simplest in the background, follow the following steps:

• First step: Configure PHP Background to allow cross-domain

<?phpheader(‘Access-Control-Allow-Origin: *‘);header(‘Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept‘);//主要为跨域CROS配置的两大基本信息,Origin和headers

• Step Two: Configure the Apache Web server cross-domain (httpd.conf) Raw code

<Directory />    AllowOverride none    Require all denied</Directory>

Change to the following code

<Directory />    Options FollowSymLinks    AllowOverride none    Order deny,allow    Allow from all</Directory>

node. JS background configuration (Express framework)

The backend of node. JS is also relatively simple to configure. Simply configure with Express as follows:

app.all(‘*‘, function(req, res, next) {res.header("Access-Control-Allow-Origin", "*");res.header("Access-Control-Allow-Headers", "X-Requested-With");res.header("Access-Control-Allow-Methods", "PUT,POST,GET,DELETE,OPTIONS");res.header("X-Powered-By", ‘ 3.2.1‘)        //这段仅仅为了方便返回json而已res.header("Content-Type", "application/json;charset=utf-8");if(req.method == ‘OPTIONS‘) {//让options请求快速返回res.sendStatus(200); } else { next(); }});

Java Background configuration

Java background configuration only needs to follow the following steps:

• The first step: Get the Dependent jar package download Cors-filter-1.7.jar, java-property-utils-1.9.jar the two library files into the Lib directory. (placed under the webcontent/web-inf/lib/of the corresponding project)

• Step two: If the project was built with MAVEN, add the following dependencies to Pom.xml: (non-maven please ignore)

<dependency><groupId>com.thetransactioncompany</groupId><artifactId>cors-filter</artifactId><version>[ version ]</version></dependency>

Where the version should be the latest stable version, Cros filter

• Step three: Add the Cros configuration to the project's Web. XML (App/web-inf/web.xml)

<!--cross-domain configuration--><filter><!--The CORS filter with parameters--><filter-name>cors</filter-name ><filter-class>com.thetransactioncompany.cors.CORSFilter</filter-class><!--Note:all  Parameters is options, if omitted the CORS Filter would fall back to the respective default values. --><init-param><param-name>cors.allowgenerichttprequests</param-name><param-value> True</param-value></init-param><init-param><param-name>cors.alloworigin</param-name ><param-value>*</param-value></init-param><init-param><param-name> cors.allowsubdomains</param-name><param-value>false</param-value></init-param>< Init-param><param-name>cors.supportedmethods</param-name><param-value>get, HEAD, POST, options</param-value></init-param><init-param><param-name>cors.supportedheaders</ Param-name><param-value>Accept, Origin, X-requested-with, Content-type, Last-modified</param-value></init-param><init-param ><param-name>cors.exposedHeaders</param-name><!--Here you can add some of your own exposure headers--><param-value >x-test-1, x-test-2</param-value></init-param><init-param><param-name> cors.supportscredentials</param-name><param-value>true</param-value></init-param>< init-param><param-name>cors.maxage</param-name><param-value>3600</param-value></ init-param></filter><filter-mapping><!--CORS Filter Mapping--><filter-name>cors</ Filter-name><url-pattern>/*</url-pattern></filter-mapping>

Please note that the above configuration file is placed in front of the Web. XML, as the first filter exists (can have multiple filter)

• Fourth step: Possible Security Module Configuration error (note that some frameworks-such as the company's private framework, there are security modules, sometimes these security module configuration will affect cross-domain configuration, you can first try to close them)

NET Background configuration

. NET background configuration can refer to the following steps:

• First step: web site Configuration Open the Control Panel, select Administrative Tools, select IIS, right-click your own website, select Browse; Open the directory where the site is located, open the Web. config file with Notepad to add the following configuration information, restart the site please note that older, if the configuration still problems, Consider adding more headers to allow, such as:

"Access-Control-Allow-Headers":"X-Requested-With,Content-Type,Accept,Origin"

• Second Step: Additional configuration, if the first step has been done, there are still cross-domain issues, may be:
  • The interface has some restrictions on the number of dead request types (such as writing dead post, etc.), please remove the limit
  • Interface, the configuration is repeated Origin:* , please remove the
  • IIS server, the configuration is repeated Origin:* , please remove the

Proxy request method resolves interface cross-domain issues

Note that because the interface agent is at a cost, this is only done during the development process.

Unlike the previous method, the front Cros is a back-end solution, and this is mainly the front-end to the interface agent, that is:

• The front-end AJAX request is local interface
• The local interface requests data to the actual interface after it receives the request, and then returns the information to the front end
• Typically use node. js to Proxy

about how to implement the agent, here is not the focus of description, methods and many, it is not difficult, basically is based on node. js.

Search for keywords node.js to 代理请求 find a big package.

How to analyze Ajax cross-domain

The above has introduced the principle of cross-domain and how to solve, but in the actual process, found that there are still many people to follow similar documents can not solve cross-domain problems, mainly reflected in, the front-end personnel do not know when the cross-domain problem caused, when not, so here is a little introduction to how to analyze a request cross-domain:

Grab Packet Request data

The first step, of course, is to know what data our AJAX requests are sending, what we receive, and it's not difficult to do this, or to fiddler wait for tools, based on just Chrome

• ChromeThe browser opens a page that corresponds to an AJAX occurrence, F12 opensDev Tools
• Send an AJAX request
• Right panel NetWork , and XHR then find the AJAX request that you just went to.

Example one (normal Ajax request)

The above request is a correct request, for convenience, I put the meaning of each head field is indicated, we can clearly see that the interface returned by the response header field, including the

Access-Control-Allow-Headers: X-Requested-With,Content-Type,AcceptAccess-Control-Allow-Methods: Get,Post,Put,OPTIONSAccess-Control-Allow-Origin: *

Therefore, when the browser receives the response, the correct request is judged, and the response data is successfully obtained.

Example two (cross-domain error AJAX request)

For convenience, we still take an example of the error shown above.

In this request, the interface allow is not included OPTIONS , so the request appears across the domain,

This request, which Access-Control-Allow-Origin: * occurred two times, caused the cross-domain configuration to not be configured correctly and an error occurred.

More cross-domain errors are basically similar, that is, the above three is not satisfied (Headers,allow,origin), here no longer one by one repeat.

Example three (Ajax requests that are cross-domain independent)

Of course, not all Ajax request errors are related to cross-domain, so please do not confuse, such as the following:

For example, this request, its cross-domain configuration is not a bit of a problem, it is only because of request Accept and response mismatch Content-Type .

More

Basically this is the analysis of an AJAX request, through the Chrome can know what data sent, what data received, and then the right to know what the problem is.

Appendix Reference

• Browser homology policy and its avoidance method (Nanyi)
• Cross-domain resource sharing CORS detailed (Nanyi)
• My previous article on the Cnblog

Original link

• Https://dailc.github.io/2017/03/22/ajaxCrossDomainSolution.html

Ajax cross-domain (GO)