Le mécanisme de proxy inverse nginx résout les problèmes inter-domaines front-end

Actuellement, il n'existe aucune technologie qui ne s'appuie pas sur le serveur pour demander des ressources entre domaines

　1.jsonp nécessite que le serveur cible coopère avec une fonction de rappel .

2.window.name+iframe nécessite que le serveur cible réponde à window.name.

　3.window.location.hash+iframe nécessite également le serveur cible pour le traitement.

postMessage+ifrme de 4.html5 nécessite également que le serveur cible ou la page cible écrive un postMessage, se concentrant principalement sur la communication frontale.

5. CORS nécessite que le serveur définisse l'en-tête : Access-Control-Allow-Origin。

6. nginx reverse proxy Cette méthode est rarement mentionnée, mais elle ne nécessite pas de cible serveur Coopérez, mais vous devez configurer un serveur relais nginx pour transmettre les demandes.

Le proxy inverse nginx résout les problèmes inter-domaines

Comme mentionné ci-dessus, interdire les problèmes inter-domaines est en fait un comportement de sécurité des navigateurs, et la plupart des solutions actuelles utilisent des balises ou des failles. techniques d'accès inter-domaines, mais elles nécessitent toutes que le serveur cible apporte les modifications correspondantes. J'ai récemment rencontré une exigence selon laquelle le serveur cible ne peut pas me donner d'en-tête, et encore moins modifier le code pour renvoyer un script, donc les 5 options précédentes. ont été rejetés par moi. Enfin, comme mon site Web est mon propre hébergeur, j'ai décidé de créer un nginx et de déployer le code correspondant sous celui-ci. La page demande une adresse de ce nom de domaine, et l'agent nginx la traite et renvoie le résultat à la page. ça, tout est synchronisé.

À propos de nginxConfiguration et installation de baseVeuillez consulter mon autre blog, ce qui suit expliquera directement comment configurer un proxy inverse.

Recherchez d'abord nginx.conf ou nginx.conf.default ou cette partie par défaut

Où le serveur représente un service démarré et l'emplacement est une règle de positionnement.

location /｛   #所有以/开头的地址，实际上是所有请求
 
root  html     ＃去请求../html文件夹里的文件,其中..的路径在nginx里面有定义，安装的时候会有默认路径，详见另一篇博客
 
index  index.html index.htm  ＃首页响应地址
 
｝

Comme vous pouvez le voir ci-dessus, l'emplacement est le point d'entrée utilisé par nginx pour le routage, nous compléterons donc notre proxy inverse dans l'emplacement ensuite.

　　假如我们我们是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代理就成功了。