HTTP之访问控制「CORS」

序言

跨域资源共享「CORS」就是在不一样的域名、协议、端口直接请求资源。本文主要讲述了什么是跨域，什么状况下会出现预检请求，我司的跨域安全访问

什么是跨域

同源策略

出于安全的缘由，在没有被容许的状况下浏览器限制从不一样源「origin」发起请求，也多是跨站请求能够正常发起，可是返回结果被浏览器拦截了。

什么才能是同源

源：由协议+域名+端口组成，也就是说，这个三个要统一才同源

例：

• http://www.baidu.com && https://www.baidu.com 不一样源 协议不一样
• http://api.baidu.com && http://www.baidu.com 不一样源 域名不一样
• http://www.baidu.com:8081 && http://www.baidu.com:8080 不一样源 端口不一样
• www.baidu.com/index.html && www.baidu.com/404.html 同源

什么状况下会出现预检请求

预检请求

跨域资源共享标准新增了一组HTTP首部字段，容许服务器声明哪些源站经过浏览器有权限访问哪些资源。在某些会对服务器数据产生做用「须要修改数据库」的请求「主要是GET之外的请求」，浏览器会先发送经过OPTIONS方法发送预检请求，从服务器那边获得返回是否容许跨域。服务器也能够携带是否须要身份凭证通知浏览器。

也就是说：在你发送请求的时候，浏览器会本身先发送一个预检请求。后台只须要识别请求的方法「OPTIONS」，而后返回一些信息。 以下图：

这里有两个login/请求，第一个是浏览器主动发出的。它的Request Method方法为 OPTIONS，而后服务器的返回信息：

• access-control-allow-headers：容许你携带头的参数
• access-control-allow-methods：容许你发送请求的方法
• access-control-allow-origin：容许你发送请求的地址

这部分信息通知了你修改本身的请求参数来符合服务器的要求， 服务器如何除了浏览器发送的预检请求，能够参照这个MDN Server-Side_Access_Control (CORS)。

简单请求

在如下状况下发送的请求不会触发预检请求

• 使用如下方法之一：「GET HEAD POST」

• 头部字段在这个集合以内：「Accept， Accept-Language， Content-Language， Content-Type （须要注意额外的限制）， DPR， Downlink， Save-Data， Viewport-Width， Width」

• Content-Type如下三种之一：「text/plain，multipart/form-data，application/x-www-form-urlencoded」

• ...

例子：我在发送登陆的时候，头部字段自定义了Authorization，这时候就触发预检请求

我司的访问控制方式

JSON Web Token「JWT」

公司主要采用的就是JWT的跨域认证解决方案。JWT的意思就是：用户发送登陆信息「用户名，密码」给服务器，服务器认证后生成一个JSON对象，给用户储存，以后用户请求数据都须要带上JWT来发送请求。

步骤

• 1. 登陆 发送用户名密码给服务器验证返回JWT

• 2. 前端经过LocalStorage储存JWT

• 3. 以后的请求带上JWT

     

• 4. 验证过时或者失败直接返回401退到登陆页面

     

不足之处

• JWT一旦签发了，在到期以前始终有效，这样别人可使用你的JWT获取数据
• JWT过时或失效的时候，用户仍然须要经过失效的JWT请求才能知道JWT已经失效

扩展阅读

若是前端没有跟后端创建统一API设计规范，可使用这个 RESTful api

参考

MDN HTTP访问控制 阮一峰 JWT入门教程