shiro使用(使用token预热,为什么要使用token)

既然要做，就做的细致一点，对得起自己！

常见问题：1.是否思考过传统web项目是如何进行请求合法性的验证？请看第一部分

                  2.是否认真思考过token和Session相比真正的优势在哪里？请看简单总结

                 3.使用token的正确姿势是什么？请看问题思考

第一部分：传统web(前后端没有分离的时代)项目是如何保证服务器接收的请求都是合法的？(这里的合法请求是指服务器经过认证的)

常见场景：1.系统开发人员在编写代码过程中一点都没有做请求的校验，安全性为0！

                  2.系统开发人员统一使用Session进行请求的判断，即在登录认证成功之后，将用户信息存储在session中，凡是涉及到校验权限的请求，在相关代码里，都要从当前Session中提取信息，(如果你存储在session里，但是你又不在Session里控制，那意义何在？)成功则合法，没有则引导用户登录！

                  对于第2步来说，结合shiro使用之后，shiro会自动将用户信息存储在shiro的Session中，如下图，取出Session中信息则可以通过User user = (User) SecurityUtils.getSubject().getPrincipal()获取！

服务端使用Session的弊端以及为何要使用token的文章，请看这里，或者可以自行去各大技术论坛搜索相关文章即可。

简单总结一下网上的个人觉得靠谱的答案：

1.首先Session如果存储在服务器内存中,如果Session过多，势必会影响服务器性能。

2.Session如果存储在服务器内存中，在大型分布式中(服务器很多台的情况下)很难做到多个服务器之间Session共享，也不是有解决方案，具体可参考 深入分析JavaWeb技术内幕一书中关于Session的章节。

3.Session和对应的SessionId可以存储在数据库中(不要被网上有些文章误导了，说什么只能存在内存中)，虽然绝大多数情况下是存储在内存中。客户端拿着SessionId去服务器内存或者数据库中查找对应的Session。

4.token一般放在请求头中，在前后端分离的时代，服务器认证通过之后，会返回给客户端一个token，在vue项目中，将这个token设置在全局cookie中，每次请求通过interceptors.request.use这个拦截，动态地为每个请求带上刚刚那个token。

5.token和Session一样，都可以存储在数据库，都设置有过期时间。

6.在移动端，token的应用价值更高，因为移动端不支持Cookie。

问题思考：关于token的存储问题？

服务器如何校验请求中的token是否为登录认证的时返回给客户端的token？

1.将token值和创建时间和过期时间保存在数据库，每一次请求根据token去数据库里进行查询比对，来判断是否合法。但是这种方式和将Session存储在数据库里没啥区别啊，每次请求都要进行数据库的查询操作，当请求很多时，数据库压力也很大，同时还要定期删除过期的token，这么难受的，那为什么还要用你啊？

2.将token值和创建时间和过期时间保存redis中，这样可以保证请求多的时候，redis数据库可以很好的扛住压力，同时redis也提供了key的过期时间，解决了1中的两个问题，但是同样的解决方式也可以用在Session上啊，那为什么还要用你啊？(Session也不是没有分布式解决方案的，总不能为了用token而用toke吧，他的厉害之处在哪)

3.不存储token，无论在缓存中或者数据库中。toekn和session相比，最重要的优势应该在于减少服务器的压力，不论是内存压力还是数据库的压力。思路大致如下：用户登录认证通过之后---->返回给客户端的token应该是加密了的token，这个加密算法是关键，大致思路是这样的：要将用户的部分信息和请求的URL，时间戳融合在一起，返回给客户端。下次客户端请求时，会根据URL，时间戳，和部分用户信息重新生成一个token，将这个token和客户端请求中带的token比较，如果相同则这次请求合法。这样token不用占用存储空间，而且加解密的过程要比数据库查询快得多。具体也可以参考这篇文章。

综上所述，那么token的作用就很明显了。