无论是前端同学还是后端同学,可能都接触过跨域问题。网上已经有了很多介绍跨域问题和解决方案的博客文章,笔者之前也是看过很多关于跨域问题的文章,当时感觉已经了解得差不多了,不过最近又有了一些新的认识,所以写这篇文章记录一下,希望也能对读者有所帮助。当然,本文是笔者自己的认识和实践,如果有不准确的地方,还请不吝指教。
在正式介绍之前,大家可以先思考一下下面几个问题:
1、跨域问题是浏览器导致的还是服务端导致的?
2、为什么在服务端配置几个响应头就可以解决跨域问题?
3、发生跨域问题时,请求发送出去了没有?服务端有没有接收到请求,有没有进行处理和响应?
4、为什么在浏览器里发送Ajax请求会发生跨域,但是在浏览器地址栏直接请求接口或者通过postman却不会有问题?
5、跨域问题(或者说背后的同源策略)到底保护的是谁?
这几个问题是笔者最近重新认识或者是重新确认的问题。本文主要是围绕上面的几个问题展开的,对于一些基础知识(如同源策略等)则不会赘述,还请大家自行百度。
对于问题1,大家应该都知道答案——浏览器,具体来说是浏览器同源策略的限制。
既然是浏览器的限制,那浏览器限制的是什么,请求还是响应?最开始笔者也是认为是限制了请求,跨域问题发生的时候,浏览器拦截了请求,没有发送出去。但是这种理解无法解释问题2,如果请求没有发送出去,也就是请求根本就没有到达服务端,服务端的配置又有什么用呢?
实际上,浏览器限制的是响应。
这个问题也比较容易验证,读者可以在本地启动一个服务端测试接口,用来接收前端页面的请求(设置断点或者打印日志来确认请求是否接收成功),比如接口地址为:http://localhost:8080/test,然后再写一个前端页面,通过 Ajax 方式请求后端接口,需要保证前端页面的访问也是通过域名访问的(比较简单的方式是使用python -m SimpleHTTPServer8000),比如访问地址是:http://localhost:8000/test.html。最终的结果证明,发生跨域报错时,请求已经发送出去了,而且服务端接收了请求并且进行了正常的处理。
确认了限制响应这个问题,那么问题2和问题3就迎刃而解了。
对于问题4,其实也容易理解。大家可以回到“同源”和“跨域”这两个词本身,对于直接发出的请求,无论是从浏览器的地址栏发出的请求,还是 postman 发出的请求,还是 Java 程序发出的请求,根本没有当前域的概念,实际上每发出一个请求,都是在独立请求一个资源,而不是在一个网站返回的页面里,再去请求另外一个网站/端口的资源,自然也就不会造成跨域了。
对于问题5,其实是要解释限制响应这种方式,对于服务端来说是没有保护作用的。要解释这个问题,还是要回到同源策略,这是浏览器的安全策略,虽然也是要保护用户的数据,但是是从浏览器的角度出发的。简单说是要浏览器保证在A域名下谨慎接收B域名返回的资源,防止B域名返回的资源是窃取A域名用户数据的恶意资源,这种保护只是最基础的保护机制(也可以说是最弱的保护),你不能指望同源策略来完全保护用户数据。对于用户数据的保护,主要工作还是在服务端完成,服务端要保证请求是合法的、是已经鉴权的。
以上便是读者最近关于跨域问题的新认识。
在这里提一下,同源策略是一个非常核心、非常基础的策略,是 Web 前端安全的核心,网上有人说,
《Web前端黑客技术揭秘》,非常系统的解析了前端安全知识,这些知识都是要围绕着同源策略展开的,可想而知它是有多重要
对于同源策略的理解,当前也只是停留在大概是什么、大概能解决什么问题的阶段,对于理解跨域问题已经基本足够,但是对于具体的场景还是理解不多,希望日后能有机会再整理一篇关于同源策略的深度文章,可能那时候对于跨域也会有更深的理解。
参考文章:
浏览器的同源策略
https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy
浏览器同源政策及其规避方法,阮一峰
http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html
不要再问我跨域的问题了
网友评论