理解session,cookie,token以及js-cookie,sessionStorage，localStorage在实际开发中的使用

Web 存储（localStorage和sessionStorage）

HTML5 Web 存储（webStorage）是本地存储，存储在客户端，包括localStorage和sessionStorage。HTML5 Web 存储是以键/值对的形式存储的，通常以字符串存储。

localStorage

localStorage生命周期是永久，除非主动清除localStorage信息，否则这些信息将永远存在。存放数据大小为一般为5MB,而且它仅在客户端（即浏览器）中保存，不参与和服务器的通信。

// 1、保存数据到本地
// 第一个参数是保存的变量名，第二个是赋给变量的值
localStorage.setItem('Author', 'local');
 
// 2、从本地存储获取数据
localStorage.getItem('Author');
 
// 3、从本地存储删除某个已保存的数据
localStorage.removeItem('Author');
 
// 4、清除所有保存的数据
localStorage.clear();

sessionStorage

sessionStorage 属性允许你访问一个，对应当前源的 session Storage 对象。它与 localStorage 相似，不同之处在于 localStorage 里面存储的数据没有过期时间设置，而存储在 sessionStorage 里面的数据在页面会话结束时会被清除。

页面会话在浏览器打开期间一直保持，并且重新加载或恢复页面仍会保持原来的页面会话。
在新标签或窗口打开一个页面时会复制顶级浏览会话的上下文作为新会话的上下文，这点和 session cookies 的运行方式不同。
打开多个相同的URL的Tabs页面，会创建各自的sessionStorage。
关闭对应浏览器窗口（Window）/ tab，会清除对应的sessionStorage。

sessionStorage仅在当前会话下有效，关闭页面或浏览器后被清除。存放数据大小为一般为5MB,而且它仅在客户端（即浏览器）中保存，不参与和服务器的通信。

// 1、保存数据到本地
// 第一个参数是保存的变量名，第二个是赋给变量的值
sessionStorage.setItem('Author', 'session');
 
// 2、从本地存储获取数据
sessionStorage.getItem('Author');
 
// 3、从本地存储删除某个已保存的数据
sessionStorage.removeItem('Author');
 
// 4、清除所有保存的数据
sessionStorage.clear();

复杂数据存储

上面都是对于简单的数据类型的存储，但当要存储的数据是一个对象或是数组的时候，直接存储是不行的,需要转化数据格式

！！注意：如果存进去的变量是个null，null也是一个对象哦，存进去以后会变成字符串null

存储数据前：利用JSON.stringify将对象转换成字符串

获取数据后：利用JSON.parse将字符串转换成对象

var user = {
    username: 'fengxin',
    password: '123456'
};
user = JSON.stringify(user);
sessionStorage.setItem('user', user);
 
var account = sessionStorage.getItem('user');
console.log(account);
 
account = JSON.parse(account)
console.log(account);

session

session是服务端存储的一个对象，主要用来存储所有访问过该服务端的客户端的用户信息（也可以存储其他信息），从而实现保持用户会话状态。但是服务器重启时，内存会被销毁，存储的用户信息也就消失了。
不同的用户访问服务端的时候会在session对象中存储键值对，“键”用来存储开启这个用户信息的“钥匙”，在登录成功后，“钥匙”通过cookie返回给客户端，客户端存储为sessionId记录在cookie中。当客户端再次访问时，会默认携带cookie中的sessionId来实现会话机制。
session是基于cookie的。

Cookie

cookie机制：如果不在浏览器中设置过期事件，cookie被保存在内存中，生命周期随浏览器的关闭而结束，这种cookie简称为会话cookie。如果在浏览器中设置了cookie的过期事件，cookie会被保存在硬盘中，关闭浏览器后，cookie数据仍然存在，直到过期事件结束才消失。cookie是服务端发给客户端的特殊信息，cookie是以文本的方式保存在客户端，每次请求时都带上它。

cookie的数据4k左右
cookie存储数据的格式：字符串key=value
cookie存储有效期：可以自行通过expires进行具体的日期设置，如果没设置，默认是关闭浏览器时失效。
cookie有效范围：当前域名下有效。所以session这种会话存储方式方式只适用于客户端代码和服务端代码运行在同一台服务器上（前后端项目协议、域名、端口号都一致，即在一个项目下）
session持久化
用于解决重启服务器后session就消失的问题。在数据库中存储session，而不是存储在内存中。通过包：express-mysql-session
其它
当客户端存储的cookie失效后，服务端的session不会立即销毁，会有一个延时，服务端会定期清理无效session，不会造成无效数据占用存储空间的问题。

Cookie 和 Session 的区别

• 安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
• 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
• 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
• 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源

token

基于Token的身份验证是无状态的，我们不将用户信息存在服务器或Session中。

这种概念解决了在服务端存储信息时的许多问题

NoSession意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。

基于Token的身份验证的过程如下:

1.用户通过用户名和密码发送请求。

2.程序验证。

3.程序返回一个签名的token 给客户端。

4.客户端储存token,并且每次用于每次发送请求。

5.服务端验证token并返回数据。

每一次请求都需要token。token应该在HTTP的头部发送从而保证了Http请求无状态。我们同样通过设置服务器属性Access-Control-Allow-Origin:* ，让服务器能接受到来自所有域的请求。需要主要的是，在ACAO头部标明(designating)*时，不得带有像HTTP认证，客户端SSL证书和cookies的证书。

token实现思路如下:

Tokens的优势

Acesss Token

无状态、可扩展

在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。

如果我们将已验证的用户的信息保存在Session中，则每次请求都需要用户向已验证的服务器发送验证信息(称为Session亲和性)。用户量大时，可能会造成一些拥堵。

但是不要着急。使用tokens之后这些问题都迎刃而解，因为tokens自己hold住了用户的验证信息。

每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里

基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库

token 完全由应用管理，所以它可以避开同源策略

安全性

请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，让我们少了对session操作。

token是有时效的，一段时间之后用户需要重新验证。我们也不一定需要等到token自动失效，token有撤回的操作，通过token revocataion可以使一个特定的token或是一组有相同认证的token无效。

可扩展性（）

Tokens能够创建与其它程序共享权限的程序。例如，能将一个随便的社交帐号和自己的大号(Fackbook或是Twitter)联系起来。当通过服务登录Twitter(我们将这个过程Buffer)时，我们可以将这些Buffer附到Twitter的数据流上(we are allowing Buffer to post to our Twitter stream)。

使用tokens时，可以提供可选的权限给第三方应用程序。当用户想让另一个应用程序访问它们的数据，我们可以通过建立自己的API，得出特殊权限的tokens。

多平台跨域

我们提前先来谈论一下CORS(跨域资源共享)，对应用程序和服务进行扩展的时候，需要介入各种各种的设备和应用程序。

Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.

只要用户有一个通过了验证的token，数据和资源就能够在任何域上被请求到。

token放在哪边比较好

1. token 其实就是访问资源的凭证，一般是用户通过用户名和密码登录成功之后，服务器将登录凭证做数字签名，加密之后得到的字符串作为token
2. token用在用户登录城后之后会返回给客户端，
3. token主要存储有:
3.1 存储在localStorage、sessionStorage中，每次调用接口的时候发送给服务端（每次调用接口放在HTTP请求头的Authorization字段里）
优点：可以跨域
缺点：没有任何安全防御，很容易受到xss攻击（简单理解在输入框输入js代码）导致token被盗取，因此要做好xss防御
3.2 存储在cookie中，可以自动发送给服务端
优点：可以指定httponly，来防止xss，也可以指定secure，来保证token只能在HTTPS下传输
缺点：不能跨域，而且不符合Restful最佳实践，易受CSRF攻击（简单来说攻击者盗用已经认证过的用户信息，以用户的名义进行一些操作（发邮件、转账等）CSRF不能拿到用户信息，他只是盗用用户的凭证去进行操作）。

Refresh Token

• 另外一种 token——refresh token
• refresh token 是专用于刷新 access token 的 token。如果没有 refresh token，也可以刷新 access token，但每次刷新都要用户输入登录用户名与密码，会很麻烦。有了 refresh token，可以减少这个麻烦，客户端直接用 refresh token 去更新 access token，无需用户进行额外的操作。

• Access Token 的有效期比较短，当 Acesss Token 由于过期而失效时，使用 Refresh Token 就可以获取到新的 Token，如果 Refresh Token 也失效了，用户就只能重新登录了。
• Refresh Token 及过期时间是存储在服务器的数据库中，只有在申请新的 Acesss Token 时才会验证，不会对业务接口响应时间造成影响，也不需要向 Session 一样一直保持在内存中以应对大量的请求。

token和session的区别

Session 是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。而 Token 是令牌，访问资源接口（API）时所需要的资源凭证。Token 使服务端无状态化，不会存储会话信息。

Session 和 Token 并不矛盾，作为身份认证 Token 安全性比 Session 好，因为每一个请求都有签名还能防止监听以及重放攻击，而 Session 就必须依赖链路层来保障通讯安全了。如果你需要实现有状态的会话，仍然可以增加 Session 来在服务器端保存一些状态。

所谓 Session 认证只是简单的把 User 信息存储到 Session 里，因为 SessionID 的不可预测性，暂且认为是安全的。而 Token ，如果指的是 OAuth Token 或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对 App 。其目的是让某 App 有权利访问某用户的信息。这里的 Token 是唯一的。不可以转移到其它 App上，也不可以转到其它用户上。Session 只提供一种简单的认证，即只要有此 SessionID ，即认为有此 User 的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方 App。所以简单来说：如果你的用户数据可能需要和第三方共享，或者允许第三方调用 API 接口，用 Token 。如果永远只是自己的网站，自己的 App，用什么就无所谓了。

实际开发中js-cookie的使用

js-cookie:js-cookie是一个简单的,轻量级的处理cookies的js API，用来处理cookie相关的插件

1.下载

npm install --save js-cookie

2.src/uitls中新建cookie.js文件夹并且引入

import Cookies from 'js-cookie'

const TokenKey = 'ADMIN_DESIGN_KEY'

export function getToken() {
  return Cookies.get(TokenKey)
}

export function setToken(token) {
	return Cookies.set(TokenKey, token, {
		expires: new Date(new Date().getTime() + 60 * 1000 * 60 )   //设置cookie有效期为1h，对应后端有效期
	})
}

export function removeToken() {
  return Cookies.remove(TokenKey)
}

用户登录以后保存获取得token

login(data)
            .then((res) => {
              setToken(res.token);
            })

然后在封装好的axios请求文件request.js中请求头带上token

 config.headers['Authorization'] = token

前后端鉴权的几种办法

Session-Cookie
Token 验证（包括 JWT，SSO）
OAuth2.0（开放授权）