设为首页 - 加入收藏 北海站长网 (http://www.0779zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: 2019 2018 平台 数据
当前位置: 首页 > 机选5注双色球倍投中两千万 > 外闻 > 正文

CORS跨域与Nginx反向代理跨域优劣对比

发布时间:2019-04-12 10:58 所属栏目:[外闻] 来源:Segmentfault
导读:最近写了一些关于前后端分离项目之后,跨域相关方案的基本原理和常见误区的帖子,主要包括CORS和Nginx反向代理。这两种方案项目中都有在用,各有优缺,关于具体使用哪种方案,大家的观点也不大一致,本文主要就此展开一下,从前后端及服务器配置、安全性、

最近写了一些关于前后端分离项目之后,跨域相关方案的基本原理和常见误区的帖子,主要包括CORS和Nginx反向代理。这两种方案项目中都有在用,各有优缺,关于具体使用哪种方案,大家的观点也不大一致,本文主要就此展开一下,从前后端及服务器配置、安全性、移植灵活性、扩展性等方面详细对比一下两种方案的优缺,以便于后期在方案选型上对大家有所帮助。

CORS跨域与Nginx反向代理跨域优劣对比

前端配置

CORS方案:跨域时部分浏览器默认不携带cookie,因此为了携带cookie需要设置一下xmlhttprequest的withCrendetails属性,使用vue-resouce时设置如下:

  1. Vue.http.options.credentials?=?true?

用axios时,可以在拦截器中设置如下:

  1. axios.interceptors.request.use((config)?=>?{?
  2. ????config.withCredentials?=?true?
  3. ????return?config?
  4. },?(error)?=>?{?
  5. ????return?Promise.reject(error)?
  6. })?

使用原生XMLHttpRequest对象时如下,

  1. var?xhr?=?new?XMLHttpRequest();?
  2. xhr.withCredentials?=?true;?

如果不需要传递cookie,最好置成false,避免不嗯浏览器默认允许cookie的携带。

Nginx反向代理:此时前端相当于不跨域,和正常请求一致,无需额外配置。

后端配置

CORS方案: 后端需要包装ACA系列header,

  1. 'Access-Control-Allow-Origin'?'*';?
  2. 'Access-Control-Allow-Credentials'?"true";??
  3. 'Access-Control-Allow-Headers'?'X-Requested-With';?

除此以外无需额外配置。

Nginx反向代理:此时后端相当于不跨域,和正常请求一致,无需额外配置。

服务器配置

CORS方案: 无。

Nginx反向代理:该方案跨域工作都集中在nginx服务器上,配置如下:

  1. ...?
  2. proxy_set_header?X-Real-IP?$remote_addr;?
  3. proxy_set_header?X-Real-Port?$remote_port;?
  4. proxy_set_header?X-Forwarded-For?$proxy_add_x_forwarded_for;?
  5. ...?
  6. location?/api?{?
  7. ???proxy_pass?https://b.test.com;?#?设置代理服务器的协议和地址?
  8. ???proxy_cookie_domain?b.test.com??a.test.com;?#?修改cookie,针对request和response互相写入cookie?
  9. }????????
  10. ...?

安全性

CORS方案: 由于此时浏览器会默认添加origin属性,服务端可以直接查到请求来源,便于控制来源、屏蔽黑名单链接。同时服务端域名和端口会暴露出来。

Nginx反向代理:反向代理方案中没有默认的origin头部可以使用,但是可以通过X-Forward-For头部查看客户端及各级代理ip,也可以实现一定程度的回溯追踪和黑名单屏蔽。由于反向代理中,可以采用内网地址访问接口服务器,这样可以一定程度上保护接口服务器不暴露出来。

移植灵活性、扩展性

CORS方案: 只需要在代码或者配置中心进行黑白名单配置即可,方便移植和扩展。

Nginx反向代理:不同环境服务域名可能不一致,因此nginx配置也各不相同,不便于移植。而对于扩展性,当存在新的项目需要访问接口服务器时,需要首先访问nginx中server指定的域名,再由server域名反向代理到接口服务器,比如:

  1. server?{??
  2. ????listen???????8443;?
  3. ????server_name??a.test.com;?????
  4. ????client_max_body_size????????????100m;?
  5. ?????????
  6. ????ssl?...?
  7. ?
  8. ????location?/micro{?
  9. ????????proxy_pass???https://b.test.com;??#反向代理?
  10. ????????proxy_cookie_domain?b.test.com?a.test.com;?#修改cookie?
  11. ????????add_header?'Access-Control-Allow-Origin'?'htps://c.test.com';?
  12. ????????add_header?'Access-Control-Allow-Credentials'?"true";??
  13. ????????add_header?Access-Control-Allow-Headers?X-Requested-With;?
  14. ????}?
  15. }?

这个时候跨域模型就变了,由单纯的a.test.com反向代理到b.test.com,变成了a.test.com反向代理到b.test.com以及c.test.comCORS到a.test.com再反向代理到b.test.comd的情况。这个有点绕,但仔细想一下就会明白。这无疑增加了后期的维护成本。

综合对比

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章