更多demo请关注
springboot demo实战项目
java 脑洞
java 面试宝典
开源工具
1.Shiro + JsessionID
这种就是最早的基于session的权限认证框架，在服务器登录认证成功后，服务器会把用户信息存放在session中并把对应的sessionID返回给客户端，客户端下次访问时带上sessionID，服务器端根据sessionID获取对应的session，从session中获取到对应的用户信息，假如sessionID未能找到对应的session或者访问没有带上sessionID，则认为未登录
缺点：
请求校验依赖session， 而session通常存放在服务器的内存中，不适用于分布式，也就是没法实现多点登录， 因为换一个服务器就没了session
2.Shiro + JsessionID + redis
这种是为了解决上面方案的缺点而提出的用redis来解决分布式下session共享问题的，说白了就是服务器的session不存放在内存中，而是通过redis的api将session提交到redis中存储，多台服务器访问同一个redis，那同一个sessionID在不同的服务器上就能获取相同的session了，进而实现了多点登录
缺点：
1.sessionID的安全性不足，容易被挟持
2.用户信息存放在服务器端，每次访问校验都依赖服务器的读取能力
3.Shiro + token + redis
这种是为了解决上面方案sessionID的安全性不足的确定，提出用token来代替jessionID作为前后端校验的凭证，token是根据sessionID生成，通过token能获取对应的sessionID，而sessionID则能获取到session， sessionID不变的情况下，我们可以根据sessionID生成不同的token，然后通过定时刷新token来避免挟持，而且token的传输可以通过header 等方式来支持手机端访问
缺点：
用户信息存放在服务器端，每次访问校验都依赖服务器的读取能力
4.Shiro + jwt
JWT的提出实现了请求无状态，坦白说就是用户信息不存放在服务器中，而是把用户信息通过加密的方式存放到token中，客户端每次访问带上token，服务器端校验token并解密获得用户信息，由于用户信息不在服务器上，服务器只做校验，进而提高了服务器效率，也由于服务器端没有保留用户信息，天然支持了了分布式
缺点：
- 由于token是客户端持有，也就是发放出去的token，服务器端无法主动发起回收，所以jwt的有效时间应该设置为较短的时间
- jwt 是无需session实现的，所以需要关闭shiro的session支持，导致shiro实现jwt校验的复杂性较大
5. jwt + 轻量级校验框架 + redis
大家看到这里可能有点蒙，为什么用了jwt来做无状态请求，还要引入redis ? 首先我们来看下我们要解决的问题
- jwt 持有用户信息，服务器端无法收回jwt，造成风险不可控
- shiro对jwt支持的复杂性
所以我们提出使用拦截器校验jwt的方式来实现轻量级校验框架，jwt持有用户信息而不持有权限信息，权限信息交由redis储存，
也就是我们把用户操作级别，比如添加商品到购物车，收藏商品等等这种交由jwt校验，而权限级别操作，比如登记商户，上下架商品等交由服务器端来校验权限
缺点：
- 需要明确的业务隔离
- 对静态资源拦截不友好
#公众号
五分钟了解前沿技术，大数据，微服务，区域链，提供java前沿技术干货，独立游戏制作技术分享
如果这篇文章对你有帮助请给个star
