Same domain name, different second-level domain names (same as above)
| is |
|
Common cross-domain solutions
Currently, there is no technology that does not rely on the server to request resources across domains
1.jsonp requires the target server to cooperate with a callback function.
2.window.name+iframe requires the target server to respond to window.name.
3.window.location.hash+iframe also requires the target server for processing.
4.html5’s postMessage+ifrme also requires the target server or target page to write a postMessage, which mainly focuses on front-end communication.
5.CORS requires the server to set the header: Access-Control-Allow-Origin.
6.nginx reverse proxy This method is rarely mentioned, but it does not require the cooperation of the target server, but you need to build a transit nginx server for forwarding ask.
nginx reverse proxy solves cross-domain issues
As mentioned above, prohibiting cross-domain issues is actually a security behavior of the browser, and most of the current solutions use tags. This loophole or skill in cross-domain access can be accomplished, but it is indispensable for the target server to make corresponding changes. Recently, I encountered a requirement that the target server cannot give me a header, let alone change the code to return a script, so the previous All 5 options were rejected by me. Finally, because my website is my own host, I decided to build an nginx and deploy the corresponding code under it. The page requests an address of this domain name, and then the nginx agent handles it and returns the result to the page. And all this It's all synchronized.
About some basic configuration and installation of nginxPlease see my other blog, the following will directly explain how to configure a reverse proxy .
First find nginx.conf or nginx.conf.default or this part of default
Where server represents a started service, location is a positioning rule.
location /｛ #所有以/开头的地址，实际上是所有请求
root html ＃去请求../html文件夹里的文件,其中..的路径在nginx里面有定义，安装的时候会有默认路径，详见另一篇博客
index index.html index.htm ＃首页响应地址
｝
As can be seen from the above, location is the entry point used by nginx for routing, so we next need to complete our reverse proxy in location.
假如我们我们是www.a.com/html/msg.html 想请求www.b.com/api/?method=1¶=2；
我们的ajax：
var url = 'http://www.b.com/api/msg?method=1¶=2'；
<br>$.ajax({
type: "GET",
url:url,
success: function(res){..},
....
})上面的请求必然会遇到跨域问题，这时我们需要修改一下我们的请求url，让请求发在nginx的一个url下。
var url = 'http://www.b.com/api/msg?method=1¶=2'；
var proxyurl ＝ 'msg?method=1¶=2'；
//假如实际地址是 www.c.com/proxy/html/api/msg?method=1¶=2; www.c.com是nginx主机地址
$.ajax({
type: "GET",
url:proxyurl,
success: function(res){..},
....
}) 再在刚才的路径中匹配到这个请求，我们在location下面再添加一个location。
location ^~/proxy/html/{
rewrite ^/proxy/html/(.*)$ /$1 break;
proxy_pass http://www.b.com/;
}
以下做一个解释：
1.'^~ /proxy/html/ '
就像上面说的一样是一个匹配规则，用于拦截请求，匹配任何以 /proxy/html/开头的地址，匹配符合以后，停止往下搜索正则。
2.rewrite ^/proxy/html/(.*)$ /$1 break;
代表重写拦截进来的请求，并且只能对域名后边的除去传递的参数外的字符串起作用，例如www.c.com/proxy/html/api/msg?method=1¶=2重写。只对/proxy/html/api/msg重写。
rewrite后面的参数是一个简单的正则 ^/proxy/html/(.*)$ ,$1代表正则中的第一个(),$2代表第二个()的值,以此类推。
break代表匹配一个之后停止匹配。
3.proxy_pass
既是把请求代理到其他主机，其中 http://www.b.com/ 写法和 http://www.b.com写法的区别如下:
不带/
location /html/
{
proxy_pass http://b.com:8300;
}带/
location /html/
{
proxy_pass http://b.com:8300/;
}
上面两种配置，区别只在于proxy_pass转发的路径后是否带 “/”。
针对情况1，如果访问url = http://server/html/test.jsp，则被nginx代理后，请求路径会便问http://proxy_pass/html/test.jsp，将test/ 作为根路径，请求test/路径下的资源。
针对情况2，如果访问url = http://server/html/test.jsp，则被nginx代理后，请求路径会变为 http://proxy_pass/test.jsp，直接访问server的根资源。
修改配置后重启nginx代理就成功了。
