㈠ 使用SpringSecurity验证token
我们从AuthenticationManager接口的实现类作为入口启动认证，那么就要在SecurityConfig配置类中去写个@Bean注解，这样我们才能自动注入。
service层
定义一个UserDetailsService接口的实现类，重写loadUserByUsername方法（service层的AuthenticationManager类做校验时会自动调用该方法），那么它的返回是UserDetails接口的实现类，所以我们再写个LoginUser作为实现类
好，到这边准备工作做完了，我们再回过头看service层。根据userId生成token，然后把用户信息存入redis，而前端ajax请求的结果里则包含了token值。
接下来定义token验证过滤器，这样子的话，如果前端发的请求是需要验证身份的，那就会走这个过滤器的校验流程。
最后，附上springsecurity的配置类
㈡ 什么是token验证
Token是在客户端频繁向服务端请求数据，服务端频繁的去数据库查询用户名和密码并进行对比，判断用户名和密码正确与否，并作出相应提示，在这样的背景下，Token便应运而生。Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。
(2)前端权限验证token具体方法扩展阅读：
token其实说的更通俗点可以叫暗号，在一些数据传输之前，要先进行暗号的核对，不同的暗号被授权不同的数据操作。例如在USB1.1协议中定义了4类数据包：token包、data包、handshake包和special包。主机和USB设备之间连续数据的交换可以分为三个阶段，第一个阶段由主机发送token包，不同的token包内容不一样（暗号不一样）可以告诉设备做不同的工作，第二个阶段发送data包，第三个阶段由设备返回一个handshake包。
㈢ 鉴权操作流程（前端逻辑）
1.用户登录 调取接口 去获取对应的token，此时将token 存储在了sessionStorage中。项目的最开始是去获取当前用户的token。（base64加密），之后调用token有效时间和校验token是否失效。
2.公共请求方法 request 函数在请求头添加 token，即每次的相关请求都带有了当前用户的token信息，如果token在有效期内则可以正常请求。否则便会抛出异常。
3.假如token的有效时间是3600s，但是用户很久没有操作系统，会启动用户锁定状态，通过监控用户的操作时间差来判断锁定的状态。正常情况下token是不会过期的，因为在token的过期前几分钟内会进行token的更新操作，理论上token是不会过期的。所以当用户重新操作系统的时候，超过了一定时间之后需要用户重新登录系统来，其实也是调取的token的接口，去获取新的token，并替换之前的token。（但是这里没有考虑到的一种情况是如果项目一直在启动，但是服务重启了，或者其他原因导致前端的token在验证的时候不通过，这样就会导致页面的锁定状态无法打开，这时候前端做的处理是重新跳转到登录页，并删除token，就像第一次登录系统一样。）
㈣ 服务端如何校验token的是否正确
服务端第一次返回登录请求token的时候,服务端是校验了用户,并绑定了用户关系,之后才返回了这个token,也就说,服务端保存了token和登录用户账户的对应关系,不管之后的token怎么变,都是服务器校验上一次的token,并返回新的token,token和用户账户的对应关系一直在服务端更新并维护,对于客户端来讲,无需判断token是谁,服务器下发什么,就返回什么,检验是服务端处理
㈤ Vue前端用户权限控制大全
用户权限是对特定资源的访问许可，所谓权限控制，也就是确保用户只能访问到被分配的资源
接口权限目前一般采用通用的形式来验证(用户是否登录系统)，没有的话一般返回401，跳转到登录页面重新进行登录 ,
登录成功后拿到token，将token存起来，通过axios请求拦截器进行拦截，每次请求的时候头部携带token
通过自定义指令进行按钮权限的判断
自定义权限指令
在使用的按钮中只需要引用v-has指令
全局路由守卫里做判断
每次路由跳转的时候都要判断权限，这里的判断也很简单，因为菜单的name与路由的name是一一对应的，而后端返回的菜单就已经是经过权限过滤的
如果根据路由name找不到对应的菜单，就表示用户有没权限访问
如果路由很多，可以在应用初始化的时候，只挂载不需要权限控制的路由。取得后端返回的菜单后，根据菜单与路由的对应关系，筛选出可访问的路由，通过addRoutes动态挂载
这种方式的缺点：
菜单需要与路由做一一对应，前端添加了新功能，需要通过菜单管理功能添加新的菜单，如果菜单配置的不对会导致应用不能正常使用
全局路由守卫里，每次路由跳转都要做判断
㈥ 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的情况是已经约定好了一个好的加密机制，服务器可以信任客户端的这个输入的情况下可以由前端或者客户端生成
㈦ 前后端分离项目——登录Token校验思路
对token的校验分为前端和后端
前端： Vue-Cli 2.x + axios
后端：SpringBoot 2.3.4
这里的话，userToken和userId放到sessionStorage是关键步骤
后端主要是使用拦截器来进行请求的拦截和校验
解释一下思路：
这里的话，针对需要拦截的路径和需要放行的路径进行配置就行
关于redisTemple的引入这里就不再赘述。
到这里为止，前后端的token就都做完了，后面就再讲讲前端的一些其他思路吧
对于登录状态的判断，前端可以在router.foreach上对路由进行状态判定，从而实现页面程度的拦截（具体可以参考最后的参考文章2）
在使用拦截器后，会发现前端部分请求会无法正常到达后端，网络后发现是因为 axios发送正式请求前会先发送一个嗅探请求 ，而嗅探请求是不携带我们封装的header的，所以会导致部分请求会无法成功，解决的方式有很多种，这里的话是选择了在后端去直接处理
参考文章
1、SpringBoot加了拦截器后出现的跨域问题解析
https://blog.csdn.net/mrkorbin/article/details/104066979
2、Vue项目中实现用户登录及token验证
https://www.cnblogs.com/web-record/p/9876916.html
㈧ 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. 进入首页
㈨ Vue项目中用户登录及token验证及流程图
在前后端完全分离的情况下，Vue项目中实现token验证大致思路如下：
简单举例说明：
① 调登录接口成功，在回调函数中将token存储到localStorage和vuex中（login.vue中）
② store文件夹下的index.js
③ 路由守卫（router文件夹下的index.js）
④ 请求头加token
⑤ 如果前端拿到状态码为401，就清除token信息并跳转到登录页面
流程图：