用shiro、redis做登录权限处理

前言 最近，需要用shiro做一套登录，机缘巧合看到了张开涛大佬的跟我学shiro

本文也是在此基础上完成的，点击上方链接可以到网盘上下载pdf

尽管有文档参考，但还是遇到了很多坑，所以在快要完成的时候写个blog总结回顾，等不忙的时候我会整理一份demo发到GitHub或者gitee上

先简单看下shiro，下面这些在很多地方都能看到列在这，是为了留给之前没看过的或（懒得找的—不是个好习惯）

Shiro 的 API 感觉还是不错清晰明了，其基本功能点如下图所示：

Authentication：身份认证 / 登录，验证用户是不是拥有相应的身份；
Authorization：授权，即权限验证，验证某个已认证的用户是否拥有某个权限；即判断用户是否能做事情，常见的如：验证某个用户是否拥有某个角色。或者细粒度的验证某个用户对某个资源是否具有某个权限；
Shiro 是不会去管角色和权限的；这些需要我们自己去设计 / 提供；然后通过相应的接口注入给 Shiro 即可。

Session Manager：会话管理，即用户登录后就是一次会话，在没有退出之前，它的所有信息都在会话中；会话可以是普通 JavaSE 环境的，也可以是如 Web 环境的；
Cryptography：加密，保护数据的安全性，如密码加密存储到数据库，而不是明文存储；
Web Support：Web 支持，可以非常容易的集成到 Web 环境；
Caching：缓存，比如用户登录后，其用户信息、拥有的角色 / 权限不必每次去查，这样可以提高效率；
Concurrency：shiro 支持多线程应用的并发验证，即如在一个线程中开启另一个线程，能把权限自动传播过去；
Testing：提供测试支持；
Run As：允许一个用户假装为另一个用户（如果他们允许）的身份进行访问；
Remember Me：记住我，这个是非常常见的功能，即一次登录后，下次再来的话不用登录了。
从应用程序的角度来看

Subject：主体，代表了当前 “用户”，这个用户不一定是一个具体的人，与当前应用交互的任何东西都是 Subject，如网络爬虫，机器人等；即一个抽象概念；所有 Subject 都绑定到 SecurityManager，与 Subject 的所有交互都会委托给 SecurityManager；可以把 Subject 认为是一个门面；SecurityManager 才是实际的执行者；
SecurityManager：安全管理器；即所有与安全有关的操作都会与 SecurityManager 交互；且它管理着所有 Subject；可以看出它是 Shiro 的核心，它负责与后边介绍的其他组件进行交互，如果学习过 SpringMVC，你可以把它看成 DispatcherServlet 前端控制器；
Realm：域，Shiro 从从 Realm 获取安全数据（如用户、角色、权限），就是说 SecurityManager 要验证用户身份，那么它需要从 Realm 获取相应的用户进行比较以确定用户身份是否合法；也需要从 Realm 得到用户相应的角色 / 权限进行验证用户是否能进行操作；可以把 Realm 看成 DataSource，即安全数据源。
也就是说对于我们而言，最简单的一个 Shiro 应用：
应用代码通过 Subject 来进行认证和授权，而 Subject 又委托给 SecurityManager；
我们需要给 Shiro 的 SecurityManager 注入 Realm，从而让 SecurityManager 能得到合法的用户及其权限进行判断。
从以上也可以看出，Shiro 不提供维护用户 / 权限，而是通过 Realm 让开发人员自己注入。
从 Shiro 内部来看下 Shiro 的架构，如下图所示：

Subject：主体，可以看到主体可以是任何可以与应用交互的 “用户”；
SecurityManager：相当于 SpringMVC 中的 DispatcherServlet 或者 Struts2 中的 FilterDispatcher；是 Shiro 的心脏；所有具体的交互都通过 SecurityManager 进行控制；它管理着所有 Subject、且负责进行认证和授权、及会话、缓存的管理。
Authenticator：认证器，负责主体认证的，这是一个扩展点，如果用户觉得 Shiro 默认的不好，可以自定义实现；其需要认证策略（Authentication Strategy），即什么情况下算用户认证通过了；
Authrizer：授权器，或者访问控制器，用来决定主体是否有权限进行相应的操作；即控制着用户能访问应用中的哪些功能；
Realm：可以有 1 个或多个 Realm，可以认为是安全实体数据源，即用于获取安全实体的；可以是 JDBC 实现，也可以是 LDAP 实现，或者内存实现等等；由用户提供；注意：Shiro 不知道你的用户 / 权限存储在哪及以何种格式存储；所以我们一般在应用中都需要实现自己的 Realm；
SessionManager：如果写过 Servlet 就应该知道 Session 的概念，Session 呢需要有人去管理它的生命周期，这个组件就是 SessionManager；而 Shiro 并不仅仅可以用在 Web 环境，也可以用在如普通的 JavaSE 环境、EJB 等环境；所有呢，Shiro 就抽象了一个自己的 Session 来管理主体与应用之间交互的数据；这样的话，比如我们在 Web 环境用，刚开始是一台 Web 服务器；接着又上了台 EJB 服务器；这时想把两台服务器的会话数据放到一个地方，这个时候就可以实现自己的分布式会话（如把数据放到 Memcached 服务器）；
SessionDAO：DAO 大家都用过，数据访问对象，用于会话的 CRUD，比如我们想把 Session 保存到数据库，那么可以实现自己的 SessionDAO，通过如 JDBC 写到数据库；比如想把 Session 放到 Memcached 中，可以实现自己的 Memcached SessionDAO；另外 SessionDAO 中可以使用 Cache 进行缓存，以提高性能；
CacheManager：缓存控制器，来管理如用户、角色、权限等的缓存的；因为这些数据基本上很少去改变，放到缓存中后可以提高访问的性能
Cryptography：密码模块，Shiro 提高了一些常见的加密组件用于如密码加密 / 解密的。

看完上面的是不有点感觉了，下面是我的实例
大致介绍下我的环境：
编辑器：idea
jdk：1.8
集成：gitlab
打包：gradle （看到大多数都是maven，这点很难受）
主要的有：springboot 、shiro、redis、mysql

FIRST

配置这个身份验证即UserRealm，通过账号和密码来认证这个人的身份
在这里重写了两个方法，一个登陆、一个授权，如下图：

先说这个登陆
如下登录流程图：

1. 首先调用 Subject.login(token) 进行登录，其会自动委托给 Security Manager，调用之前必须通过 SecurityUtils.setSecurityManager() 设置；
2. SecurityManager 负责真正的身份验证逻辑；它会委托给 Authenticator 进行身份验证；
3. Authenticator 才是真正的身份验证者，Shiro API 中核心的身份认证入口点，此处可以自定义插入自己的实现；
4. Authenticator 可能会委托给相应的 AuthenticationStrategy 进行多 Realm 身份验证，默认 ModularRealmAuthenticator 会调用 AuthenticationStrategy 进行多 Realm 身份验证；
5. Authenticator 会把相应的 token 传入 Realm，从 Realm 获取身份验证信息，如果没有返回 / 抛出异常表示身份验证失败了。此处可以配置多个 Realm，将按照相应的顺序及策略进行访问。

在执行subject.login(usernamePasswordToken);方法时会到这个重写的doGetAuthenticationInfo中执行这个登录校验；
String username = authenticationToken.getPrincipal().toString();
String password = new String((char[]) authenticationToken.getCredentials());
在shiro里principals、credentials就是账号密码；去数据库查下密码MD5加密

如果身份验证失败请捕获 AuthenticationException 或其子类，常见的如： DisabledAccountException（禁用的帐号）、LockedAccountException（锁定的帐号）、UnknownAccountException（错误的帐号）、ExcessiveAttemptsException（登录失败次数过多）、IncorrectCredentialsException （错误的凭证）、ExpiredCredentialsException（过期的凭证）等

授权的话
先看看流程图：

如果没有涉及到权限的控制那就直接返回null就可以（那我这肯定不能直接返回空啊，要挨k的）
这个里面其实也没什么东西，之前有提到过shiro是不管角色和权限的，这个角色和权限需要自行设计，这里的实现只是去mysql查一下交个shiro而已。如下图：
登录时subject.login()时调用，而授权呢就是通过以下方式触发的：

1. 权限注解
2. shirFilter
   注解的如下：
   @RequiresAuthentication
   表示当前 Subject 已经通过 login 进行了身份验证；即 Subject.isAuthenticated() 返回 true。 @RequiresUser
   表示当前 Subject 已经身份验证或者通过记住我登录的。
   @RequiresGuest
   表示当前 Subject 没有身份验证或通过记住我登录过，即是游客身份。
   @RequiresRoles(value={“admin”,“user”}, logical= Logical.AND)
   表示当前 Subject 需要角色 admin 和 user。
   @RequiresPermissions (value={“user:a”, “user:b”}, logical= Logical.OR)
   表示当前 Subject 需要权限 user：a 或 user：b。
   filter根据路径如下：
   访问/user/delete需要delete权限,在自定义Realm中为用户授权。
   filterMap.put("/user/delete", “perms[“user:delete”]”);
   但是，这两种都是硬编码，这个不符合最初搞这个登录的可配置想法。这里留个todo！！！

Shiro 的会话管理

shiro 提供了完整的企业级会话管理功能，不依赖于底层容器（如 web 容器 tomcat），提供了会话管理、会话事件监听、会话存储 / 持久化、容器无关的集群、失效 / 过期支持、对 Web 的透明支持、SSO 单点登录的支持等特性。也就是说直接使用 Shiro 的会话管理可以直接替换如 Web 容器的会话管理。

Subject subject = SecurityUtils.getSubject();
Session session = subject.getSession();//获取会话
String sessionId = session.getId().toString();
session.getId();
获取当前会话的唯一标识。
session.getHost();
获取当前 Subject 的主机地址，该地址是通过 HostAuthenticationToken.getHost() 提供的。
session.getTimeout();
session.setTimeout(毫秒); 
获取 / 设置当前 Session 的过期时间；如果不设置默认是会话管理器的全局过期时间。  
session.getStartTimestamp();
session.getLastAccessTime();
获取会话的启动时间及最后访问时间
session.touch();
session.stop(); 
更新会话最后访问时间及销毁会话；当 Subject.logout() 时会自动调用 stop 方法来销毁会话。
session.setAttribute("key", "123");
Assert.assertEquals("123", session.getAttribute("key"));
session.removeAttribute("key");
设置 / 获取 / 删除会话属性；在整个会话范围内都可以对这些属性进行操作
在Web 环境的 WebSessionManager 又提供了如下接口：  
boolean isServletContainerSessions();// 是否使用 Servlet 容器的会话
Shiro 还提供了 ValidatingSessionManager 用于验资并过期会话：  
void validateSessions();// 验证所有会话是否过期

Shiro 提供了三个默认实现：

1. DefaultSessionManager：DefaultSecurityManager 使用的默认实现
2. ServletContainerSessionManager：DefaultWebSecurityManager 使用的默认实现，用于 Web 环境–>servelet容器
3. DefaultWebSessionManager用于 Web 环境的实现，可以替代 ServletContainerSessionManager，自己维护会话（咱们在这里才用的就是这个）
   如下图：
   

其中： globalSessionTimeout 将应用给所有 Session。可以单独设置每个 Session 的 timeout 属性来为每个 Session 设置其超时时间,（毫秒为单位），默认 30 分钟。
这个是在config包下配置的ShiroConfig，详细描述下面再说。
Cookie信息
sessionIdCookie 是 sessionManager 创建会话 Cookie 的模板：
sessionIdCookie.name：设置 Cookie 名字，默认为 JSESSIONID； （伏笔）
sessionIdCookie.domain：设置 Cookie 的域名，默认空，即当前访问的域名；
sessionIdCookie.path：设置 Cookie 的路径，默认空，即存储在域名根下；
sessionIdCookie.maxAge：设置 Cookie 的过期时间，秒为单位，默认 - 1 表示关闭浏览器时过期 Cookie；
sessionIdCookie.httpOnly：如果设置为 true，则客户端不会暴露给客户端脚本代码，使用 HttpOnly cookie 有助于减少某些类型的跨站点脚本攻击；此特性需要实现了 Servlet 2.5 MR6 及以上版本的规范的 Servlet 容器支持；
sessionManager.sessionIdCookieEnabled：是否启用 / 禁用 Session Id Cookie，默认是启用的；如果禁用后将不会设置 Session Id Cookie，即默认使用了 Servlet 容器的 JSESSIONID，且通过 URL 重写（URL 中的 “;JSESSIONID=id” 部分）保存 Session Id。

重写session listener

session存储和持久化

Shiro 提供 SessionDAO 用于会话的 CRUD，即 DAO（Data Access Object）模式实现

ID；主要此处返回的ID.equals(session.getId())；
Serializable create(Session session);
//根据会话ID获取会话
Session readSession(Serializable sessionId) throws UnknownSessionException;
//更新会话；如更新会话最后访问时间/停止会话/设置超时时间/设置移除属性等会调用
void update(Session session) throws UnknownSessionException;
//删除会话；当会话过期/会话停止（如用户退出时）会调用
void delete(Session session);
//获取当前所有活跃用户，如果用户量多此方法影响性能
Collection<Session> getActiveSessions();

这里涉及到AbstractSessionDAO的实现，它提供了 SessionDAO 的基础实现，如生成会话 ID 等；CachingSessionDAO 提供了对开发者透明的会话缓存的功能，只需要设置相应的 CacheManager 即可；MemorySessionDAO 直接在内存中进行会话维护；而 EnterpriseCacheSessionDAO 提供了缓存功能的会话维护，默认情况下使用 MapCache 实现，内部使用 ConcurrentHashMap 保存缓存的会话。

这里咱们使用redis存储，如下图把session序列化存入redis

如果在会话过期时不想删除过期的会话可以：
sessionManager.setDeleteInvalidSessions(false);
如果是在获取会话时验证了会话已过期，将抛出 InvalidSessionException，可以拦截此异常，告知前端，跳到登录页。

shiro的RememberMe

1. 首先在登录页面选中 RememberMe 然后登录成功
   如果是浏览器登录，一般会把 RememberMe 的 Cookie 写到客户端并保存下来；
2. 关闭浏览器再重新打开；会发现浏览器还是记住你的；
3. 访问一般的网页服务器端还是知道你是谁，且能正常访问；
4. 但是，进行关键操作如进行支付时，此时还是需要再进行身份认证的，以确保当前用户还是 你。