1、cookie和session前端
cookie和session都是用来跟踪浏览器用户身份的会话方式。segmentfault
区别：后端
一、保持状态：cookie保存在浏览器端，session保存在服务器端浏览器
二、使用方式：缓存
（1）cookie机制：若是不在浏览器中设置过时时间，cookie被保存在内存中，生命周期随浏览器的关闭而结束，这种cookie简称会话cookie。若是在浏览器中设置了cookie的过时时间，cookie被保存在硬盘中，关闭浏览器后，cookie数据仍然存在，直到过时时间结束才消失。安全
Cookie是服务器发给客户端的特殊信息，cookie是以文本的方式保存在客户端，每次请求时都带上它服务器
（2）session机制：当服务器收到请求须要建立session对象时，首先会检查客户端请求中是否包含sessionid。若是有sessionid，服务器将根据该id返回对应session对象。若是客户端请求中没有sessionid，服务器会建立新的session对象，并把sessionid在本次响应中返回给客户端。一般使用cookie方式存储sessionid到客户端，在交互中浏览器按照规则将sessionid发送给服务器。若是用户禁用cookie，则要使用URL重写，能够经过response.encodeURL(url) 进行实现；API对encodeURL的结束为，当浏览器支持Cookie时，url不作任何处理；当浏览器不支持Cookie的时候，将会重写URL将SessionID拼接到访问地址后。cookie
三、存储内容：cookie只能保存字符串类型，以文本的方式；session经过相似与Hashtable的数据结构来保存，能支持任何类型的对象(session中可含有多个对象)网络
四、存储的大小：cookie：单个cookie保存的数据不能超过4kb；session大小没有限制。session
五、安全性：cookie：针对cookie所存在的攻击：Cookie欺骗，Cookie截获；session的安全性大于cookie。
缘由以下：（1）sessionID存储在cookie中，若要攻破session首先要攻破cookie；
（2）sessionID是要有人登陆，或者启动session_start才会有，因此攻破cookie也不必定能获得sessionID；
（3）第二次启动session_start后，前一次的sessionID就是失效了，session过时后，sessionID也随之失效。
（4）sessionID是加密的
（5）综上所述，攻击者必须在短期内攻破加密的sessionID，这很难。
六、应用场景：
cookie：（1）判断用户是否登录过网站，以便下次登陆时可以实现自动登陆（或者记住密码）。若是咱们删除cookie，则每次登陆必须重新填写登陆的相关信息。
（2）保存上次登陆的时间等信息。
（3）保存上次查看的页面
（4）浏览计数
session：Session用于保存每一个用户的专用信息，变量的值保存在服务器端，经过SessionID来区分不一样的客户。
（1）网上商城中的购物车
（2）保存用户登陆信息
（3）将某些数据放入session中，供同一用户的不一样页面使用
（4）防止用户非法登陆
七、缺点：cookie：（1）大小受限
（2）用户能够操做（禁用）cookie，使功能受限
（3）安全性较低
（4）有些状态不可能保存在客户端。
（5）每次访问都要传送cookie给服务器，浪费带宽。
（6）cookie数据有路径（path）的概念，能够限制cookie只属于某个路径下。
session：（1）Session保存的东西越多，就越占用服务器内存，对于用户在线人数较多的网站，服务器的内存压力会比较大。
（2）依赖于cookie（sessionID保存在cookie），若是禁用cookie，则要使用URL重写，不安全
（3）建立Session变量有很大的随意性，可随时调用，不须要开发者作精确地处理，因此，过分使用session变量将会致使代码不可读并且很差维护。
2、WebStorage
WebStorage的目的是克服由cookie所带来的一些限制，当数据须要被严格控制在客户端时，不须要持续的将数据发回服务器。
WebStorage两个主要目标：（1）提供一种在cookie以外存储会话数据的路径。（2）提供一种存储大量能够跨会话存在的数据的机制。
HTML5的WebStorage提供了两种API：localStorage（本地存储）和sessionStorage（会话存储）。
一、生命周期：localStorage:localStorage的生命周期是永久的，关闭页面或浏览器以后localStorage中的数据也不会消失。localStorage除非主动删除数据，不然数据永远不会消失。
sessionStorage的生命周期是在仅在当前会话下有效。sessionStorage引入了一个“浏览器窗口”的概念，sessionStorage是在同源的窗口中始终存在的数据。只要这个浏览器窗口没有关闭，即便刷新页面或者进入同源另外一个页面，数据依然存在。可是sessionStorage在关闭了浏览器窗口后就会被销毁。同时独立的打开同一个窗口同一个页面，sessionStorage也是不同的。
二、存储大小：localStorage和sessionStorage的存储数据大小通常都是：5MB
三、存储位置：localStorage和sessionStorage都保存在客户端，不与服务器进行交互通讯。
四、存储内容类型：localStorage和sessionStorage只能存储字符串类型，对于复杂的对象可使用ECMAScript提供的JSON对象的stringify和parse来处理
五、获取方式：localStorage：window.localStorage;；sessionStorage：window.sessionStorage;。
六、应用场景：localStoragese：经常使用于长期登陆（+判断用户是否已登陆），适合长期保存在本地的数据。sessionStorage：敏感帐号一次性登陆；
WebStorage的优势：
（1）存储空间更大：cookie为4KB，而WebStorage是5MB；
（2）节省网络流量：WebStorage不会传送到服务器，存储在本地的数据能够直接获取，也不会像cookie同样美词请求都会传送到服务器，因此减小了客户端和服务器端的交互，节省了网络流量；
（3）对于那种只须要在用户浏览一组页面期间保存而关闭浏览器后就能够丢弃的数据，sessionStorage会很是方便；
（4）快速显示：有的数据存储在WebStorage上，再加上浏览器自己的缓存。获取数据时能够从本地获取会比从服务器端获取快得多，因此速度更快；
（5）安全性：WebStorage不会随着HTTP header发送到服务器端，因此安全性相对于cookie来讲比较高一些，不会担忧截获，可是仍然存在伪造问题；
（6）WebStorage提供了一些方法，数据操做比cookie方便；
setItem (key, value) —— 保存数据，以键值对的方式储存信息。
getItem (key) —— 获取数据，将键值传入，便可获取到对应的value值。
removeItem (key) —— 删除单个数据，根据键值移除对应的信息。
clear () —— 删除全部的数据
key (index) —— 获取某个索引的key
https://segmentfault.com/q/1010000012617431-----登录信息用cookie好仍是localStorage好的鉴别
你的需求能够拆成两个部分：认证 和 鉴权
认证识别这个用户的身份
鉴权肯定这个用户访问首页以后是否须要跳转到绑定支付页面
cookie 天生就是最适合作认证，除了你提出的可否设置过时时间上的区别， cookie 和 localStorage 最大的区别是：每次 request 都会自动在 header 中带上全部的 cookie。因此若是你为了鉴权，设置不少 cookie ，还会引起一个问题就是，每次 request 的包都会很大。
个人解决方案很简单：鉴权就应该交给后端去作。不管你多么细心的在 client 中维护用户权限标识，都须要确保一点：用户的真实权限是否保持同步？因此你仍是须要向后端查询用户权限设置，干吗不简单些：
用户认证以后，后端鉴权，提示是否跳转，或者干脆在 header 头中设置跳转连接。
首先，是登陆信息：
登陆信息存在 cookie 中是一直以来的作法，并且实现的很好，不用考虑各类问题。
而 localStorage 是在这个 API 诞生以后，一些 JS 党带起来的另外一种实现方式。
使用 localStorage，你须要在每次请求的时候，都手动带上这个信息，这大大增长了开发过程当中带来的困难，很是麻烦，并且还要手动维护过时时间。
而使用 cookie 的话，只须要在后端的 Auth 模块放个设置 header 的代码便可，其余彻底不用考虑。为何：
- 用户未登陆的状况下，Auth 判断没有权限，设置个跳转到登陆页（或者是其余逻辑，好比以访客身份浏览之类的）
- 用户登陆时：将帐号和密码 POST 到 Auth 模块后，Auth 设置一个 header，设置 Cookie 及过时时间
- 用户登陆后，在 Cookie 的有效期内（设置了过时时间就是过时时间内，没设置就是浏览器关闭前），任何请求都会自动带上 cookie，彻底不用人工干预（fetch 请求除外，须要额外指定配置）
- 在用户自动带上 cookie 请求后，须要受权的请求必定会通过 Auth 模块，判断 cookie 是否有效（防止恶意无效的 cookie），若 cookie 无效，则
设置 header 删除 cookie（可选步骤），并将用户重定向到登陆页。若 cookie 有效，则设置 header，为 cookie 续期（cookie 内容均可以彻底不变）。
Auth 模块：
if (POST 方法请求登陆) {
if (帐号密码不正确) {
return 重定向到登陆页面，并提示错误
}
设置 cookie，并指定过时时间为当前时间 +n 天
return Auth 模块逻辑结束，进入其余模块逻辑
}
if (没有 cookie) {
return 重定向到登陆页面
}
if (cookie 无效) {
// 可选步骤：设置 cookie 过时时间为 -1 （删除 cookie）
return 重定向到登陆页面
}
// 带了有效的 cookie
设置 cookie 过时时间为当前时间 +n 天（为 cookie 续期）
return Auth 模块逻辑结束，进入其余模块逻辑
注意：只有请求 Auth 模块才会给 cookie 续期，其余模块不续。因此权限认证的模块都统一到一块儿了。
前端 js 什么都不用管，后端其余模块也什么都不用管。