跨域问题与解决方案

Zzz1m
491 阅读8分钟

什么是跨域问题？

跨域问题的产生，源自浏览器的同源策略：SOP（Same origin policy）。

同源策略是由 Netscape 提出的一个著名的安全策略，它是浏览器最核心也是最基本的安全功能，所有支持 JavaScript 的浏览器都会使用这个策略，目的是为了保护本地数据不被 JavaScript 代码获取回来的数据污染，因此拦截的是客户端发出的请求回来的数据接收，即请求发送了，服务器响应了，但是无法被浏览器接收。

同源: 如果两个URL的协议、域名、端口号都相同，就称这两个URL同源

非同源限制：

  • 无法读取非同源的 Cookie、LocalStorage 和 IndexedDB
  • 无法接触非同源的 DOM
  • 无法向非同源地址发送 AJAX 请求

跨域请求的解决方案

JSONP

Jsonp (JSON with Padding) 是一种非正式传输协议：允许用户传递一个 callback 参数给服务端，然后服务端返回数据时会将这个 callback 参数作为函数名来包裹住JSON数据，这样客户端就可以随意定制自己的函数来自动处理返回数据了。

在浏览器中，<script>、<img>、<iframe>、<link> 等标签都可以跨域加载资源，而不受同源策略的限制。基于此原理，可以通过动态创建 script，发送一个带 callback 参数的请求实现跨域通信。

使用 JS 动态生成 script 标签，进行跨域操作

function handler(response){
  console.log('The responsed data is: '+response.data)
  //处理获得的Json数据
}
var script = document.createElement('script')
script.src = 'http://www.example.com/?callback=handler'
document.body.insertBefore(script, document.body.firstChild)

或者直接添加:

<script src="http://www.example.com/?callback=handler"></script>

使用 jQuery:

$.getJson('http://www.example.com/?callback=?',function(jsondata){ });

优点：简单适用，兼容性好（兼容低版本IE）。
缺点：

  • 只能接受 GET 请求，无法拿到相关的返回头，状态码等数据
  • 安全问题(请求代码中可能存在安全隐患，callback参数恶意注入，可能会造成xss漏洞)
  • 要确定 jsonp 请求是否失败并不容易，没有关于调用错误的处理

Nginx 代理

同源策略是浏览器的安全策略，不是 HTTP协议的一部分。服务器端调用 HTTP 接口只是使用 HTTP 协议，不会执行 JS 脚本，不需要同源策略，也就不存在跨越问题。

实现思路：通过 nginx 配置一个代理服务器做跳板机，将前端的地址和后端的地址用 nginx 转发到同一个地址下，如 5500 端口和 3000 端口都转到 8080 端口下, 也可以解决跨域问题。

server {
  listen       8080;
  server_name  localhost;
  location  / {
    add_header Access-Control-Allow-Origin 'http://localhost:5500' always;
    add_header Access-Control-Allow-Headers '*';
    add_header Access-Control-Allow-Methods '*';
    add_header Access-Control-Allow-Credentials 'true';
    if ($request_method = 'OPTIONS') {
        return 204;
    }
    proxy_pass  http://localhost:3000;
  }
}

CORS

CORS (Cross-origin resource sharing）跨域资源共享，是一个 W3C 标准。它允许浏览器向跨源服务器，发出 XMLHttpRequest 请求，从而克服了 AJAX 只能同源使用的限制。

阮一峰：跨域资源共享CORS详解

  1. 需要浏览器和服务器同时支持，目前，所有浏览器都支持该功能，IE >= 10。
  2. 关键在服务端实现了 CORS 接口，浏览器自动添加一些附加的头信息。

浏览器 CORS 请求分类：

  1. 简单请求（simple request）
  2. 非简单请求（not-so-simple request）

简单请求

目的是为了兼容表单 form
对于简单请求，浏览器直接发出 CORS 请求

条件：

  1. 请求方法是 HEAD、POST、GET
  2. HTTP 头信息不超出以下几种字段：
    • Accept
    • Accept-Language
    • Content-Language
    • Last-Event-ID
    • Content-Type 仅限：
      • application/x-www-form-urlencoded
      • multipart/form-data
      • text/plain

处理方式：在头信息之中，增加一个 Origin 字段。

GET /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

Origin 字段说明本次请求来自哪个源：协议、域名、端口。
服务器根据这个值，决定是否同意这次请求。

不在许可范围内： 返回一个不包含 Access-Control-Allow-Origin 的 HTTP 回应，触发 XMLHttpRequest 的 error 事件。

在许可范围内，服务器返回的响应会多出几个头信息字段：

Access-Control-Allow-Origin: http://api.bob.com
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8

Access-Control-Allow-Origin

允许的源，要么是请求时 Origin 字段的值，要么是一个 *，表示接受任意域名的请求。

Access-Control-Allow-Credentials

是否允许发送 Cookie，布尔值，为 true 或删除该字段。如果允许发送，AJAX 请求中需要打开 withCredentials 属性。否则即使服务器同意发送Cookie，浏览器也不会发。

var xhr = new XMLHttpRequest()
xhr.withCredentials = true

如果要发送Cookie，Access-Control-Allow-Origin 就不能设为星号，必须指定明确的、与请求网页一致的域名。

Access-Control-Expose-Headers

默认情况下 XMLHttpRequest 对象的 getResponseHeader() 方法只能拿到6个基本字段：Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma。如果要拿到其他的值，需要在 Access-Control-Expose-Headers 中指定。

非简单请求

非简单请求是那种对服务器有特殊要求的请求，比如请求方法是 PUT 或 DELETE，或者 Content-Type 字段的类型是 application/json。

非简单请求的 CORS 请求，会在正式通信之前，增加一次 HTTP 预检请求（preflight）。

案例：

Ajax 请求：

var url = 'http://api.alice.com/cors'
var xhr = new XMLHttpRequest()
xhr.open('PUT', url, true)
xhr.setRequestHeader('X-Custom-Header', 'value')
xhr.send()

预检请求的头信息：

# 请求方法是 OPTIONS，表示这个请求是用来询问的
OPTIONS /cors HTTP/1.1
Origin: http://api.bob.com
# 必须字段，用来列出浏览器的CORS请求会用到哪些HTTP方法
Access-Control-Request-Method: PUT
# 逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段
Access-Control-Request-Headers: X-Custom-Header
Host: api.alice.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

预检请求的回应：服务端检查 Origin、Access-Control-Request-Method 和 Access-Control-Request-Headers，确认是否允许跨域请求，做出回应。

允许跨域：

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
# 或者设为 * 同意任意跨源请求
Access-Control-Allow-Origin: http://api.bob.com
# 服务器支持的所有跨域请求的方法, 避免多次预检
Access-Control-Allow-Methods: GET, POST, PUT
# 逗号分隔，服务器支持的所有头信息字段，不限于浏览器在预检请求的字段
Access-Control-Allow-Headers: X-Custom-Header
# 可选，用来指定本次预检请求的有效期，单位为秒
Access-Control-Max-Age: 1728000
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

不允许跨域：返回一个正常的 HTTP 回应，但是没有任何 CORS 相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误，被 XMLHttpRequest 对象的 onerror 回调函数捕获，控制台会打印出如下的报错信息：

XMLHttpRequest cannot load http://api.alice.com.
Origin http://api.bob.com is not allowed by Access-Control-Allow-Origin.

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

PUT /cors HTTP/1.1
Origin: http://api.bob.com
Host: api.alice.com
X-Custom-Header: value
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

跨域通信的解决方案

跨域通信是指浏览器中两个不符合同源策略的前端页面进行通信。
通常指的是iframe 与父页面之间的通信。

<!-- http://a.com/index.html" -->
<iframe id="iframe" src="http://b.com/index.html"></iframe>
<script>
  var iframe = document.getElementById('iframe');
  iframe.onload = function() {
    var win = iframe.contentWindow;
    // 无法读取非同源的dom
    var doc = win.document;
    var name = win.name;
  }
</script>

以下为4种常见的解决方案：

iframe + document.domain

// iframe b页面 http://b.y.com
document.domain = 'y.com'
var param = 0

// a页面 http://a.y.com
document.domain = 'y.com'
var iframe = document.getElementById('iframe')
var win = iframe.contentWindow
console.log(win.param)

限制：只能把 document.domain 设置成自身或更高一级的父域，且主域必须相同
如 a.b.c.com 只能设置为 a.b.c.com、b.c.com、c.com

优点：实现逻辑简单，无需额外中转页面
缺点：仅适用于主域相同，子域不同的前端通信跨域场景

iframe + location.hash

实现原理：不同域之间利用 iframe 的 location.hash 传值

a.html：http://www.domain1.com/a.html
a 与 b 不同域只能通过 hash 值单向通信

<iframe id="iframe" src="http://www.domain2.com/b.html" style="display:none;"></iframe>
<script>
  var iframe = document.getElementById('iframe');

  // 向b.html传hash值
  setTimeout(function() {
    iframe.src = iframe.src + '#user=admin';
  }, 1000);
  
  // 开放给同域c.html的回调方法
  function onCallback(res) {
    alert('data from c.html ---> ' + res);
  }
</script>

b.html：http://www.domain2.com/b.html
b 与 c 也不同域也只能单向通信

<iframe id="iframe" src="http://www.domain1.com/c.html" style="display:none;"></iframe>
<script>
  var iframe = document.getElementById('iframe');
  // 监听a.html传来的hash值，再传给c.html
  window.onhashchange = function () {
    iframe.src = iframe.src + location.hash;
  };
</script>

c.html：http://www.domain1.com/c.html
c 与 a 同域，所以 c 可通过 parent.parent 访问 a 页面所有对象

<script>
  // 监听b.html传来的hash值
  window.onhashchange = function () {
    // 再通过操作同域a.html的js回调，将结果传回
    window.parent.parent.onCallback('hello: ' + location.hash.replace('#user=', ''));
  };
</script>

优点：

  • 可以解决域名完全不同的跨域
  • 可以实现双向通讯

缺点：

  • location.hash 会直接暴露在 URL 里，并且在一些浏览器里会产生历史记录，数据安全性不高也影响用户体验
  • 由于 URL 长度的限制，支持传递的数据量也不大

iframe + window.name

window.name 在不同页面或不同域名加载后依旧存在，并且可以支持非常长的name值。即在一个窗口(window)的生命周期内，窗口载入的所有的页面都是共享一个 window.name 的，每个页面对 window.name 都有读写的权限。

window.name 的值只能是字符串的形式，这个字符串的大小最大能允许 2M 左右甚至更大的一个容量，具体取决于不同的浏览器。

<!-- http://a.b.com/a.html -->
<iframe id="iframe" src="http://b.c.com/b.html"></iframe>
<script>
  var state = 0;
  var iframe = document.getElementById('iframe')
  iframe.onload = function() {
    if (state === 1) {
      // 第2次onload成功后，读取同域window.name中数据
      console.log(iframe.contentWindow.name)
    } else if (state === 0) {
      // 第1次onload成功后
      state = 1
    }
  }
</script>

<!-- http://b.c.com/b.html -->
<script>
  window.name = "这里是B页面!";
  window.location = "http://a.b.com/b.html";
</script>

优点：

  • 可以解决主域不同的前端通信跨域问题
  • 通信数据类型不受限，且长度可达 2MB

缺点：需要额外的同源中转页面，但中转页可以为空白页

postMessage

postMessage 是 HTML5 XMLHttpRequest Level2 中的 API，且是为数不多可以跨域操作的 window 属性之一。解决以下问题：

  • 页面与嵌套 iframe 消息传递
  • 多窗口之间消息传递
  • 页面和其打开的新窗口的数据传递

语法：otherWindow.postMessage(message, targetOrigin, [transfer])

  • otherWindow：其他窗口的引用
    • iframe 的 contentWindow 属性
    • 执行 window.open 返回的窗口对象
    • 命名过或数值索引的 window.frames
  • message：要发送到其他 window 的数据
  • targetOrigin：指定哪些窗口能接收到消息事件，其值可以是 * 或者一个 URI
  • transfer：可选，一串和 message 同时传递的 Transferable 对象。这些对象的所有权将被转移给消息的接收方，而发送一方将不再保有所有权。

Transferable 接口代表一个能在不同可执行上下文之间，例如主线程和 Worker 之间，相互传递的对象。

常用示例：

http://a.com/index.html

<iframe id="iframe" src="http://b.com/index.html"></iframe>
<script>
  var iframe = document.getElementById('iframe');
  iframe.onload = function() {
    var data = { message: 'ok' }
    var win = iframe.contentWindow;
    win.postMessage(JSON.stringify(data), 'http://b.com/index.html')
  }
  window.addEventListener("message", function(e) {
    if(e.origin === 'http://b.com/index.html') {
      console.log('B页面发来消息：' + JSON.parse(e.data)); // received
    }
  });
</script>

http://b.com/index.html

window.addEventListener("message", function(e) {
  console.log('message from A:' + JSON.parse(e.data)); // ok
  var data = { meesage: 'received' };
  window.parent.postMessage(JSON.stringify(data), 'http://a.com/index.html');
}, false);

优点：

  • 安全地实现跨源通信
  • 可以解决多种类型的前端跨域通信问题

缺点：

  • 兼容性：IE8 及以下浏览器不支持该方法，IE9 只支持传字符串
  • postMessage 的调用者不能监测到监听者抛出的异常
avatar
文章
阅读
粉丝