Nginx反向代办跨域基础设置与罕见误区

2019年8月22日 201次阅读 来源: 木子墨

近来公司前后端星散，前端自力供应页面和静态效劳很天然的就想到了用nginx去做静态效劳器。同时因为跨域了，就想应用nginx的反向代办去处置惩罚一下跨域，但是在解决题目的同时，发明网上有些计划的确是存在一些题目，在这里总结一下基础设置，也聊一下罕见的设置题目。

Nginx接口效劳反向代办基础设置

server {
    listen 8443; # 监听的端口号
    server_name a.test.com; # 效劳器称号
    client_max_body_size 100m;   # 定义读取客户端要求头的超时时刻
    ssl on;
    ssl_certificate test.pem;
    ssl_certificate_key test.key;
    ssl_session_timeout 5m;
    ssl_protocols SSLv3 TLSv1.2;
    ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
    ssl_prefer_server_ciphers on;
    location / {
        root /test-static-app; # 静态资本目次
        index index.html index.htm;
        try_files $uri $uri/ /index.html; # 动态剖析目次，合营vue的history形式
    }
}

基础设置完成了页面及静态效劳器的基础功能，并能够完成运用vue的history形式时的路由剖析。进一步的，为了完成向接口效劳器的一致转发，我们需要和后端开发人员划定接口名的前缀，比方一切接口的相对途径都以api开首，此时我们能够增加以下设置(和上一个location平级)，

...
location /api {
   proxy_pass https://b.test.com; # 设置代办效劳器的协媾和地点
   proxy_cookie_domain b.test.com  a.test.com; # 修正cookie，针对request和response相互写入cookie
}       
...

个中重要依靠proxy_pass，完成将a.test.com下的/api/x接口转发到了b.test.com下面，这个历程大抵以下
《Nginx反向代办跨域基础设置与罕见误区》

cookie的交互重要就是proxy_cookie_domain，加上下面这段

proxy_cookie_domain b.test.com  a.test.com;

这个完成了，a.test.com和b.test.com域名之间cookie的通报与回写。这里的明白有点误区，请移步到细致诠释Nginx反向代办明白误区之proxy_cookie_domain

假如用node来模仿一下的话，大抵以下

module.exports =  (router) => {
  router.get('/api/index/getCmsInfo', async function (ctx, next) {
    // 接口转发
    let result = await superagent.post('https://b.test.com/api/card/home').set(browserMsg)
    // 猎取返回的set-cookie，并设置header
    let setCookie = result.headers['set-cookie']
    if (setCookie) {
        ctx.response.header['set-cookie'] = setCookie
    }
    // 返回
    ctx.response.body={
        success: true,
        result: result.body 
    }
  })
}

综上nginx反向代办的实质实在就是接口效劳的转发与header的处置惩罚，细致想一想也就轻易明白了。

罕见误区

1、无用的ACA-Header ？
网上许多的nginx跨域设置内里都加了跨域header设置相干的内容，比方

add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Credentials' "true"; 
add_header Access-Control-Allow-Headers X-Requested-With;

想一想上面的道理，列位看官以为这个还有效么？ACA(Access-Control-Allow-)系列的header自身是为了cors中做协商跨域而设置的，在这里配这个纯属脱裤子放屁节外生枝。
2、proxy_pass 域名带不带‘斜杠/’ ？
一样的，在网上看到了有的网友在设置proxy_pass的时刻，会在背面加一个斜杠，以下，然后说报错啦，找不到接口啦～咋整啊～

...
location /api {
   #proxy_pass https://b.test.com;
   proxy_pass https://b.test.com/;
}       
...

看到这个我们来想一想哈，proxy_pass的作用是抓发，加了斜杠意味着一切的/api要求都邑转发到根目次下，也就是说 /api 会被 / 替换，这个时刻接口途径就变了，少了一层/api。而不加斜杠的时刻呢？这代表着转发到b.test.com 的域名下，/api的途径不会丧失。
针对这类状况，假如后端接口一致有了划定前缀，比方/api，那你这里就不要设置斜杠了。另一种状况，后端接口shit一样，没有一致前缀，这边又要辨别，那就在前端一切接口都加一个一致前缀，比方/api，然后经由过程加斜杠来替换掉好了～

以上就是本次的全部内容了～本日的《新闻联播》播送完了，感谢收看，再会～再会～

    原文作者：木子墨
    原文地址: https://segmentfault.com/a/1190000016200035
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞