摘要:但是随着互联网的发展,同源策略严重影响了项目之间的连接尤其是大项目,有几个域名需要进行沟通的,标准推出了跨来源资源共享。
同源策略相信各位同学已然不陌生了,在这里不做过多阐述,简单介绍一下就好:
URL | 说明 | 是否允许 |
---|---|---|
http://www.a.com/a.js / http://www.a.com/b.js | 同一域名下 | 允许 |
http://www.a.com/lab/a.js / http://www.a.com/script/b.js | 同一域名下不同文件夹 | 允许 |
http://www.a.com:8000/a.js http://www.a.com/b.js | 同一域名,不同端口 | 不允许 |
http://www.a.com/a.js https://www.a.com/b.js | 同一域名,不同协议 | 不允许 |
http://www.a.com/a.js http://70.32.92.74/b.js | 域名和域名对应ip | 不允许 |
http://www.a.com/a.js http://script.a.com/b.js | 主域相同,子域不同 | 不允许 |
http://www.a.com/a.js http://a.com/b.js | 同一域名,不同二级域名(同上) | 不允许(cookie这种情况下也不允许访问) |
http://www.cnblogs.com/a.js http://www.a.com/b.js | 不同域名 | 不允许 |
以上表格系统的阐述了如何算是跨域。
那么下面我们
今天我们着重讲讲对抗同源策略的方法:
CORS——Cross-origin resource sharing(跨来源资源共享)
由于HTML 5的概念形成,在原有XHR的基础上提出了XMLHttpRequest Level2(XHR2),在XHR2中对CORS有了很好的支持。(除了远古的IE8,IE9这些老古董)
我们先看看看CORS日常是怎么实现跨域的
• isset($_POST["name"])? $_POST["name"] : "", • "gender" => isset($_POST["gender"])? $_POST["gender"] : "" • ); • • //HTTP_ORIGIN是请求头中的信息,在浏览器中直接展示为Origin • $origin = isset($_SERVER["HTTP_ORIGIN"])? $_SERVER["HTTP_ORIGIN"] : ""; • //此处是允许跨域的白名单 • $allow_origin = array( • "http://www.client.com", • "http://www.client2.com" • ); • //判断当前Origin来源是否在白名单内,是的话就允许设置一套三式Header头让他跨域 • if(in_array($origin, $allow_origin)){ • //关键点是这里的一套三式 • header("Access-Control-Allow-Origin:".$origin); //允许的域名 • header("Access-Control-Allow-Methods:POST"); //允许的方法 • header("Access-Control-Allow-Headers:x-requested-with,content-type"); //服务器支持的头信息 • } • • echo json_encode($ret); • ?>
关键词在header("Access-Control-Allow-*":) 一套三件,不同如果无法通过这一套三件的洗礼,那么就报类似下面这样的错:
XMLHttpRequest cannot load http://b.com. No "Access-Control-Allow-Origin" header is present on the requested resource. Origin "http://a.com" is therefore not allowed access.
这个就是浏览器同源策略造成的,如果我们没有设置Header头三件套的话("Access-Control-Allow-*":)那么对一切跨域请求操作浏览器都是拒绝的~。
但是随着互联网的发展,同源策略严重影响了项目之间的连接(尤其是大项目,有几个域名需要进行沟通的),W3C标准推出了“跨来源资源共享——CORS”。
回到前面的那段实例代码,我们来分析分析 请求-》处理-》返回 一套流程的来龙去脉。
CORS的背后基本思想就是使用自定义的HTTP头部让浏览器与服务器进行沟通,从而决定请求响应是应该成功还是应该失败。
当Http请求发起(可以通过更新操作去测试POST,或者用JavaScript请求测试GET)的时候(不分跨不跨域)会类似带着以下请求头信息:
Origin:http://www.csdnblog.com
返回头也会夹带着类似如下信息:
Access-Control-Allow-Credentials:true Access-Control-Allow-Origin:http://www.csdnblog.com
一来一回的请求决定的请求决定了改请求是否会被浏览器通过,如果返回头中没有这个头部,或者有头部但是源信息不匹配(就是说返回头%-Allow-Origin中没有当前请求站点的域名),那么浏览器就会帮我们驳回这次请求,同源策略在这里发挥了作用。
通过这一来一回我们不难发现其实浏览器判断是否驳回的标准就是返回头中是否有 Access-Control-Allow-% 这个信息,并且判断这个信息是否合法(即这个信息是否是与请求头中的Origin对应的上),对应的上就通过,对应不上就驳回。
既然搞懂这个我们就可以理解为何通过CORS设置两三行Header代码既可以轻松跨域了吧?
服务端代码设置Header返回头告诉浏览器“谁谁谁是允许访问我的,你看到这家伙就给我放行吧~“。
所以如果在服务端代码中设置:
header("Access-Control-Allow-Origin:*")
是的,这样的话任何域名都可以请求你的服务器了,当然这样子你的服务器也就非常危险了。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/11213.html
摘要:关于,强烈推荐阅读跨域资源共享详解阮一峰另外,这里也整理了一个实现原理图简化版如何判断是否是简单请求浏览器将请求分成两类简单请求和非简单请求。 前言 从刚接触前端开发起,跨域这个词就一直以很高的频率在身边重复出现,一直到现在,已经调试过N个跨域相关的问题了,16年时也整理过一篇相关文章,但是感觉还是差了点什么,于是现在重新梳理了一下。 个人见识有限,如有差错,请多多见谅,欢迎提出iss...
摘要:在接触前端开发起,跨域这个词就一直以很高的频率在我们学习工作中重复出现,最近在工作中遇到了跨域的相关问题,这里我把它总结记录一下。 在接触前端开发起,跨域这个词就一直以很高的频率在我们学习工作中重复出现,最近在工作中遇到了跨域的相关问题,这里我把它总结记录一下。关于跨域,有N种类型,现在我只专注于ajax请求跨域(ajax跨域只是属于浏览器同源策略中的一部分,其它的这里不做介绍),内容...
阅读 3142·2023-04-25 17:19
阅读 592·2021-11-23 09:51
阅读 1323·2021-11-08 13:19
阅读 759·2021-09-29 09:34
阅读 1658·2021-09-28 09:36
阅读 1457·2021-09-22 14:59
阅读 2675·2019-08-29 16:38
阅读 2017·2019-08-26 13:40