Chrome 跨域问题CORS 分析

先叠个甲,有错误,望沟通指正!

1.什么是跨域报错

has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

类似上面的报错 ,就是出现了跨域限制访问问题

2.为什么postman可以,浏览器访问就不行?根本原因是什么?

同源策略（Same-Origin Policy）,这个是浏览器的一个策略.也就是在A的域 去请求B域的资源,是不被浏览器允许的
这一种存在于浏览器上的安全策略,所以你用edge还是chrome,都会出现这个问题.而使用postman则没有.
抛出这个报错的根源在于浏览器

2.1浏览器是依据什么来报错跨域的?

并不是只通过IP来判断是否跨域报错的.
这里还涉及到一个参数就是Access-Control-Allow-Origin.如果请求B域的时候,返回的header带有这个参数.那么也是被浏览器允许的(可以通过同源策略的安全限制)

B域的服务,返回头中是否带有Access-Control-Allow-Origin,取决于B域的后台服务的代码中,是否开启了相关功能.
具体JAVA GOLANG PYTHON C#,如何开启Access-Control-Allow-Origin ,可以全网搜一下 ,不赘述了

也就是B域的服务端,开启了Access-Control-Allow-Origin,那么所有浏览器都可以跨域访问呢这个资源

3.常规解决方案的分析

方案1.通过代理解决

也就是最常见到的,在使用vue-admin-templete等前端分离项目开发时,咱们在vue.config.js里面配置的proxy
类似这样

devServer: {port: port,   //服务器 是A域open: true,overlay: {warnings: false,errors: true},before: require('./mock/mock-server.js'),proxy: {'/dev-api/vat':{target:"http://B域:8080",changeOrigin: true,}}},

结论: 核心原理也就是转发. ,对于浏览器来说,访问/dev-api/vat的时候,实际上确实是访问服务器的/dev-api/vat资源.
但是服务器在后台启动了一个代理,将/dev-api/vat资源转发给了B域.
因为是代理服务发起给B域的,所以没有同源策略的限制.代理服务自然能够成功收到B域的返回.
接下来代理服务将结果返回给浏览器(这里对于浏览器来说,代理服务和A域 是同源的 所以没有报错)

方案2.被请求的B域的服务端开启Access-Control-Allow-Origin返回头的支持

具体JAVA GOLANG PYTHON C#,如何开启Access-Control-Allow-Origin ,可以全网搜一下 ,不赘述了
也就是B域的服务端,开启了Access-Control-Allow-Origin,那么多有浏览器都可以跨域访问呢这个资源

方案3.通过设置浏览器关闭同源策略来实现访问互通

以chrome为例 ,在快捷方式–属性–目标这里,追加参数 --disable-web-security --user-data-dir=用户数据目录 即可

例如
"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir=C:\temp

此时 打开chrome将不再受跨域的束缚,但是会提示你安全性降低

4.对比3种方案

	方案1-代理	方案2-服务端代码放开	方案3-浏览器关闭同源策略
安全性	相对 高	相对 中	相对 低
方便性	相对 中	相对 中	相对 高
使用场景	开发调试 多个服务继承部署	开发调试 多个服务继承部署 生产多环境调用	无所不能
调用区别	前端所在的服务器去调用B域	可以在浏览器访问端直接调用B域	随便搞