这是我参与「第四届青训营 」笔记创作活动的的第5天
跨域问题场景
- XHR（XMLHttpRequest）的请求不能跨域，跨域的image无法被绘制到canvas，即无法访问其中的内容
- iframe、src、href、表单提交、打开窗口这些都不会有跨域问题 前端的跨域应该是在双方同意的基础上实现数据的可编程访问，可以将跨域问题理解为安全隐私问题
伪跨域问题： 主域名一致，但子域名不一致的情况
跨域方案
带域名限制的跨域方案
可以明确约束哪些域名可以来访问
CORS白名单跨域
通过设置被访问页面的三个response header来实现：
1.Access-Control-Allow-Origin
2.Access-Control-Allow-Credentials 决定是否能带cookie
3.Access-Control-Allow-Headers 决定支持哪些header
优点：
- 安全性好
- 设计较完善
- 浏览器支持较好
iframe+postmessage
被访问的站点专门设置一个页面用来处理跨域请求，访问方可以使用一个隐藏的iframe打开这个页面，并且通过postmessage来互相通信
优点：
- 安全性好（页面可以通过X-Frame-Options限制被iframe引用的场景，message也会强制带上域名信息）
websocket
本身不属于http协议
缺点：
- 代价比较大，需要服务端配合使用ws
无法限制来访问的域名的跨域方案
会有一些安全隐患
jsonp跨域
创建一个script标签，把src指定为想要获取数据的url，由服务端生成一段包含数据的js代码（回调）
缺点：
- 无法区分调用方
- 忽略cookie
- 调用方可能需要通过一些健全方案SSO、OAuth来获取用户身份信息来保障安全
url传参跨域
表单提交跨域
服务端代理跨域
通过本域名下的服务器去请求跨域的地址来得到数据
- 会对服务器形成额外的压力，基本不会在高流量的场景
- 鉴权信息带不过去
window.name跨域
在一个窗口的声明周期中，所有加载于这个窗口的页面供用这个窗口的window.name变量
页面重新载入等事件并不会刷新window.name
因此可以通过iframe等方式，使页面间通过window.name这个公共变量进行数据传递
