摘要:最近写了一些关于前后端分离项目之后,跨域相关方案的基本原理和常见误区的帖子,主要包括和反向代理。反向代理此时后端相当于不跨域,和正常请求一致,无需额外配置。
最近写了一些关于前后端分离项目之后,跨域相关方案的基本原理和常见误区的帖子,主要包括CORS和Nginx反向代理。这两种方案项目中都有在用,各有优缺,关于具体使用哪种方案,大家的观点也不大一致,本文主要就此展开一下,从前后端及服务器配置、安全性、移植灵活性、扩展性等方面详细对比一下两种方案的优缺,以便于后期在方案选型上对大家有所帮助。
CORS方案:跨域时部分浏览器默认不携带cookie,因此为了携带cookie需要设置一下xmlhttprequest的withCrendetails属性,使用vue-resouce时设置如下
Vue.http.options.credentials = true
用axios时,可以在拦截器中设置如下
axios.interceptors.request.use((config) => { config.withCredentials = true return config }, (error) => { return Promise.reject(error) })
使用原生XMLHttpRequest对象时如下,
var xhr = new XMLHttpRequest(); xhr.withCredentials = true;
如果不需要传递cookie,最好置成false,避免不嗯浏览器默认允许cookie的携带。
Nginx反向代理:此时前端相当于不跨域,和正常请求一致,无需额外配置。
CORS方案: 后端需要包装ACA系列header,
"Access-Control-Allow-Origin" "*"; "Access-Control-Allow-Credentials" "true"; "Access-Control-Allow-Headers" "X-Requested-With";
除此以外无需额外配置。
Nginx反向代理:此时后端相当于不跨域,和正常请求一致,无需额外配置。
CORS方案: 无。
Nginx反向代理:该方案跨域工作都集中在nginx服务器上,配置如下
... proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Real-Port $remote_port; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; ... location /api { proxy_pass https://b.test.com; # 设置代理服务器的协议和地址 proxy_cookie_domain b.test.com a.test.com; # 修改cookie,针对request和response互相写入cookie } ...
原理移步nginx反向代理跨域基本配置与常见误区、nginx配置解析之客户端真实IP的传递
安全性CORS方案: 由于此时浏览器会默认添加origin属性,服务端可以直接查到请求来源,便于控制来源、屏蔽黑名单链接。同时服务端域名和端口会暴露出来。
Nginx反向代理:反向代理方案中没有默认的origin头部可以使用,但是可以通过X-Forward-For头部查看客户端及各级代理ip,也可以实现一定程度的回溯追踪和黑名单屏蔽。由于反向代理中,可以采用内网地址访问接口服务器,这样可以一定程度上保护接口服务器不暴露出来。
CORS方案: 只需要在代码或者配置中心进行黑白名单配置即可,方便移植和扩展。
Nginx反向代理:不同环境服务域名可能不一致,因此nginx配置也各不相同,不便于移植。而对于扩展性,当存在新的项目需要访问接口服务器时,需要首先访问nginx中server指定的域名,再由server域名反向代理到接口服务器,比如
server { listen 8443; server_name a.test.com; client_max_body_size 100m; ssl ... location /micro{ proxy_pass https://b.test.com; #反向代理 proxy_cookie_domain b.test.com a.test.com; #修改cookie add_header "Access-Control-Allow-Origin" "htps://c.test.com"; add_header "Access-Control-Allow-Credentials" "true"; add_header Access-Control-Allow-Headers X-Requested-With; } }
这个时候跨域模型就变了,由单纯的a.test.com反向代理到b.test.com,变成了a.test.com反向代理到b.test.com以及c.test.comCORS到a.test.com再反向代理到b.test.comd的情况。这个有点绕,但仔细想一下就会明白。这无疑增加了后期的维护成本。
综合对比综合以上,我们大致可以得到如下图标
Item | CORS | Nginx反向代理 |
---|---|---|
代码配置--前端 | credentials=true | 无 |
代码配置--后台 | setHeader:ACA-Origin、ACA-Method、ACA-Credentials等 | 无 |
服务器配置 | 无 | Nginx配置 |
移植灵活性 | 高、无需额外配置 | 低、每套环境配置可能均不相同 |
安全性 | 来源可控、直接追溯 | X-Forwarded-For追溯多级来源 |
新项目扩展 | 黑白名单控制 | 更新配置,跨域模型会产生变化 |
综上呢,对于公共基础服务,由于涉及到对接的前端项目可能比较多,开发测试部署环境也比较多,整体上来讲我更倾向于推荐大家使用CORS方案。而对于一些对立性强的小项目,使用nginx则可以降低你的开发成本,快速发开快速上线。具体使用当然也要结合工作实际,按需使用吧。
此外对于Nginx反向代理方案使用时,推荐使用内部域名/ip作为接口服务器的入口,尽量不要暴露到外面,以免出现不必要的安全问题。
~本篇完~欢迎大家一起讨论~
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/40097.html
摘要:反向代理服务器对于客户端而言它就像是原始服务器,并且客户端不需要进行任何特别的设置。使用反向代理可能访问网页相对于之前响应会比较慢 标签: Nginx,跨域 问题 在之前的分享的跨域资源共享的文章中,有提到要注意跨域时,如果要发送Cookie,Access-Control-Allow-Origin就不能设为*,必须指定明确的、与请求网页一致的域名。在此次项目开发中与他人协作中就遇到...
摘要:反向代理服务器对于客户端而言它就像是原始服务器,并且客户端不需要进行任何特别的设置。使用反向代理可能访问网页相对于之前响应会比较慢 标签: Nginx,跨域 问题 在之前的分享的跨域资源共享的文章中,有提到要注意跨域时,如果要发送Cookie,Access-Control-Allow-Origin就不能设为*,必须指定明确的、与请求网页一致的域名。在此次项目开发中与他人协作中就遇到...
阅读 2579·2021-11-17 17:00
阅读 1776·2021-10-11 10:57
阅读 3657·2021-09-09 11:33
阅读 891·2021-09-09 09:33
阅读 3519·2019-08-30 14:20
阅读 3296·2019-08-29 11:25
阅读 2780·2019-08-26 13:48
阅读 716·2019-08-26 11:52