Summary of cross-domain request resolution method for Nginx reverse proxy, CORS, JSONP, etc.

Because of the existence of Javascript homology policies, the behavior of loading resources from other sources in one source is constrained. Cross-domain request suppression occurs.

Popular point is that if there is a protocol, domain name, port or sub-domain different server, or accesses than either for the IP address, accesses than either as the domain name address (cross-domain problem, the domain is only through the "URL header" to identify and not to try to determine the same IP address corresponds to two domains or two domains are the same IP), In any of the server's client-initiated requests for other server-side resource access actions are cross-domain, and the browser for security issues generally restrict cross-domain access, that is, cross-domain request resources are not allowed.

But many times we have to cross-domain request resources, this time we need to think of ways to circumvent the limitations of the browser-origin policy.

Common cross-domain request resolution:

1.Jsonp using the script tag to initiate a GET request will not be implemented with a cross-domain forbidden feature

2.window.name+iframe requires a target server response Window.name

3.HTML5 's postMessage focuses primarily on front-end communications, and data transfer between pages in different domains

4.Cors requires server settings header:Access-Control-Allow-Origin

5.Nginx reverse proxy can not need the target server mate, but requires Nginx relay server, for forwarding requests (server-side resource requests will not have cross-domain restrictions)

Here are the specific implementations of several commonly used solutions:

1 Jsonp

In general, we cannot request resources through XHR cross-domain because of the same origin policy, but our script tag can be successfully chained to resources from other domains without this restriction. Using the script tag, we can successfully bypass the same-origin strategy. But this approach has limitations, and we can only initiate get cross-domain requests. Specific implementation:

Client

Service side

The script tag initiates a GET request across domains, passing the global function that the client has already registered Process_fun as the query parameter, the server-side code extracts the query parameters, and passes in the data that needs to be returned. Another feature of the script tag is that the requested resource is immediately executed, so the process_fun (data) code returned by the server will be executed immediately, which means that it is passed to our pre-defined function further processing is performed in the Process_fun.

2 Cors

That is, cross-domain resource sharing. The key to achieving cors communication is the server, which can communicate across sources as long as the server implements the Cors interface. However, unlike jsonp,cors, it is not supported for browsers below IE8.

Client

Service side

Cross-domain resource sharing in my opinion is the most straightforward and easiest way to solve cross-domain problems, the only flaw is simply not able to overwrite the support of all browsers. The client does not need to make another change, it is consistent with the asynchronous request sent in the general situation, and even the client does not need to know that the requested interface is cross-domain. What the server needs to do is simply to return the response and set Access-Control-Allow-Origin The response header, which means "make a cross-domain resource request to the specified source (' * ' for any source)".

3 Window.name and PostMessage

Window.name and PostMessage focus primarily on data communication between pure front-end pages, which take advantage of "different pages loaded in the same browser window (whether they are different domains), share the same window.name, and are both window.name have read and write permission to achieve data exchange between pages, the latter is the HTML5 API, the different domains of the page under the conditions of a certain relationship can be passed through this API cross-domain data transfer.

4 Nginx Reverse Proxy

The Nginx reverse proxy solves the cross-domain problem by using the resource request between servers without the feature of cross-domain limitation, in particular, the request that our front-end initiates is blocked by Nginx, and then the request resource is forwarded by the Nginx to the resource server.

For example, now we have two Nodejs services, respectively, http://127.0.0.1:3000 and http://127.0.0.1:5000,5000 ports corresponding to the service side of the page needs to initiate the request 3000 port corresponding to the service side of the resources, of course, In this case, if no additional processing is done, the request will result in a cross-domain. This time we can use Nginx proxy forwarding our request, the front-end does not go directly to the resource server to initiate the request, but instead directly to the Nginx server, see here you may ask, the front page of the initiating request belongs to the http://127.0.0.1:5000 domain, Wouldn't the request for Nginx service be as cross-domain as a request that was initiated directly? So the point to understand here is that at first we may have access to our page through a path such as http://127.0.0.1:5000/, but if we use nginx as a reverse proxy, the proxy server listens on port 8080. We will visit the page again this time is no longer access to http://127.0.0.1:5000/, but http://127.0.0.1:8080/, in Nginx We do this configuration:

Location/{Proxy_pass http://127.0.0.1:5000;}

will be able to successfully access to the home page, and this time the home is in the 8080 port corresponding to the domain (that is, Nginx service) is rendered, so the home page this time is no longer with the http://127.0.0.1:5000 domain, but with the Nginx service domain , In other words, the front-end request for Nginx service is no longer cross-domain.

Access Nginx We can implement, the next thing to do is to request proxy forwarding.

The Ajax request for the front end is this:

Nginx needs to intercept the request, so it can be configured as follows:

The location configuration means that the request block containing "Cross_origin" is intercepted and the request path is rewritten, and the first request path is "/cross_origin/get_json?type=20170126", and the rewrite becomes "/get_json "Type=20170126", which represents the contents of (. *), and (. *) represents all the characters behind Cross_origin, that is, we remove the cross_origin part, but retain all the characters after the Cross_origin, Of course, this step is not absolutely necessary. We then proxy the request to the 3000 port corresponding to the resource service, so the request path from the beginning of "127.0.0.1:8080/cross_origin/get_json?type=20170126" after the proxy server Nginx became " 127.0.0.1:3000/get_json?type=20170126 ". There is a corresponding interface under "127.0.0.1:3000":

Now trigger a Click event on the front end to initiate the request:

Received a response, we successfully launched a cross-domain request.

Finish.

Summary of cross-domain request resolution method for Nginx reverse proxy, CORS, JSONP, etc.