A. 遭遇黑客，程序员，前端人员获取个人信息泄密问题你看该怎么解决
这是一个安全问题，大致需要解决的是前端可能导致的权限被拉取(cookie跨域访问等)，传输过程中的信息抓包(中间人攻击等)，以及后端数据库被拖库(服务器被黑)
首先前端不要用cookie进行权限的管理，使用token的方式，有条件设计单独的token服务器。非分布式的可以使用session。
其次数据的交互应该走https或一定的加密规则，保证数据传输过程的安全性。
前端开发者发送数据的时候，重要的数据一定得post不能使用get，还可以进行一定的数据加密和校验规则。
最后后端接收并保存到数据库，重要数据和隐私数据是必然需要加密存储的，这里涉及到权限问题，加密的隐私数据与规则应该尽量保证只有用户才能查看，保证拖库后也无法直接获取用户信息。加密规则加盐规则保密。
B. ID Token - JWT
我们来继续前两章（ OAuth2 总结 , 对OpenID Connect的理解 ）的讨论，进入对JWT的理解。先来简单回顾一下OAuth2和OpenID：
OpenID建立在OAuth之上，完成了认证和授权。而认证和授权的结果就体现在这个ID token之上，而这个ID token通常会是JWT。那么为什么会是JWT呢？我们通过以下几点来逐一解释。
JWT RFC 7519 给出了官方定义的一些字段：
当然也不限于此，可以根据自己的需要，添加其他字段。到此，我们可以看出JWT提供了ID token所需要的能力。一个完整的JTW是由三部分组成：Header，Payload，Signature。三者之间由 . 隔开，刚才提到的认证授权的字段就存在于Payload中。
Header中存放的是JTW的元数据，包含签名的算法以及token的类型，如下所示：
Signature部分是对前两部分的签名， 防止数据篡改 。首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。
算出签名以后，把 Header、Payload、Signature三个部分经过base64序列化为三个字符串，再讲三个字符串由 . 为间隔拼接成一个字符串返回给客户端。
ID Token需要有足够的安全性，JWT是如何做到的呢？
刚看到了签名部分，签名的作用只是为了防止数据篡改，而JWT默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。比如认证服务器中使用私钥进行加密，把公钥分发给其他应用服务器，应用服务拿到加密后的token后用公钥解密，获取到JWT，再用签名的秘钥来验证数据是否经过的篡改。
我们来看看还有神马其他备选么？Simple Web Tokens (SWT)和Security Assertion Markup Language Tokens (SAML)。
JWT vs SAML：JWT基于json，而SAML基于XML，在大小上就有足够的优势，更适用于HTML和HTTP。
JWT vs SWT：在安全性上，SWT只支持对称加密，而JWT和SAML支持公私钥的加密方式。
作为一个mobile developer，也想在这里对比一下原先的简单token模式和SSO中的JWT：
在没有该机制前，我们通常会使用一个随机产生的字符串作为token，认证成功后返回给前端，之后前端的每个请求带上这个token。若后台服务的是个单体应用没有什么问题，请求来了，验证一下token是否有效即可，但当认证服务和其他的应用服务是分离的，怎么做呢？应用服务受到请求，再向认证服务发起一个请求来验证验证token是否合法，是否有权限访问该应用服务。这样做到没有什么问题，只是当服务变多时，比如微服务下，势必会造成认证服务器的压力过大。
在使用该机制后，客户端通过认证服务登录，获得这个JWT，之后其他应用服务自身便可以验证这个token的是否有效，是否有权访问。
看似完美，但也有它自身的问题，我们来看一个场景：权限变更。某用户原先是一个超级管理员，可以访问所有服务，并可进行任意的删除，更改操作，他在这个状态下拿到了JWT。随后，由于权限更改为普通管理员，便不应该具有所有权限，但此时他开始时的JWT被缓存在客户端仍然可用，其他应用服务也并无法知道这个用户的权限已经被更改，后果可想而知了。解决的方式无非是将这个token的有效时间设置的短一些。
C. Token 原理解读
上一篇文章我们了解了一下 cookie 与 session 的产生、作用与原理。尽管二者在历史中已经服役过很长一段时间，但不论什么技术，都会有后来的优秀者取而代之。
前面说到，cookie 因为是保存在客户端，所以有安全隐患，因而诞生了 session，session 保存在服务器端，相对安全很多。但 session 每次都要为用户开辟一个空间用于其身份校验，且每次浏览器的请求过来服务器都要进行校验请求，十分耗费服务器的空间与性能。
于是，另一种身份校验工具诞生了，这就是 token。
本质上还是用户身份验证的工具。但与 cookie、session 明文似的形式不同，token 是经过一系列加密手段加密过的，最后表现为一串“无意义”的字符串。但里面包含了许多信息，可能包括用户登录的终端的地址、用户身份 ID、时间戳以及一个签名。所谓签名就是信息发送者给这段信息进行签名，让信息接收方知道请求 token 是属于谁。可以理解为在你的身份证上签名字，证件加笔迹双重认证。
为了避免上述 CSRF 攻击，浏览器对网页资源的访问提出了限制，URL 请求必须是与页面一样来自同一 协议 、 域名 、 端口 才给予访问权限。这样三者相同的站点被认为是有相同的“源”，是一个独立的“域”。即使 “localhost” 与 “ip” 都指向了本机，但也会被认为是非同源。浏览器在某个“域”下不会执行其他“域”的脚本。因而这也产生了前端领域里一个重要的话题：跨域。
session 的产生来自于用户登录后服务器生成的一个 session 对象，保存在服务器端，这个 session 只适用于该“域”。但实际情况是，一个网站的请求大多数情况下都会跨域，每台服务器的端口不同，甚至是域名就不同，每当跨域时就会形成新的会话，生成新的 session，这是非常影响用户体验的，所以也会有许多保存、共享或中央存储 session 的方案。
但上述两种限制在 token 这里就不再是问题。
与 cookie 类似。
首先，用户输入账号密码，发起登录请求，服务器校验账号密码合法性，成功则返回 token 给客户端。
客户端收到响应后拿到 token，将其通过 localStorage 等本地存储方式进行保存。
当浏览器再次请求时，需要在请求头中添加 token，这样服务器在接收到请求后便可以识别该请求的身份是否合法，合法则返回响应数据。
在实际应用中，配合 axios 的请求拦截器使用起来会很方便：
这样，就不用每次请求都手动添加 token，axios 会自动帮助我们完成添加，十分方便。
其实前端程序员对 token 的涉及没有多深，只需要在需要授权的请求中携带 token 即可。token 的生成、加密等都是后端去处理。所以，这里也就不在赘述 token 的加密原理，以笔者的能力也很难去讲述清楚。
token 运用也不是上文中描述的那么简单，涉及到一些过期处理、refresh 等操作。这些日后有机会再详谈。
D. JWT生成token及过期处理方案
## 业务场景
在前后分离场景下，越来越多的项目使用token作为接口的安全机制，APP端或者WEB端（使用VUE、REACTJS等构建）使用token与后端接口交互，以达到安全的目的。本文结合stackoverflow以及本身项目实践，试图总结出一个通用的，可落地的方案。
## 基本思路
- 单个token
1. token（A）过期设置为15分钟
2. 前端发起请求，后端验证token（A）是否过期；如果过期，前端发起刷新token请求，后端设置已再次授权标记为true，请求成功
3. 前端发起请求，后端验证再次授权标记，如果已经再次授权，则拒绝刷新token的请求，请求成功
4. 如果前端每隔72小时，必须重新登录，后端检查用户最后一次登录日期，如超过72小时，则拒绝刷新token的请求，请求失败
- 授权token加上刷新token
用户仅登录一次，用户改变密码，则废除token，重新登录
## 1.0实现
1.登录成功，返回access\_token和refresh\_token，客户端缓存此两种token;
2.使用access_token请求接口资源，成功则调用成功；如果token超时，客户端
携带refresh\_token调用中间件接口获取新的access\_token;
3.中间件接受刷新token的请求后，检查refresh_token是否过期。
如过期，拒绝刷新，客户端收到该状态后，跳转到登录页；
如未过期，生成新的access\_token和refresh\_token并返回给客户端（如有可能，让旧的refresh\_token失效），客户端携带新的access\_token重新调用上面的资源接口。
4.客户端退出登录或修改密码后，调用中间件注销旧的token(使access\_token和refresh\_token失效)，同时清空客户端的access\_token和refresh\_toke。
后端表
id user\_id client\_id client\_secret refresh\_token expire\_in create\_date del_flag
## 2.0实现
场景： access\_token访问资源 refresh\_token授权访问 设置固定时间X必须重新登录
1.登录成功，后台jwt生成access\_token（jwt有效期30分钟）和refresh\_token（jwt有效期15天），并缓存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都能删除)，返回后，客户端缓存此两种token;
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果token超时，中间件删除access\_token（废除）；客户端再次携带refresh\_token调用中间件接口获取新的access_token;
3.中间件接受刷新token的请求后，检查refresh_token是否过期。
如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页；
如未过期，检查缓存中是否有refresh\_token（是否被废除），如果有，则生成新的access\_token并返回给客户端，客户端接着携带新的access_token重新调用上面的资源接口。
4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access\_token和refresh\_token（废除）)，同时清空客户端侧的access\_token和refresh\_toke。
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：失效，长时间未登录，频繁刷新）
2.0 变动
1.登录
2.登录拦截器
3.增加刷新access_token接口
4.退出登录
5.修改密码
## 3.0实现
场景：自动续期 长时间未使用需重新登录
1.登录成功，后台jwt生成access\_token（jwt有效期30分钟），并缓存到redis（hash-key为access\_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token），设置access_token过期时间为7天，保证最终所有token都能删除)，返回后，客户端缓存此token;
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果token超时，中间件删除access\_token（废除）,同时生成新的access\_token并返回。客户端收到新的access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access\_token（废除）)，同时清空客户端侧的access\_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
3.0 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
1.3 场景：token过期重新登录 长时间未使用需重新登录
1.登录成功，后台jwt生成access\_token（jwt有效期7天），并缓存到redis，key为 "user\_id:access\_token",value为access\_token（根据用户id，可以人工废除指定用户全部token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此access_token；
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果token超时，中间件删除access\_token（废除）,同时生成新的access\_token并返回。客户端收到新的access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access\_token（废除）)，同时清空客户端侧的access\_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
1.3 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
# 解决方案
2.0 场景： access\_token访问资源 refresh\_token授权访问 设置固定时间X必须重新登录
1.登录成功，后台jwt生成access\_token（jwt有效期30分钟）和refresh\_token（jwt有效期15天），并缓
存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全
部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都
能删除)，返回后，客户端缓存此两种token;
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果
token超时，中间件删除access\_token（废除）；客户端再次携带refresh\_token调用中间件接口获取新的
access_token;
3.中间件接受刷新token的请求后，检查refresh_token是否过期。
如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页；
如未过期，检查缓存中是否有refresh\_token（是否被废除），如果有，则生成新的access\_token并返回给
客户端，客户端接着携带新的access_token重新调用上面的资源接口。
4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access\_token和refresh\_token（
废除）)，同时清空客户端侧的access\_token和refresh\_toke。
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（
拒绝的场景：失效，长时间未登录，频繁刷新）
2.0 变动
1.登录
2.登录拦截器
3.增加刷新access_token接口
4.退出登录
5.修改密码
3.0 场景：自动续期 长时间未使用需重新登录
1.登录成功，后台jwt生成access_token（jwt有效期30分钟），并缓存到redis（hash-key为
access_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以
根据sub-key,废除部分设备的token。），设置access_token过期时间为1个月，保证最终所有token都能删
除)，返回后，客户端缓存此token;
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果
token超时，中间件删除access\_token（废除）,同时生成新的access\_token并返回。客户端收到新的
access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清
空客户端侧的access_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长
时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
3.0 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
4.0 场景：token过期重新登录 长时间未使用需重新登录
1.登录成功，后台jwt生成access_token（jwt有效期7天），并缓存到redis，key为
"user\_id:access\_token" + 用户id,value为access_token（根据用户id，可以人工废除指定用户全部
token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此
access_token；
2.使用access\_token请求接口资源，校验成功且redis中存在该access\_token（未废除）则调用成功；如果
token超时，中间件删除access\_token（废除）,同时生成新的access\_token并返回。客户端收到新的
access_token，
再次请求接口资源。
3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清
空客户端侧的access_token。
4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长
时间未登录，频繁刷新）
5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。
4.0 变动
1.登录
2.登录拦截器
3.退出登录
4.修改密码
## 最终实现
### 后端
1. 在登录接口中 如果校验账号密码成功 则根据用户id和用户类型创建jwt token(有效期设置为-1，即永不过期),得到A
2. 更新登录日期(当前时间new Date()即可)（业务上可选），得到B
3. 在redis中缓存key为ACCESS_TOKEN:userId:A(加上A是为了防止用户多个客户端登录 造成token覆盖),value为B的毫秒数（转换成字符串类型），过期时间为7天（7 * 24 * 60 * 60）
4. 在登录结果中返回json格式为{"result":"success","token": A}
5. 用户在接口请求header中携带token进行登录，后端在所有接口前置拦截器进行拦截，作用是解析token 拿到userId和用户类型（用户调用业务接口只需要传token即可），
如果解析失败（抛出SignatureException），则返回json（code = 0 ,info= Token验证不通过, errorCode = '1001'）；
此外如果解析成功，验证redis中key为ACCESS_TOKEN:userId:A 是否存在 如果不存在 则返回json（code = 0 ,info= 会话过期请重新登录, errorCode = '1002'）；
如果缓存key存在，则自动续7天超时时间（value不变），实现频繁登录用户免登陆。
6. 把userId和用户类型放入request参数中 接口方法中可以直接拿到登录用户信息
7. 如果是修改密码或退出登录 则废除access_tokens（删除key）
### 前端（VUE）
1. 用户登录成功，则把username存入cookie中，key为loginUser;把token存入cookie中，key为accessToken
把token存入Vuex全局状态中
2. 进入首页
E. 前后端交互数据加解密
本文提供了一种前后端交互数据的加解密方法，主要涉及了AES和RSA两种加密方式。
AES加密是一种对称式加密，即加密和解密所需秘钥是相同的。后端生成一组秘钥，并利用该秘钥加密数据，然后发给前端，同时也需要把秘钥发送给前端，这样前端才能解密。这样就会有风险，一旦秘钥被泄露，你的加密将不存在任何意义。同时，相比RSA加密来说，好处是不会限制加密字符串的长度。
RSA加密，是一种非对称式加密，相比AES加密，这个就安全多了。后端生成一对秘钥，自己拿着私钥，公钥可以公开。这样前端拿公钥进行加密，后端拿私钥进行解密，私钥掌握在自己手里，被泄露的风险就小了很多。当然也有不好的地方，就是被加密字符串的长度不能过长，1024的秘钥只能加密117字节以内的明文，这就比较尴尬了，可能稍微长一点的数据就会超出了，当然可以通过2048或者4096的秘钥来延长加密长度，但总会被超出。所以适合需要加密长度不长的数据，最好是已知长度的数据，这样 就不会因长度问题报错。
RSA+AES混合加密，即后端通过RSA算法生成一对公私钥，并把公钥提供给前端。前端通过AES算法生成密钥，利用公钥进行加密并送给后端，后端根据私钥进行解密，得到与前端相同的AES密钥。然后，前后端就可以利用AES密钥对称加密进行数据交互。
详细步骤如图所示。
RSA+AES混合加密，结合了两种加密方式的优点。另外，前端每次启动都会随机生成AES密钥，后端增加token失效机制（前端设置了定时任务请求token），增加了前后端数据交互的安全性。
https://www.cnblogs.com/huanzi-qch/p/10913636.html
https://blog.csdn.net/weixin_38342534/article/details/94582656
F. token什么意思 前端如何使用token
大家好，从网上找了很多关于token的文章，都是提到要生成一个token，然后前端每次请求的时候，要使用这个token，请问下如何在前端使用生成的token？
前端能就使用jQuery搞定，还是需要其他的前端框架配合？能有这方面的完整示例吗？
做后端的，对前端的东西有些不太懂，请见谅
先谢谢大家了！！
解决方案1:
一般是后端有个结构给你拿token的，然后你请求的时候，根据约定
把token
放在header中
放uri参数中
放body表单里
给后端
解决方案2:
因为http协议是无状态的 token是后台给你发的一个唯一标识 你再去访问后台时带上这个token 后台就知道你是谁了
同session的作用
解决方案3:
前台生成的token，可能会存在安全性问题吧
解决方案4:
你做后台应该很了解token才对呀。
用户登录后，生成一个session_id，即token，可以存在redis里。然后前端或客户端保存起来，存cookie或者LS都行，然后所有的请求作为基类参数带上（也有通过cookie带的），然后server端再取到后，验证你是不是你。
解决方案5:
使用领域很多，以表单为例子：
后台生成token.
前端打印表单,并且讲该token变成隐藏项。<input type="hide" value="{{token}}">
客户提交表单。
后台验证提交的token合法性。
验证成功，处理表单。验证失败，返回错误处理页面。
解决方案6:
token一般都是后端生成的，在登陆之后返回，前端保存token，之后每次请求都带上token来验证身份。
解决方案7:
问题是前端生成的token给后台有用吗
解决方案8:
一般token都是服务器端生成，做csrf的。我在补充下我见过前端生成的栗子，虽然没啥卵用，但让我废了好大的劲才发现。
譬如你有一个验证码的表单，你在传递验证码的时候，新增一个隐藏域，将验证码用你本地的js加密后，作为参数传递，这样在服务器端可以检测验证码是不是被篡改过。
但这样没啥卵用，因为在提交的时候用同样的js模拟即可。
解决方案9:
大多数情况下，token作为一种令牌，都是在服务器端生成，生成的方法很多，从简单点的对时间或者id或者两个混合起来进行哈希运算的值到自己设计更复杂的算法都可以，生成的目的是为了给前端下一次通信时使用这个token作为令牌，当作为一个请求资源的许可的标识，而服务器则会视这个token在一段时间内都是有效的，并且还可以额外看情况加上是否是同一个ip之类的其它的限制，从而防止某种资源被非法访问
偶有前端（包括本地客户端或者app）生成token的情况是已经约定好了一个好的加密机制，服务器可以信任客户端的这个输入的情况下可以由前端或者客户端生成
G. jwt的token怎么生存的
引入依赖包加密解密方法。
在生产环境中，一般jwt会保存用户的名字和角色权限等信息。可以将token写到cookie里，每次前端访问后台时，可以在拦截器或者过滤器取到token，然后解密，先判断是否过期，过期就抛异常阻止其访问。然后取出信息保存到threadLocal里，方便以后调用这些信息，当后台访问完成后，从thredLocal删除此用户信息。
服务器认证以后，生成一个JSON格式的对象返回给客户端。之后客户端与服务端通信的时候，都要发回这个JSON对象。服务器完全根据这个对象认证用户身份。
H. 登录时对于token的处理
在前后端完全分离的情况下，Vue项目中实现token验证大致思路如下：
1、用户输入账号密码，前端调后端的登陆接口，发送用户名和密码，
2、后端收到请求，验证用户名和密码，验证通过后（即登录成功），后端返回token给前端；
3、前端拿到token，将token存储到localStorage和vuex中，并跳转路由页面；
4、前端每次跳转路由，都要判断 localStroage 中有无 token ，没有就跳转到登录页面，有则跳转到对应路由页面（ 通过router.beforeEach((to, from, next)=>{.....}）)
5、每次调后端接口，都要在请求头中加上token；
6、后端判断请求头中有无token，有token，就拿到token并验证token，验证成功就返回数据，验证失败（例如：token过期）就返回编码401（编码由前台和后台约定好），请求头中没有token也返回编码401；
7、如果前端拿到状态码为401，则清除token信息并跳转到登录页面，并弹框提示用户当前缺少token或者token已失效，请重新登录；
一、调登录接口成功，在回调函数中将token存储到localStorage和vuex中
login.vue
store文件夹下的index.js
二、路由导航守卫
main.js
三、请求头加token，如果前端拿到状态码为401，就清除token信息并跳转到登录页面
I. vue项目实现用户登录 以及携带token
<article class="_2rhmJa">
调取登录接口 （首先明确一下要做到事情）
在前后端完全分离的情况下，Vue项目中实现token验证大致思路如下：
1、第一次登录的时候，前端调后端的登陆接口，发送用户名和密码
2、后端收到请求，验证用户名和密码，验证成功，就给前端返回一个token
3、前端拿到token，将token存储到localStorage和vuex中，并跳转路由页面
4、前端每次跳转路由，就判断 localStroage 中有无 token ，没有就跳转到登录页面，有则跳转到对应路由页面
5、每次调后端接口，都要在请求头中加token
6、后端判断请求头中有无token，有token，就拿到token并验证token，验证成功就返回数据，验证失败（例如：token过期）就返回401，请求头中没有token也返回401
7、如果前端拿到状态码为401，就清除token信息并跳转到登录页面
调取登录接口成功，会在回调函数中将token存储到localStorage和vuex中
1.<template>
<div>
</div>
</template>
export default {
data () {
},
methods: {
/////判读账号密码是否输入，没有则alert 出来
}
};
在store文件夹下的index.js 添加 token
import Vue from 'vue';
import Vuex from 'vuex';
Vue.use(Vuex);
const store = new Vuex.Store({
state: {
},
mutations: {
}
});
export default store;
二，配置 路由导航守卫
router文件夹下的index.js
import Vue from 'vue';
import Router from 'vue-router';
import login from '@/components/login';
import home from '@/components/home';
Vue.use(Router);
const router = new Router({
routes: [
]
});
// 导航守卫
// 使用 router.beforeEach 注册一个全局前置守卫，判断用户是否登陆
router.beforeEach((to, from, next) => {
if (to.path === '/login') {
} else {
}
});
export default router;
三、请求头加token 在 main.js中添加
// 添加请求拦截器，在请求头中加token
axios.interceptors.request.use(
config => {
},
error => {
});
token的过期可以自定义
四、如果前端拿到状态码为401，就清除token信息并跳转到登录页面
localStorage.removeItem('Authorization');
this.$router.push('/login');
</article>
66人点赞
前段学习
J. token 加密解密
.
.
(三种不同的信息)
第一部分：红色 令牌Header--头部包含所使用的签名算法和令牌的类型
{ "alg": "HS256", "typ": "JWT"} 经过Base64Url 编码以后，结果大致如：
第二部分：绿色 载荷payload--数据实体
{
data: { username: 'abc', password: '111111' },
exp: 1591933872,
iat: 1591930272
}
注：atob：ASCII-to-Binary 解密-返回一个正常字符串；
btoa：Binary-to-ASCII 加密-返回一个 Base64 表示的字符串
第三部分：蓝色 签名Signature--是对前两部分的防篡改签名。将Header和Payload用Base64URL编码后，再用点(.)连接起来。然后使用签名算法和密钥对这个字符串进行签名。
signature = hmac_sha256(base64encode(header) + '.' + base64encode(payload), 'MY_SUPER_SECRET_KEY')
注：这个密钥（MY_SUPER_SECRET_KEY）只有服务器才知道，不能泄露给用户。