1. 什么是跨域
当一个请求的url的协议 域名 端口三者之间任意一个与当前页面的url不同即为跨域
2. 为什么会出现跨域问题
浏览器的同源策略导致了跨域问题
同源: 如果两个页面的协议 端口 和域名都相同 则两个页面具有相同的源
浏览器的同源策略 是浏览器最核心也最基本的安全功能，分为以下两种
DOM 同源策略：禁止对不同源页面 DOM 进行操作。这里主要场景是 iframe 跨域的情况，不同域名的 iframe 是限制互相访问的。
XMLHttpRequest 同源策略：禁止使用 XHR 对象向不同源的服务器地址发起 HTTP 请求。
同源策略只要带来以下三方面的限制
1、cookie，localstorage和IndexDB无法读取
2、DOM无法获取
3、Ajax请求不能发送
同源策略的目的是保证用户可以更安全的上网 防止更多方式的恶意攻击
跨域的目的是:为了能够使得使用cookie，让浏览器能够将sessionid放入到request。服务端能够识别是那个用户登录的。从而跨域也可以请求资源，并且不需要登录。
3. 跨域问题的解决方法
跨域问题的解决方法有jsonp ,jquery ,ifram ,cors
3.1 CORS是应用比较广泛的一种跨域方式
CORS:Cross-Origin Rersource Sharing 跨来源资源共享
CORS 原理是使用自定义的 HTTP 头部让浏览器与服务器进行沟通，从而决定请求或响应是应该成功，还是应该失败
CORS 需要浏览器和服务器同时支持
浏览器端支持
- IE8 和 IE9 通过 XDomainRequest 插件支持CORS，IE10 开始则完全正常支持CORS
- 其余现代版本的浏览器均支持CORS 旧版本浏览器可能存在兼容性问题
服务器端支持
浏览器将CORS请求分为两类: 简单请求 和 非简单请求(预检请求)
同时满足下列条件即为 简单请求
请求方法是以下三种方法之一：
- HEAD
- GET
- POST
HTTP的头信息不超出以下几种字段：
- Accept 、
- Accept-Language 、
- Content-Language 、
- Last-Event-ID、
- Content-Type：只限于三个值 application/x-www-form-urlencoded、multipart/form-data、text/plain
凡是不同时满足此两个条件的都是非简单请求(预检请求)
浏览器对不同的请求 有不同的处理方式
简单请求: 只会发送一次HTTP请求
- 在请求中附加一个Origin头部 其中包含请求页面的原信息(协议 域名 端口)，一边服务器根据这个头部信息来决定是否给予响应
- 如果服务器认为这个请求可以接受，就在 Access-Control-Allow-Origin 头部中回发相同的源信息
- 如果Origin制定的源不在许可范围内，服务器会返回一个正常的HTTP响应 但响应头信息中不包含Access-Control-Allow-Origin字段 ，浏览器会抛出一个错误 被XHR的onerror回调函数捕获 此处无法通过状态码识别 因为响应状态码可能是200
非简单请求(预检请求):在正式通行之前 增加一次HTTP查询请求
- 由于跨域请求可能会携带使用者的信息 所以要先进行预检请求
预检请求通过 后续正式通信则与简单请求相同 - 预检请求的请求头信息中
Access-Control-Request-Method 请求自身使用的方法。
Access-Control-Request-Headers（可选）自定义的头部信息，多个头部以逗号分隔。 - 发送这个请求后，服务器可以决定是否允许这种类型的请求。
- 服务器通过在响应中发送如下头部与浏览器进行沟通：
- Access-Control-Allow-Origin：与简单的请求相同。
- Access-Control-Allow-Methods: 允许的方法，多个方法以逗号- 分隔。
- Access-Control-Allow-Headers: 允许的头部，多个方法以逗号分隔。
- Access-Control-Max-Age: 应该将这个 Preflight 请求缓存多长时间（以秒表示）。
一旦服务器通过 Preflight 请求允许该请求之后，以后每次浏览器正常的 CORS 请求，就都跟简单请求一样了。
CORS优点:
- CORS 通信与同源的 AJAX 通信没有差别，代码完全一样，容易维护。
- 支持所有类型的 HTTP 请求。
缺点: - 存在兼容性问题，特别是 IE10 以下的浏览器。
- 第一次发送非简单请求时会多一次请求。
3.2 JSONP跨域 目前最流行的一种跨域方法
JSONP(JSON with Padding) 是 json 的一种补充使用方式，利用 script 标签来解决跨域问题。
JSONP 是非官方协议，他只是前后端一个约定，如果请求参数带有约定的参数，则后台返回 javascript 代码 而非 json 数据，返回代码是函数调用形式，函数名即约定值，函数参数即要返回的数据。
script标签&img标签 的src属性 不受浏览器同源策略的影响允许跨域引用资源
JSONP实现原理:
首先在客户端 js 中定义一个函数（假设名为 handler），然后动态创建一个 script 标签插入页面中，script 标签的 src 属性即要调用的地址，同时，在调用的 url 中加入一个服务端约定的参数（假设名为 callback，参数值为已定义的函数名 handler），服务端收到请求，如果发现请求的 url 中带有约定的参数，那么就返回一段函数调用形式的 javascript 代码，该段代码的函数名即为 callback 参数的值 handler，函数的参数即为待返回的数据。这样，客户端拿到返回结果后就会执行 handler 函数，对返回的数据进行处理。
JSONP请求的响应
发送JSONP请求时，请求的 Type 为 script 类型而非 xhr 类型，这样就打破了跨域报错的三个必要条件，不会产生跨域错误，同时也验证了服务端返回的数据格式为 javascript 代码调用的形式
使用 JSONP 来解决跨域问题存在以下缺陷：
- 只能发送 GET 请求
- 发送的不是 XHR 请求，这样导致 XHR 请求中的很多事件都无法进行处理
- 服务端需要改动
- 由于是从其它域中加载代码执行，因此如果其他域不安全，很可能会在响应中夹带一些恶意代码
- 要确定 JSONP 请求是否失败并不容易。虽然 HTML5 给 script 标签新增了一个 onerror 事件处理程序，但是存在兼容性问题。
JSONP跨域方案
- 客户端:用script.src向服务器发送请求
服务端:将要返回的数据填充在一条合法的js语句中返回
问题:服务端将客户端执行的程序写死 众口难调 - 客户端:提前定义一个处理函数 可接受服务端的数据并执行在客户端本地自定义的操作
服务端:将普通js语句修改为函数调用语句 且函数名与客户端提前定义的函数名一致
问题:服务端将函数名写死 也是 众口难调 - 客户端:在script.src请求的url之后 将提前定义好的函数名以查询字符串的形式拼接上去 可以将自定义好的函数名传给服务器端
服务器端:将请求的url之后的查询字符串解析并截取出函数名
动态拼接到要返回的js语句中
问题:script标签 写在html页面中时 客户端只能在页面加载时请求一次 无法按需反复请求 - 在事件处理函数中动态创建script
问题:script会堆积 - 在事件处理函数的结尾自动删除最后一个script
企业项目中跨域操作
jquery的$.ajax中将 dataType设置为 jsonp
script.src后拼接的查询字符串为 ?callback=自定义函数名
JSONP跨域的优点是:使用简便 没有兼容性问题
参考博文:
https://blog.csdn.net/u014297572/article/details/82012390
https://www.cnblogs.com/laixiangran/p/9064769.html
https://www.cnblogs.com/qcloud1001/p/10191996.html
扫一扫
2959
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
