- Published on
就是要跨域
- Authors
- Name
- Pursue
由于 CORS(跨域)本身是具有安全隐患的,因此浏览器默认是禁止的。但跨域却在 web 开发中具有很重要的作用,也是前端 dev 经常为之头痛的领域。那么,前端到底如何跨这个域呢,且往下看。
前端常见的跨域手段如下:
1.script/link/img 加载外部资源
一个网站常常会加载以下外部资源:
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"></script>
<link
rel="stylesheet"
href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css"
/>
<img src=“http://www.otherdomain.com/apple.jpg” />
它们都有一个相似的特点,即 js 运行时一般很难去获取其加载的资源内容。具体来说,有时候我们经常需要请求类似http://www.otherdomain.com/data.json
的文件,那我们如何能够获取这个文件的内容呢?
2.发送 ajax
面对上面的问题,大多数人就会说“发送 ajax 请求啊”,具体实现如下:
$.get(‘/data.json’,function(res) {…});
可是不好意思亲,你这是同源的,当然能请求到了。如果你访问的是http://www.otherdomain.com/data.json
,那么一定会报错,提示你不允许跨域。
其实仔细想想也不难理解,别人站点上的资源你可以通过浏览器打开访问,这没问题,因为你是处在当前的站点访问当前的资源;但是如果你在自己的站内去请求别人的资源,还能随随便便请求到的话,是你你愿意不?
所以,如果你利用 ajax 请求到了外部资源,只有一种情况:被访问的 server 端允许你跨域,即:
jsonp(返回 script 让前端调用)
后端在 response header 中设置了 Allow-Control-Allow-Origin: matcher(例如,
*
)
3.利用 iframe
其实很容易想到,iframe 本身是一个html tag
,那么它和其他能够加载资源的tag
类似,肯定也能加载外部页面,从这一点来说它算跨域。
但有一个很重要的前提:如果加载的 iframe 是一个外部页面,并且你无法修改这个页面本身(比如某个站点的首页),那么你只能在 iframe 里去操作其加载的页面。换言之,如果你想在主页面内访问嵌套的 iframe 内容,那同样还是有安全问题,是会被禁止的。
对于这种情况的处理,就得说说 postMessage 了。我们知道,页面内嵌套页面是会形成 window 链的,即 top->parent->...,而 postMessage 可以实现不同 window 之间的消息传递。
假设 A 页面和 B 页面属于不同的 domain,A 中的 iframe 加载了 B,那么用 postMessage 通信的方式如下:
- 在 B 中添加消息监听事件
window.addEventListener(‘message’, function(e){ … });
- 在 A 页面里找到 B 的 window 后调用 postMessage 发送数据
window.frames[0].postMessage(’some data’, '*');
可以看到 B 其实已经知道自己需要跨域,所以向 A 暴露了事件作为间接操作 dom 的接口,进行了自发自收的通信方式。所以只有当我们有权限修改所加载的外部页面时,postMessage 才行得通。
到此,基本可以得出结论,如果在极端情况(只有前端,无法修改后端,无法修改外部资源,只有一个外部 api 或者 url)下,前端是不能跨域的,这是浏览器的限制。
任性就是想跨域
那么也不是没有办法:我们可以修改浏览器的设置,取消浏览器对跨域的限制。
其实 chrome extension app 就允许你这么干,开发 extension 时,在mainfest.json
里,如下配置你的 app 即可让浏览器对跨域没有任何限制:
"permissions": [
"http://*/*",
"https://*/*"
]
所以许多 chrome 的插件也由此诞生,其中 votes 比较多的Allow-Control-Allow-Origin
就是一个不错的跨域 toggle 工具。
可是讲真的,你这么任性取消了 CORS 的限制,那我们还聊什么跨域呢?