如今“前后端分离”的设计思想已经非常普及,所以一旦静态资源和后台应用部署在不同服务器上并采用不同域名,那么,必然会遇到“浏览器同源策略”的限制,也必然,需要前后台一起合作解决跨域问题。
什么样的URL是同源的?其必须满足下面三个条件:
比如,a.com网站,想要访问b.com网站api,比如api.b.com。那么,在“同源策略”限制下,a.com网站无法获取api.b.com下的cookie,也无法向api.b.com发送ajax请求。
最简单的方式是后台服务器将允许跨域访问的URL添加到白名单中,这样,前台应用不需要做任何特殊处理。
另外,还有两种常用方法:
基本思想为:网页通过添加一个<script>元素,向服务器请求JSON数据,服务器收到请求后,将数据放在一个指定名字的回调函数里传回来。
用src属性请求资源的标签,比如<link>,<img>,<script>
...都不受同源策略的限制。
<body>
<button onclick="loadData()">LoadData</button>
<script>
function foo(res){
console.log(res)
}
function loadData(){
var elem = document.createElement('script');
elem.src = 'http://a.com/jsonp?callback=foo';
document.head.appendChild(elem);
}
</script>
</body>
用JSONP,浏览器会自动在request header里面带上a.com
下的cookie信息。
其实,通过src调用api都是GET方式,类似请求资源文件,必须明确,从Web页面产生的文件请求都会带上cookie。
因此,JSONP的缺点很明显了:
CORS是一个W3C标准,全称是"跨域资源共享"。它运行浏览器向跨域服务器发送AJAX请求。
小贴士
IE10以上用XMLHttpRequest对象实现CORS;
IE8,IE9用XDomainRequest支持CORS。
整个CORS跨域,是浏览器自动完成,不需要前端特殊处理。浏览器一旦发现是AJAX请求跨域,会添加origin头信息,后台应用需要根据request header中的origin/referer,来设置正确的response header,完成跨域请求。
cors.png
CORS具体的概念和讲解,网上很多资料,包括什么是简单请求和“Preflighted”,请参考 https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS。
下面要重点提到的是,CORS下,前端如何携带cookies?
用JS/JQuery启动AJAX请求时,必须设置withCredentials
头为true,写法如下:
JS:
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;
xhr.open('POST', ‘a.com’, true);
xhr.send();
JQuery:
$.ajax({
url: a_cross_domain_url,
xhrFields: {
withCredentials: true
}
});
这时,后台设置response header时,需要返回:
Access-Control-Allow-Credentials: true;
Access-Control-Allow-Origin: a.com; //必须为具体域名,不能是*
重点需要注意的是cookies信息!!!这时,request请求中可以携带的cookies,不仅仅有本域下的cookies,还包括跨域服务器下设置的cookies(注意:跨域服务器下的cookies,是无法通过JS代码document.cookie
访问,该cookies只能被远程服务器控制)。
可见,在安全性上,CORS比JSONP强悍很多!
CORS缺点是,低版本的IE浏览器支持不好。
针对iframe,还有些特殊的解决跨域方式,比如HTML5新特性:postMessage。
如果父子窗口是同一个主域,不同子域,也可以通过设置document.domain
属性,规避同源策略。