HTTP跨域的原因及解决方法(CORS 和 JSONP)

  • 在前后端对接口的时候,有时浏览器控制台会出现一诸如此类的报错:

XMLHttpRequest cannot load http://xxxxx. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://xxxxx' is therefore not allowed access. The response had HTTP status code 405.
这段话的大概意思呢,就是不允许跨域请求资源

  • 状态码

  1. 状态码分类
    1** - 信息,服务器接收到请求,需要请求者继续执行操作
    2** - 成功,操作被成功接受并处理
    3** - 重定向,需要进一步的操作以完成请求
    4** - 客户端错误,请求包含语法错误或无法完成请求
    5** - 服务端错误,服务器在处理请求的过程中发生了错误
  2. 常见状态码
    200 - 请求成功
    301 - 资源(网页等)被永久转移到其他URL
    404 - 请求的资源(网页等)不存在
    405 - 客户端请求中的方法被禁止
    500 - 内部服务器错误
  • 为什么会出现跨域问题?

  1. 什么是跨域请求
    浏览器同源策略的限制(访问同源的资源是被浏览器允许的,但是如果访问不同源的资源,浏览器默认不允许。访问不同源的资源就叫做跨域)
  2. 什么是同源策略(Same Origin Policy)?
    同源策略,是浏览器的一种核心最基本的安全策略。它对来之不同远的文档或脚本对当前文档的读写操作做了限制。同源,即协议相同,域名相同,端口相同
  3. 为什么会有跨域问题
    跨域问题只出现在浏览器访问的页面,因为这是浏览器为了保户用户安全而制造的策略。假如没有这层保护,网站就很容易受到跨站伪造请求(CSRF)的攻击。

浏览器的两种同源策略会造成跨域:

  • DOM同源策略:禁止对不同源的页面的DOM进行操作,主要包括iframe、canvas之类的。不同源的iframe禁止数据交互的,含有不同源数据的canvas会受到污染而无法进行操作。
  • XmlHttpRequest同源策略:禁止不同源的AJAX请求,主要用来防止CSRF攻击
  • 怎么解决跨域限制

  1. CORS(跨资源共享- Cross-origin resource sharing)
    CORS 是W3C推荐的一种官方方案,能使服务器支持XmlHttpRequest的跨域请求。CORS只需要添加一些HTTP头,让服务器声明允许的访问来源。

1. 使用CORS时,异步请求会被分为简单请求和非简单请求

  • 简单请求需要满足以下两大条件:
  1. 请求方法是以下三种之一:
  • HEAD
  • GET
  • POST
  1. HTTP 的头信息不超出以下几种字段:
  • Accept
  • Accept-Language
  • Content-Language
  • Last-Event-ID
  • Content-type:只限于3个值application/x-www-from-urlencoded、multipart/from-data、text/plain
  • 凡是不同时满足以上两个条件的,均属于非简单请求

a. 简单请求

对于简单请求,浏览器直接发出CORS请求。在头信息中自动添加一个Origin字段(本次请求来自哪个源:协议+域名+端口),服务器根据这个值,决定是否同意这次请求。
如果Origin指定的源,不在许可范围内,服务器返回一个正常的HTTP回应。头信息中没有包含Access-Control-Allow-Origin字段,便会抛出错误:被XMLHttpRequest的onerror回调函数捕获。
如果Origin指定的源在许可范围内,服务器会返回的响应会多出:

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

Access-Control-Allow-Origin: 请求字段为时,表示接受任意域名的请求(如果需要cookie时,不能设置为
Access-Control-Allow-Credentials: 该字段可选,是一个布尔值,表示是否发送Cookie,默认为false
Access-Control-Expose-Headers: 该字段可选,可选值有:Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragma

b. 非简单请求
非简单请求是那种对服务器有特殊要求的请求,比如请求方法是PUT或DELETE,或者Content-Type字段的类型是application/json。
非简单请求之前,会增加一次HTTP查询请求,称为“预检”请求。
浏览器先询问服务器,当前网页所在域名是否在服务器许可名单中,以及可以使用哪些HTTP动词和头信息字段,只有得到肯定的答复,浏览器才会发出XMLHttpRequest请求。

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

上面这段代码中,HTTP的请求方式是PUT,并且发送一个自定义头信息X-Custom-Header。
浏览器发现这是一次非简单请求,就自动发出“预检”请求,要求服务器确认可以这样请求,"预检"请求的头信息:

OPTIONS /cors HTTP/1.1
Origin: http://api.bbb.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header
Host: api.aaa.com
Accept-Language: en-US
Connection: keep-alive
User-Agent: Mozilla/5.0...

"预检"请求方法是OPTIONS,表示这个请求是用来询问的,头信息里边的关键字Origin表示来源。
Access-Control-Request-Method: 该字段是必须的,用来列出浏览器的CORS会用到哪些HTTP方法。
Access-Control-Request-Headers: 指定浏览器CORS请求会额外发送的头信息字段,如’token‘,'equipment'

"预检"请求的回应(检查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
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

Access-Control-Allow-Methods: 返回所有支持的方法:避免多次"预检"请求;
Access-Control-Allow-Headers: 如果浏览器有Access-Control-Request-Headers请求,则为必须;
Access-Control-Allow-Credentials: 该字段可选,是一个布尔值,表示是否发送Cookie,默认为false;
Access-Control-Max-Age: 可选,指定本次预检请求的有效期;

浏览器的正常请求和回应
当服务器通过"预检"请求之后,以后每次浏览器CORS请求都和简单请求一样,"预检"请求之后浏览器的请求:

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

服务器响应:

Access-Control-Allow-Origin: http://api.bbb.com
Content-Type: text/html; charset=utf-8

2. JSONP
可以在js中绕过同源策略,并发起跨域HTTP请求的使用模式。
同源策略有一个显著的例外,HTML脚本元素可以规避SOP检查,所以我们可以通过script标签动态注入脚本向其他源发送请求。

局限性

  1. JSONP只适用于http的get请求。
  2. JSONP缺乏错误处理机制,如果动态注入脚本成功,就会执行回调函数,如果错误,没有任何提示信息;即当遇到4,5等错误的时候,没法找到错误的原因;
  3. 在安全方面,借助JSONP有可能进行跨站请求伪造(CSRF)攻击,当一个恶意网站使用访问者的浏览器向服务器发送请求并进行数据变更时,被称为CSRF攻击。由于请求会携带cookie信息,服务器会认为是用户自己想要提交表单或者发送请求,而得到用户的一些隐私数据

推荐阅读更多精彩内容