网络开发的隐形壁垒：如何巧妙解决跨域难题？

什么是跨域

跨域是浏览器受同源（协议、域名、端口）策略的限制，不允许不同源的站点之间进行某些操作（如发送ajax请求，操作dom，读取cookie），如果不进行特殊配置是不能操作成功的，并且控制台会报如下跨域错误：
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'xxxxxx' is therefore not allowed access

跨域出现的场景

两个常见的例子：

• 前后端分离的项目联调时，客户端和服务端ip不一致

  一般前端本地服务启动在localhost:8080上，服务端接口部署在联调服务器上，此时向联调服务器发送请求的话就会发生跨域

• 大型项目中可能需要多个服务，不同职责的服务部署在不同的端口上，甚至多个服务器上

  在当前网站页面上请求其他服务器或者其他端口上的接口，也会发生跨域，这种情况一般通过nginx反向代理解决

跨域解决方案

JSONP

原理：利用script标签的src属性不受同源策略的限制，并且资源加载完成后会被当作js脚本立即执行的特点，来达到跨域请求资源的目的。

需要做一些特殊处理：准备一个callback函数用于处理后端传来的数据，将callback函数的名字作为src属性中的query传给后端，后端收到后用callback函数名将数据包裹起来，使数据作为参数返回给前端，当资源加载完成，callback会立即被调用，此时的实参就是我们需要的数据。

var script = document.createElement('script');

// 传参一个回调函数名给后端，方便后端返回时执行这个在前端定义的回调函数
script.src = 'http://www.domain2.com:8080/login?user=admin&callback=handleCallback';
document.head.appendChild(script);

// 回调执行函数
function handleCallback(res) {
    alert(JSON.stringify(res));
}
1
2
3
4
5
6
7
8
9
10

服务端返回如下（返回时即执行全局函数）：

handleCallback({"success": true, "user": "admin"})
1

JSONP的优缺点：

• 优点

  • 兼容性好，支持老的浏览器

• 缺点

  • 只支持get请求，因为script标签请求资源本质就是一个get请求
  • 需要服务端专门配置，把数据用callback函数名包裹起来再返回

CORS

CORS是w3c指定的跨域方案，支持所有类型的请求；兼容性：ie不能低于ie 10

CORS跨域方案将所有请求划分为简单请求和非简单请求两类，对其分别采用不同的处理方案。

简单请求

同时满足以下两个条件的请求属于简单请求：

• 请求方法是get、 post、 head中的一种
• http头字段不超出：
• Accept
• Accept-Language
• Accept-Language
• Content-Type仅限于text/plain、multipart/form-data、application/x-www-form-urlencoded

简单请求流程

浏览器在请求头中自动加入origin字段，origin字段用来说明本次请求来自哪个源（协议+域名+端口），服务器根据这个值，决定是否同意这次请求。

如果origin指定的源，不在许可范围内，服务器会返回一个正常的http回应。浏览器发现，这个回应的头信息没有包含 Access-Control-Allow-Origin 字段，就知道出错了，从而抛出一个错误，被XMLHttpRequest的onerror回调函数捕获。注意，这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。

如果Origin指定的域名在许可范围内，服务器返回的头字段中会包含Access-Control-Allow-Origin，它的值要么是请求时Origin字段的值，要么是一个*，表示接受任意域名的请求。

如何设置cookie？

• cors请求默认不携带cookie，如果想要发送cookie，需要服务端和客户端同时设置
• 一方面要服务器同意，指定Access-Control-Allow-Credentials: true
• 另一方面，开发者必须在ajax请求中打开withCredentials属性。xhr.withCredentials = true;

非简单请求

预检请求

非简单请求需要先发出一个预检请求，预检请求方法是OPTIONS，用来获知服务器是否允许该实际请求。"预检请求“的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响（PUT、delete）

请求头字段

• Origin
• Access-Control-Request-Method
• Access-Control-Request-Headers

预检请求的回应

• 如果允许跨源请求

  • Access-Control-Allow-Origin

  • Access-Control-Allow-Methods（返回的是所有支持的方法，而不单是浏览器请求的那个方法。这是为了避免多次"预检"请求。）

  • Access-Control-Allow-Headers（是一个逗号分隔的字符串，表明服务器支持的所有头信息字段，不限于浏览器在"预检"中请求的字段。）

  • Access-Control-Allow-Credentials

    • 如何设置cookie？

      • cors请求默认不发送cookie，如果想要发送cookie，需要服务端和客户端同时设置
      • 一方面要服务器同意，指定Access-Control-Allow-Credentials: true
      • 另一方面，开发者必须在AJAX请求中打开withCredentials属性。

  • Access-Control-Max-Age

    • 该字段可选，用来指定本次预检请求的有效期，单位为秒。在此期间，不用发出另一条预检请求。

• 如果不允许，比如origin不在信任名单内

  • 会返回一个正常的HTTP回应，但是没有任何CORS相关的头信息字段。浏览器就会报错

正常请求

一旦服务器通过了"预检"请求，以后每次浏览器正常的CORS请求，就都跟简单请求一样，会有一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。

反向代理

跨域是浏览器的保护机制，如果绕过浏览器，使用代理服务器去请求目标服务器上的数据，就不会受跨域影响。因此前端可以通过脚手架或webpack配置devSever下的proxy选项，将/api开头的请求转发到真实服务器上。

在生产环境下也可以使用nginx配置反向代理来解决跨域。

学习资料：点此下载