Nginx Reverse proxy mechanism solves the problem of front-end cross-domain

Cross-domain refers to a page want to get B page resources, if a, B page of the protocol, domain name, port, sub-domain name, or a page for the IP address, b page is the domain name address, the access actions are cross-domain, and the browser for security issues generally restrict cross-domain access, that is, do not allow cross-domain request

The cross-domain situation is as follows:

Url	Description	Whether cross-domain
Http://www.cnblogs.com/a.js Http://www.a.com/b.js	Different domain names	Is
Http://www.a.com/lab/a.js Http://www.a.com/script/b.js	Different folders under the same domain name	Whether
Http://www.a.com:8000/a.js Http://www.a.com/b.js	Same domain name, different ports	Is
Http://www.a.com/a.js Https://www.a.com/b.js	Same domain name, different protocols	Is
Http://www.a.com/a.js Http://70.32.92.74/b.js	Domain and domain name corresponding IP	Is
Http://www.a.com/a.js Http://script.a.com/b.js	Primary domain is the same, subdomain is different	Yes (cookies are not accessible)
Http://www.a.com/a.js Http://a.com/b.js	Same domain name, different level two domain name (IBID.)	Is

Common approaches to cross-domain solutions

Currently, there is no technology to request resources across domains without relying on the server side.

1.JSONP requires the target server to mate with a callback function.

2.window.name+iframe requires the target server to respond to Window.name.

3.window.location.hash+iframe also requires a target server for processing.

4.HTML5 Postmessage+ifrme This also needs the target server or the target page to write a postMessage, mainly focused on the front-end communication.

5.CORS requires server settings header:Access-Control-Allow-Origin。

6.Nginx Reverse Proxy This method is rarely mentioned, but he can not use the target server, but you need to build a transit Nginx server for forwarding requests.

Nginx Reverse proxy solves cross-domain

As mentioned above, the prohibition of cross-domain issues is actually a browser security behavior, and now most of the solution is to use the label can be accessed across the domain of the vulnerability or skill to complete, but all the target server to make the corresponding changes, and I recently encountered a demand is that The target server can not give me a header, but also can not change the code to return a script, so the first 5 kinds of programs are rejected by me. Finally because my website is my own host, so I decided to build a nginx and put the corresponding code under it, by the page request an address of the domain name, the Nginx agent after the processing to return the results to the page, and all of this is synchronous.

For some basic configuration and installation of Nginx please see my other blog, the following directly explains how to configure a reverse proxy.

First, find nginx.conf or Nginx.conf.default or this part of default.

Where server represents a service started, location is a positioning rule.

Location/{   #所有以/start address, which is actually all request root  HTML     # to go to request: /html files in the folder, where: The path in Nginx has a definition, the installation will have a default path, see another blog index  index.html index.htm  # Home Response Address}

From the above we can see that the location is the portal for the Nginx to route, so we will then complete our reverse proxy in the location.

If we were www.a.com/html/msg.html, we wanted to ask www.b.com/api/?method=1&para=2;.

Our Ajax:

var url = ' http://www.b.com/api/msg?method=1¶=2 '; <br>$.ajax ({type: "GET", Url:url,success:function (res) {...}, ....})

The above request is bound to encounter cross-domain issues, then we need to modify our request URL, so that the request is sent to a URL of nginx.

var url = ' http://www.b.com/api/msg?method=1¶=2 '; var proxyurl = ' msg?method=1¶=2 ';//If the actual address is www.c.com/proxy/html/api/ msg?method=1¶=2; Www.c.com is the Nginx host address $.ajax ({type: "GET", Url:proxyurl,success:function (res) {.,....})

Again, in the path that matches the request, we add a location below the location.

Location ^~/proxy/html/{rewrite ^/proxy/html/(. *) $/$1 break;proxy_pass http://www.b.com/;}

Here's an explanation :

1. ' ^~/proxy/html/'

Like it says, it's a matching rule that intercepts requests, matches any address that starts with/proxy/html/, matches, and stops searching for regular.

2.rewrite ^/proxy/html/(. *) $/$1 break;

Represents rewriting the incoming request, and can only work on a string outside the domain name except the passed argument, such as www.c.com/proxy/html/api/msg?method=1&para=2 rewrite. Rewrite only for/proxy/html/api/msg.

The argument behind rewrite is a simple regular ^/proxy/html/(. *) $, which represents the first () in the regular, the value of the second (), and so on.

Break represents a match after a stop match.

3.proxy_pass

It is not only the request agent to other hosts, where http://www.b.com/and http://www.b.com are written in the following differences:

Not with/

location/html/{Proxy_pass http://b.com:8300;}

With

location/html/{     proxy_pass http://b.com:8300/;}

The above two configurations differ only in whether the path after the Proxy_pass is forwarded with "/".

In case 1, if the access URL = http://server/html/test.jsp, after the Nginx proxy, the request path will ask http://proxy_pass/html/test.jsp, the test/as the root path, request test /resource under the path.

In case 2, if the access URL = http://server/html/test.jsp, after the Nginx proxy, the request path becomes http://proxy_pass/test.jsp, direct access to the root resource of the server.

After modifying the configuration, restarting the Nginx agent succeeds.