前端常见跨域解决方案

一、通过Jsonp跨域

二、document.domain+iframe 跨域

三、location.hash+iframe 跨域

四、window.name+iframe 跨域

五、postMessage 跨域

六、跨域共享资源 （CORS）

七、nginx 代理跨域

八、node js中间件代理跨域

九、WebSocket 协议跨域

1、通过Jsonp跨域

通常为了减轻Web服务器的负载，我们把Js、Css、img等静态资源分离
到另一台独立域名的服务器上，在html页面中在通过相应的标签从不同
的域名下加载静态资源，而被浏览器运行，基于此原理，我们可以通过
动态创建script标签，再请求一个带参网址实现跨域通信，是目前比较
常见的跨域方式。

缺点：只能实现get一种请求。

2、document.domain+iframe跨域

此方案仅限主域相同，子域不同的跨域应用场景。

实现原理：
两个页面都通过Js强制设置document.domain为基础主域，
就实现了同域。

3、location.hash+iframe跨域

实现原理：
A欲与B跨域相互通讯，通过中间页C来实现。三个页面，不
同域名之间利用iframe的location.hash传值,相同域名之间直接Js
访问来通信。

具体实现：
A域：a.html——>B域：b.html——>A域：c.html
a与b不同域只能通过hash值单向通信，但c与a同域，所以c可通过
parent.parent访问a页面所有对象。

4、window.name+iframe跨域

window.name属性的独特之处：
name值在不同的页面（甚至不同域名）加载后依旧存在，并且可以
支持非常长的name值（2MB）

总结：
通过iframe的src属性由外域转向本地域，跨域数据即由iframe的
window.name从外域传递到本地域。这个就巧妙地绕过了浏览器的
跨域访问限制，但同时它又是安全操作。

5、postMessage跨域

postMessage是HTML5 XMLHttpRequest Level 2中的Api，
且是为数不多可以跨域操作的window属性之一，它可用与解决以下
方面的问题：
1、页面和其打开的新窗口的数据传递
2、多窗口之间消息传递
3、页面之嵌套的iframe消息传递
4、上面三个场景的跨域数据传递

用法：
postMessage（data，origin）方法接收两个参数
data：html5规范支持任意基本类型或可复制的对象，但部分浏览器
支持字符串，所以传参时最好用JSON.stringfiy()序列化。
origin：协议+主机+端口号，也可以设置为"*",表示可以传递给任意
窗口，如果要制定和当前窗口同源的话设置为"/"。

6、跨域资源共享（CORS）

普通跨域请求：
只服务端设置Access-Control-Allow-Origin即可，前端无需设置，
若要带cookie请求，前后端都需要设置。
需注意的是：
由于同源策略的限制，所读取的cookie为跨域请求接口所在域的cookie，
而非当前页。如果想实现当前页cookie的写入，可参考下文 7、nginx反
向代理中设置proxy_cookiedomain和 8、Nodejs中间件代理中cookieDo
mainRewrite参数的设置。

目前，所有浏览器都支持该功能（IE8+：IE8/9需要使用XDomainRequest
对象来支持CORS），CORS也已经成为主流的跨域解决方案。

7、nginx代理跨域

 nginx配置解决iconfont跨域：
浏览器跨域范文Js、Css、Img等常规静态资源被同源策略许可，单iconfont
字体文件（eot/otf/ttf/woff/svg）例外，此时可在nginx的静态资源服务
器中加入配置。

8、Nodejs中间件代理跨域

node中间件实现跨域代理，原理大致与nginx相同，都是通过一个代理服务器
，实现数据的转发，也可以通过设置cookieDomainRewrite参数修改响应头中
cookie中域名，实现当前域的cookie写入，方便接口登陆认证。

9、WebSocket协议跨域

WebSocket protocol是HTML5一种新的协议。它实现了浏览器与服务器全双
工通信，同时允许跨域通讯，是server push技术的一种很好的实现。
原生WebSocket Api使用起来不太方便，我们使用Socket.io,她很好地封装
了WebSocket接口，提供了更简单、灵活的接口，也对不支持webSocket的浏
览器提供了向下兼容。