# 为什么会产生跨域问题
- 浏览器限制,目前所有浏览器都实现了同源策略规范。
- 请求方式Type为xhr。如果非xhr,如json,script则也不会存在跨域问题
- 请求方与服务方的源不同,即跨域,包括:
- 协议不同
- 域名不同
- 端口不同
同时满足三个条件才有可能产生跨域问题。
# 解决方案
对于浏览器限制的解决方案-关闭浏览器的同源策略
--args --disable-web-security --user-data-dir
设置浏览器的启动参数,将浏览器的同源策略取消。该方式要求所用的用户进行手动操作,肯定是不现实的。-
请求方式Type为xhr的解决方案
既然只有Type为xhr的请求才会存在跨域请求,那么我们是不是可以换一种请求方式呢。Jsonp的实现就是这样。将原本Type是xhr的请求伪造成script请求。
Jsonp的请求路径后面会自动带上callback参数,服务端可据此判断是否是jsonp请求,将返回值以script的形式进行封装。且服务端需要进行相应的改动。
对于SpringBoot项目
@ControllerAdvice public class JsonpAdvice extends AbstractJsonpResponseBodyAdvice{ public JsonpAdvice{ super("callback"); //约定的jsonp请求参数 } }
JQuery实现jsonp的原理:
动态创建一个script,通过这个script去请求,请求完,该script即被销毁。可通过对jQuery打断点的方式验证。(可以看到JQuery在网页源代码嵌入了一个临时的script,当Jsonp请求完成之后,该Script即被销毁)
-
弊端:
- 服务器需要改动
- 只支持GET方式 (因为获取script都是GET方式,前端指定请求方式也无效,还以GET方式发起的请求)
- 跨域的解决方案
根据实际系统架构来决定使用哪种方式
-
被调用方解决
返回的响应头的包含允许跨域访问的信息,需要被调用方进行代码的修改。(可由具体应用添加允许跨域信息,也可以由容器,Tomcat,jetty等添加)
- 通过Filter实现
- 将允许跨域请求的信息配置在nginx或者apache转发服务器
- 调用方解决
在调用方与被调用方中间再增加一层,该层做转发,将调用方的请求转发到被调用方。其中第一点因为调用方与该转发层在同一个域名下,所以不会有跨域问题。第二点,由于不是浏览器发起的请求,所以转发层调用被调用方也是不存在跨域问题的(参见跨域的三要素)。
简单请求与非简单请求
当浏览器发起一个跨域请求的时候会先判断是简单请求还是非简单请求。
对于简单请求,浏览器会先请求,拿到结果后再判断是否跨域。
对于非简单请求,浏览器会先发起一个预检options请求,检查通过之后再发起实际的请求。
对于带cookie的跨域请求,
- 需要将allowedOrigins设置为具体的origin,而不能使用
*
。 - 需要设置响应参数
allowCredentials(true)
,允许带cookie的跨域