其实我不仅会 Spring Security，Shiro 也略懂一二！

和大家分享一个松哥原创的 Shiro 教程吧，还没写完，先整一部分，剩下的敬请期待。

1.Shiro简介

Apache Shiro是一个开源安全框架，提供身份验证、授权、密码学和会话管理。Shiro框架具有直观、易用等特性，同时也能提供健壮的安全性，虽然它的功能不如SpringSecurity那么强大，但是在普通的项目中也够用了。

1.1 由来

Shiro的前身是JSecurity，2004年，Les Hazlewood和Jeremy Haile创办了Jsecurity。当时他们找不到适用于应用程序级别的合适Java安全框架，同时又对JAAS非常失望。2004年到2008年期间，JSecurity托管在SourceForge上，贡献者包括Peter Ledbrook、Alan Ditzel和Tim Veil。2008年，JSecurity项目贡献给了Apache软件基金会（ASF），并被接纳成为Apache Incubator项目，由导师管理，目标是成为一个顶级Apache项目。期间，Jsecurity曾短暂更名为Ki，随后因商标问题被社区更名为“Shiro”。随后项目持续在Apache Incubator中孵化，并增加了贡献者Kalle Korhonen。2010年7月，Shiro社区发布了1.0版，随后社区创建了其项目管理委员会，并选举Les Hazlewood为主席。2010年9月22日，Shrio成为Apache软件基金会的顶级项目（TLP）。

1.2 有哪些功能

Apache Shiro是一个强大而灵活的开源安全框架，它干净利落地处理身份认证，授权，企业会话管理和加密。Apache Shiro的首要目标是易于使用和理解。安全有时候是很复杂的，甚至是痛苦的，但它没有必要这样。框架应该尽可能掩盖复杂的地方，露出一个干净而直观的API，来简化开发人员在应用程序安全上所花费的时间。

以下是你可以用Apache Shiro 所做的事情：

1. 验证用户来核实他们的身份

2. 对用户执行访问控制，如：判断用户是否被分配了一个确定的安全角色；判断用户是否被允许做某事

3. 在任何环境下使用Session API，即使没有Web容器

4. 在身份验证，访问控制期间或在会话的生命周期，对事件作出反应

5. 聚集一个或多个用户安全数据的数据源，并作为一个单一的复合用户“视图”

6. 单点登录（SSO）功能

7. 为没有关联到登录的用户启用"Remember Me"服务

   等等

Apache Shiro是一个拥有许多功能的综合性的程序安全框架。下面的图表展示了Shiro的重点：

Shiro中有四大基石——身份验证，授权，会话管理和加密。

1. Authentication：有时也简称为“登录”，这是一个证明用户是谁的行为。
2. Authorization：访问控制的过程，也就是决定“谁”去访问“什么”。
3. Session Management：管理用户特定的会话，即使在非Web 或EJB 应用程序。
4. Cryptography：通过使用加密算法保持数据安全同时易于使用。

除此之外，Shiro也提供了额外的功能来解决在不同环境下所面临的安全问题，尤其是以下这些：

1. Web Support：Shiro的web支持的API能够轻松地帮助保护Web应用程序。
2. Caching：缓存是Apache Shiro中的第一层公民，来确保安全操作快速而又高效。
3. Concurrency：Apache Shiro利用它的并发特性来支持多线程应用程序。
4. Testing：测试支持的存在来帮助你编写单元测试和集成测试。
5. “Run As”：一个允许用户假设为另一个用户身份（如果允许）的功能，有时候在管理脚本很有用。
6. “Remember Me”：在会话中记住用户的身份，这样用户只需要在强制登录时候登录。

2.从一个简单的案例开始身份认证

2.1 shiro下载

要学习shiro，我们首先需求去shiro官网下载shiro，官网地址地址https://shiro.apache.org/，截至本文写作时，shiro的最新稳定版本为1.7.1（Shiro 在 2017-2019 曾经停更了两年，我一度以为以为这个项目 gg 了），本文将采用这个版本。当然，shiro我们也可以从github上下载到源码。两个源码下载地址如下：

1.[apache shiro] shiro.apache.org/download.html#latest
2.[github-shiro] github.com/apache/shiro/archive/master.zip

上面我主要是和小伙伴们介绍下源码的下载，并没有涉及到jar包的下载，jar包我们到时候直接使用maven即可。

2.2 创建演示工程

这里我们先不急着写代码，我们先打开刚刚下载到的源码，源码中有一个samples目录，如下：

这个samples目录是官方给我们的一些演示案例，其中有一个quickstart项目，这个项目是一个maven项目，参考这个quickstart，我们来创建一个自己的演示工程。

1.首先使用maven创建一个JavaSE工程
工程创建成功后在pom文件中添加如下依赖：

<dependency>
	<groupId>org.apache.shiro</groupId>
	<artifactId>shiro-all</artifactId>
	<version>RELEASE</version>
</dependency>

2.配置用户

参考quickstart项目中的shiro.ini文件，我们来配置一个用户，配置方式如下：首先在resources目录下创建一个shiro.ini文件，文件内容如下：

[users]
sang=123,admin
[roles]
admin=*

以上配置表示我们创建了一个名为sang的用户，该用户的密码是123，该用户的角色是admin，而admin具有操作所有资源的权限。

3.执行登录

OK，做完上面几步之后，我们就可以来看看如何实现一次简单的登录操作了。这个登录操作我们依然是参考quickstart项目中的类来实现，首先我们要通过shiro.ini创建一个SecurityManager，再将这个SecurityManager设置为单例模式，如下：

Factory<org.apache.shiro.mgt.SecurityManager> factory = new IniSecurityManagerFactory("classpath:shiro.ini");
org.apache.shiro.mgt.SecurityManager securityManager = factory.getInstance();
SecurityUtils.setSecurityManager(securityManager);

如此之后，我们就配置好了一个基本的Shiro环境，注意此时的用户和角色信息我们配置在shiro.ini这个配置文件中，接下来我们就可以获取一个Subject了，这个Subject就是我们当前的用户对象，获取方式如下：

Subject currentUser = SecurityUtils.getSubject();

拿到这个用户对象之后，接下来我们可以获取一个session了，这个session和我们web中的HttpSession的操作基本上是一致的，不同的是，这个session不依赖任何容器，可以随时随地获取，获取和操作方式如下：

//获取session
Session session = currentUser.getSession();
//给session设置属性值
session.setAttribute("someKey", "aValue");
//获取session中的属性值
String value = (String) session.getAttribute("someKey");

说了这么多，我们的用户到现在还没有登录呢，Subject中有一个isAuthenticated方法用来判断当前用户是否已经登录，如果isAuthenticated方法返回一个false，则表示当前用户未登录，那我们就可以执行登陆，登录方式如下：

if (!currentUser.isAuthenticated()) {
    UsernamePasswordToken token = new UsernamePasswordToken("sang", "123");
    try {
        currentUser.login(token);
    } catch (UnknownAccountException uae) {
        log.info("There is no user with username of " + token.getPrincipal());
    } catch (IncorrectCredentialsException ice) {
        log.info("Password for account " + token.getPrincipal() + " was incorrect!");
    } catch (LockedAccountException lae) {
        log.info("The account for username " + token.getPrincipal() + " is locked.  " +
                "Please contact your administrator to unlock it.");
    }
    catch (AuthenticationException ae) {
    }
}

首先构造UsernamePasswordToken，两个参数就是我们的用户名和密码，然后调用Subject中的login方法执行登录，当用户名输错，密码输错、或者账户锁定等问题出现时，系统会通过抛异常告知调用者这些问题。

当登录成功之后，我们可以通过如下方式获取当前登陆用户的用户名：

log.info("User [" + currentUser.getPrincipal() + "] logged in successfully.");

我们也可以通过调用Subject中的hasRole和isPermitted方法来判断当前用户是否具备某种角色或者某种权限，如下：

if (currentUser.hasRole("admin")) {
    log.info("May the Schwartz be with you!");
} else {
    log.info("Hello, mere mortal.");
}
if (currentUser.isPermitted("lightsaber:wield")) {
    log.info("You may use a lightsaber ring.  Use it wisely.");
} else {
    log.info("Sorry, lightsaber rings are for schwartz masters only.");
}

最后，我们可以通过logout方法注销本次登录，如下：

currentUser.logout();

OK，至此，我们通过官方案例给小伙伴们简单介绍了Shiro中的登录操作，完整案例大家可以参考官方的demo。

3. 聊一聊Shiro中的Realm

3.1 登录流程是什么样的

首先我们来看shiro官方文档中这样一张登录流程图：

参照此图，我们的登录一共要经过如下几个步骤：

1. 应用程序代码调用Subject.login方法，传递创建好的包含终端用户的Principals(身份)和Credentials(凭证)的AuthenticationToken实例(即上文例子中的UsernamePasswordToken)。
2. Subject实例，通常是DelegatingSubject（或子类）委托应用程序的SecurityManager通过调用securityManager.login(token)开始真正的验证工作(在DelegatingSubject类的login方法中打断点即可看到)。
3. SubjectManager作为一个基本的“保护伞”的组成部分，接收token以及简单地委托给内部的Authenticator实例通过调用authenticator.authenticate(token)。这通常是一个ModularRealmAuthenticator实例，支持在身份验证中协调一个或多个Realm实例。ModularRealmAuthenticator本质上为Apache Shiro 提供了PAM-style 范式（其中在PAM 术语中每个Realm 都是一个’module’）。
4. 如果应用程序中配置了一个以上的Realm，ModularRealmAuthenticator实例将利用配置好的AuthenticationStrategy来启动Multi-Realm认证尝试。在Realms 被身份验证调用之前，期间和以后，AuthenticationStrategy被调用使其能够对每个Realm的结果作出反应。如果只有一个单一的Realm 被配置，它将被直接调用，因为没有必要为一个单一Realm的应用使用AuthenticationStrategy。
5. 每个配置的Realm用来帮助看它是否支持提交的AuthenticationToken。如果支持，那么支持Realm的getAuthenticationInfo方法将会伴随着提交的token被调用。

OK，通过上面的介绍，相信小伙伴们对整个登录流程都有一定的理解了，小伙伴可以通过打断点来验证我们上文所说的五个步骤。那么在上面的五个步骤中，小伙伴们看到了有一个Realm承担了很重要的一部分工作，那么这个Realm到底是个什么东西，接下来我们就来仔细看一看。

3.2 什么是Realm

根据Realm文档上的解释，Realms担当Shiro和你的应用程序的安全数据之间的“桥梁”或“连接器”。当它实际上与安全相关的数据如用来执行身份验证（登录）及授权（访问控制）的用户帐户交互时，Shiro从一个或多个为应用程序配置的Realm 中寻找许多这样的东西。在这个意义上说，Realm 本质上是一个特定安全的DAO：它封装了数据源的连接详细信息，使Shiro 所需的相关的数据可用。当配置Shiro 时，你必须指定至少一个Realm 用来进行身份验证和/或授权。SecurityManager可能配置多个Realms，但至少有一个是必须的。Shiro 提供了立即可用的Realms 来连接一些安全数据源（即目录），如LDAP，关系数据库（JDBC），文本配置源，像INI 及属性文件，以及更多。你可以插入你自己的Realm 实现来代表自定义的数据源，如果默认地Realm不符合你的需求。

看了上面这一段解释，可能还有小伙伴云里雾里，那么接下来我们来通过一个简单的案例来看看Realm到底扮演了一个什么样的作用，注意，本文的案例在上文案例的基础上完成。首先自定义一个MyRealm，内容如下：

public class MyRealm implements Realm {
    public String getName() {
        return "MyRealm";
    }
    public boolean supports(AuthenticationToken token) {
        return token instanceof UsernamePasswordToken;
    }
    public AuthenticationInfo getAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
        String password = new String(((char[]) token.getCredentials()));
        String username = token.getPrincipal().toString();
        if (!"sang".equals(username)) {
            throw new UnknownAccountException("用户不存在");
        }
        if (!"123".equals(password)) {
            throw new IncorrectCredentialsException("密码不正确");
        }
        return new SimpleAuthenticationInfo(username, password, getName());
    }
}

自定义Realm实现Realm接口，该接口中有三个方法，第一个getName方法用来获取当前Realm的名字，第二个supports方法用来判断这个realm所支持的token，这里我假设值只支持UsernamePasswordToken类型的token，第三个getAuthenticationInfo方法则进行了登陆逻辑判断，从token中取出用户的用户名密码等，进行判断，当然，我这里省略掉了数据库操作，当登录验证出现问题时，抛异常即可，这里抛出的异常，将在执行登录那里捕获到（注意，由于我这里定义的MyRealm是实现了Realm接口，所以这里的用户名和密码都需要我手动判断是否正确，后面的文章我会介绍其他写法）。

OK，创建好了MyRealm之后还不够，我们还需要做一个简单配置，让MyRealm生效，将shiro.ini文件中的所有东西都注释掉，添加如下两行：

MyRealm= org.sang.MyRealm
securityManager.realms=$MyRealm

第一行表示定义了一个realm，第二行将这个定义好的交给securityManger，这里实际上会调用到RealmSecurityManager类的setRealms方法。OK，做好这些之后，小伙伴们可以在MyRealm类中的一些关键节点打上断点，再次执行main方法，看看整个的登录流程。

4. 再来聊一聊Shiro中的Realm

4.1 Realm的继承关系

通过查看类的继承关系，我们发现Realm的子类实际上有很多种，这里我们就来看看有代表性的几种：

1. IniRealm

可能我们并不知道，实际上这个类在我们第二篇文章中就已经用过了。这个类一开始就有如下两行定义：

public static final String USERS_SECTION_NAME = "users";
public static final String ROLES_SECTION_NAME = "roles";

这两行配置表示shiro.ini文件中，[users]下面的表示表用户名密码还有角色，[roles]下面的则是角色和权限的对应关系。

2. PropertiesRealm

PropertiesRealm则规定了另外一种用户、角色定义方式，如下：

user.user1=password,role1
role.role1=permission1

3. JdbcRealm

这个顾名思义，就是从数据库中查询用户的角色、权限等信息。打开JdbcRealm类，我们看到源码中有如下几行：

protected static final String DEFAULT_AUTHENTICATION_QUERY = "select password from users where username = ?";
protected static final String DEFAULT_SALTED_AUTHENTICATION_QUERY = "select password, password_salt from users where username = ?";
protected static final String DEFAULT_USER_ROLES_QUERY = "select role_name from user_roles where username = ?";
protected static final String DEFAULT_PERMISSIONS_QUERY = "select permission from roles_permissions where role_name = ?";

根据这几行预设的SQL我们就可以大致推断出数据库中表的名称以及字段了，当然，我们也可以自定义SQL。JdbcRealm实际上是AuthenticatingRealm的子类，关于AuthenticatingRealm我们在后面还会详细说到，这里先不展开。接下来我们就来详细说说这个JdbcRealm。

4.2 JdbcRealm

1. 准备工作

使用JdbcRealm，涉及到数据库操作，要用到数据库连接池，这里我使用Druid数据库连接池，因此首先添加如下依赖：

<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>druid</artifactId>
    <version>RELEASE</version>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>5.1.27</version>
</dependency>

2. 数据库创建

想要使用JdbcRealm，那我首先要创建数据库，根据JdbcRealm中预设的SQL，我定义的数据库表结构如下：

这里为了大家能够直观的看到表的关系，我使用了外键，实际工作中，视情况而定。然后向表中添加几条测试数据。数据库脚本小伙伴可以在github上下载到（github.com/lenve/shiroSamples/blob/v4/shiroDemo.sql）。

3. 配置文件处理

然后将shiro.ini中的所有配置注释掉，添加如下配置：

jdbcRealm=org.apache.shiro.realm.jdbc.JdbcRealm
dataSource=com.alibaba.druid.pool.DruidDataSource
dataSource.driverClassName=com.mysql.jdbc.Driver
dataSource.url=jdbc:mysql://localhost:3306/shiroDemo
dataSource.username=root
dataSource.password=123
jdbcRealm.dataSource=$dataSource
jdbcRealm.permissionsLookupEnabled=true
securityManager.realms=$jdbcRealm

这里的配置文件都很简单，不做过多赘述，小伙伴唯一需要注意的是permissionsLookupEnabled需要设置为true，否则一会JdbcRealm就不会去查询权限用户权限。

4. 测试

OK，做完上面几步就可以测试了，测试方式和第二篇文章中一样，我们可以测试下用户登录，用户角色和用户权限。

5. 自定义查询SQL

小伙伴们看懂了上文，对于自定义查询SQL就没什么问题了。我这里举一个简单的例子，比如我要自定义authenticationQuery对对应的SQL，查看JdbcRealm源码，我们发现authenticationQuery对应的SQL本来是select password from users where username = ?，如果需要修改的话，比如说我的表名不是users而是employee，那么在shiro.ini中添加如下配置即可：

jdbcRealm.authenticationQuery=select password from employee where username = ?

OK,这个小伙伴下来自己做尝试，我这里就不演示了。

5. Shiro中多Realm的认证策略问题

5.1 多Realm认证策略

不知道小伙伴们是否还记得这张登录流程图：

从这张图中我们可以清晰看到Realm是可以有多个的，不过到目前为止，我们所有的案例都还是单Realm，那么我们先来看一个简单的多Realm情况。

前面的文章我们自己创建了一个MyRealm，也用过JdbcRealm，但都是单独使用的，现在我想将两个一起使用，只需要修改shiro.ini配置即可，如下：

MyRealm= org.sang.MyRealm

jdbcRealm=org.apache.shiro.realm.jdbc.JdbcRealm
dataSource=com.alibaba.druid.pool.DruidDataSource
dataSource.driverClassName=com.mysql.jdbc.Driver
dataSource.url=jdbc:mysql://localhost:3306/shiroDemo
dataSource.username=root
dataSource.password=123
jdbcRealm.dataSource=$dataSource
jdbcRealm.permissionsLookupEnabled=true
securityManager.realms=$jdbcRealm,$MyRealm

但是此时我数据库中用户的信息是sang/123,MyRealm中配置的信息也是sang/123，我把MyRealm中的用户信息修改为江南一点雨/456，此时，我的MyRealm的getAuthenticationInfo方法如下：

public AuthenticationInfo getAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
    String password = new String(((char[]) token.getCredentials()));
    String username = token.getPrincipal().toString();
    if (!"江南一点雨".equals(username)) {
        throw new UnknownAccountException("用户不存在");
    }
    if (!"456".equals(password)) {
        throw new IncorrectCredentialsException("密码不正确");
    }
    return new SimpleAuthenticationInfo(username, password, getName());
}

这个时候我们就配置了两个Realm，还是使用我们一开始的测试代码进行登录测试，这个时候我们发现我既可以使用江南一点雨/456进行登录，也可以使用sang/123进行登录，用sang/123登录成功之后用户的角色信息和之前是一样的，而用江南一点雨/456登录成功之后用户没有角色，这个也很好理解，因为我们在MyRealm中没有给用户配置任何权限。总而言之，就是当我有了两个Realm之后，现在只需要这两个Realm中的任意一个认证成功，就算我当前用户认证成功。

5.2 原理追踪

好了，有了上面的问题后，接下来我们在Subject的login方法上打断点，跟随程序的执行步骤，我们来到了ModularRealmAuthenticator类的doMultiRealmAuthentication方法中，如下：

protected AuthenticationInfo doAuthenticate(AuthenticationToken authenticationToken) throws AuthenticationException {
    this.assertRealmsConfigured();
    Collection<Realm> realms = this.getRealms();
    return realms.size() == 1?this.doSingleRealmAuthentication((Realm)realms.iterator().next(), authenticationToken):this.doMultiRealmAuthentication(realms, authenticationToken);
}

在这个方法中，首先会获取当前一共有多少个realm，如果只有一个则执行doSingleRealmAuthentication方法进行处理，如果有多个realm，则执行doMultiRealmAuthentication方法进行处理。doSingleRealmAuthentication方法部分源码如下：

protected AuthenticationInfo doSingleRealmAuthentication(Realm realm, AuthenticationToken token) {
    ...
    ...
    AuthenticationInfo info = realm.getAuthenticationInfo(token);
    if(info == null) {
        String msg = "Realm [" + realm + "] was unable to find account data for the submitted AuthenticationToken [" + token + "].";
        throw new UnknownAccountException(msg);
    } else {
        return info;
    }
}

小伙伴们看到这里就明白了，这里调用了realm的getAuthenticationInfo方法，这个方法实际上就是我们自己实现的MyRealm中的getAuthenticationInfo方法。

那如果有多个Realm呢？我们来看看doMultiRealmAuthentication方法的实现，部分源码如下：

protected AuthenticationInfo doMultiRealmAuthentication(Collection<Realm> realms, AuthenticationToken token) {
    AuthenticationStrategy strategy = this.getAuthenticationStrategy();
    AuthenticationInfo aggregate = strategy.beforeAllAttempts(realms, token);
    Iterator var5 = realms.iterator();
    while(var5.hasNext()) {
        Realm realm = (Realm)var5.next();
        aggregate = strategy.beforeAttempt(realm, token, aggregate);
        if(realm.supports(token)) {
            AuthenticationInfo info = null;
            Throwable t = null;
            try {
                info = realm.getAuthenticationInfo(token);
            } catch (Throwable var11) {
            }
            aggregate = strategy.afterAttempt(realm, token, info, aggregate, t);
        } else {
            log.debug("Realm [{}] does not support token {}.  Skipping realm.", realm, token);
        }
    }
    aggregate = strategy.afterAllAttempts(token, aggregate);
    return aggregate;
}

我这里主要来说下这个方法的实现思路：

1. 首先获取多Realm认证策略

2. 构建一个AuthenticationInfo用来存放一会认证成功之后返回的信息

3. 遍历Realm，调用每个Realm中的getAuthenticationInfo方法，看是否能够认证成功

4. 每次获取到AuthenticationInfo之后，都调用afterAttempt方法进行结果合并

5. 遍历完所有的Realm之后，调用afterAllAttempts进行结果合并，这里主要判断下是否一个都没匹配上

5.3 自由配置认证策略

OK，经过上面的简单解析，小伙伴们对认证策略应该有一个大致的认识了，那么在Shiro中，一共支持三种不同的认证策略，如下：

1. AllSuccessfulStrategy，这个表示所有的Realm都认证成功才算认证成功

2. AtLeastOneSuccessfulStrategy，这个表示只要有一个Realm认证成功就算认证成功，默认即此策略

3. FirstSuccessfulStrategy，这个表示只要第一个Realm认证成功，就算认证成功

配置方式也很简单，在shiro.ini中进行配置，在上面配置的基础上，增加如下配置：

authenticator=org.apache.shiro.authc.pam.ModularRealmAuthenticator
securityManager.authenticator=$authenticator
allSuccessfulStrategy=org.apache.shiro.authc.pam.AllSuccessfulStrategy
securityManager.authenticator.authenticationStrategy=$allSuccessfulStrategy

此时，我们再进行登录测试，则会要求每个Realm都认证通过才算认证通过。

6. Shiro中密码加密

6.1 密码为什么要加密

2011年12月21日，有人在网络上公开了一个包含600万个CSDN用户资料的数据库，数据全部为明文储存，包含用户名、密码以及注册邮箱。事件发生后CSDN在微博、官方网站等渠道发出了声明，解释说此数据库系2009年备份所用，因不明原因泄露，已经向警方报案。后又在官网网站发出了公开道歉信。在接下来的十多天里，金山、网易、京东、当当、新浪等多家公司被卷入到这次事件中。整个事件中最触目惊心的莫过于CSDN把用户密码明文存储，由于很多用户是多个网站共用一个密码，因此一个网站密码泄露就会造成很大的安全隐患。由于有了这么多前车之鉴，我们现在做系统时，密码都要加密处理。

密码加密我们一般会用到散列函数，又称散列算法、哈希函数，是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来。该函数将数据打乱混合，重新创建一个叫做散列值的指纹。散列值通常用一个短的随机字母和数字组成的字符串来代表。好的散列函数在输入域中很少出现散列冲突。在散列表和数据处理中，不抑制冲突来区别数据，会使得数据库记录更难找到。我们常用的散列函数有如下几种：

1. MD5消息摘要算法

MD5消息摘要算法是一种被广泛使用的密码散列函数，可以产生出一个128位（16字节）的散列值，用于确保信息传输完整一致。MD5由美国密码学家罗纳德·李维斯特设计，于1992年公开，用以取代MD4算法。这套算法的程序在 RFC 1321中被加以规范。将数据（如一段文字）运算变为另一固定长度值，是散列算法的基础原理。1996年后被证实存在弱点，可以被加以破解，对于需要高度安全性的数据，专家一般建议改用其他算法，如SHA-2。2004年，证实MD5算法无法防止碰撞，因此不适用于安全性认证，如SSL公开密钥认证或是数字签名等用途。

2. 安全散列算法

安全散列算法（Secure Hash Algorithm）是一个密码散列函数家族，是FIPS所认证的安全散列算法。能计算出一个数字消息所对应到的，长度固定的字符串（又称消息摘要）的算法。且若输入的消息不同，它们对应到不同字符串的机率很高。SHA家族的算法，由美国国家安全局所设计，并由美国国家标准与技术研究院发布，是美国的政府标准，其分别是：SHA-0：1993年发布，是SHA-1的前身；SHA-1：1995年发布，SHA-1在许多安全协议中广为使用，包括TLS和SSL、PGP、SSH、S/MIME和IPsec，曾被视为是MD5的后继者。但SHA-1的安全性在2000年以后已经不被大多数的加密场景所接受。2017年荷兰密码学研究小组CWI和Google正式宣布攻破了SHA-1；SHA-2：2001年发布，包括SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。虽然至今尚未出现对SHA-2有效的攻击，它的算法跟SHA-1基本上仍然相似；因此有些人开始发展其他替代的散列算法；SHA-3：2015年正式发布，SHA-3并不是要取代SHA-2，因为SHA-2目前并没有出现明显的弱点。由于对MD5出现成功的破解，以及对SHA-0和SHA-1出现理论上破解的方法，NIST感觉需要一个与之前算法不同的，可替换的加密散列算法，也就是现在的SHA-3。

6.2 Shiro中如何加密

Shiro中对以上两种散列算法都提供了支持，对于MD5，Shiro中生成消息摘要的方式如下：

Md5Hash md5Hash = new Md5Hash("123", null, 1024);

第一个参数是要生成密码的明文，第二个参数密码的盐值，第三个参数是生成消息摘要的迭代次数。

Shiro中对于安全散列算法的支持如下(支持多种算法，这里我举一个例子)：

Sha512Hash sha512Hash = new Sha512Hash("123", null, 1024);

这里三个参数含义与上文基本一致，不再赘述。shiro中也提供了通用的算法，如下：

SimpleHash md5 = new SimpleHash("md5", "123", null, 1024);
SimpleHash sha512 = new SimpleHash("sha-512", "123", null, 1024);

当用户注册时，我们可以通过上面的方式对密码进行加密，将加密后的字符串存入数据库中。我这里为了简单，就不写注册功能了，就把昨天数据库中用户的密码123改成sha512所对应的字符串，如下：

cb5143cfcf5791478e057be9689d2360005b3aac951f947af1e6e71e3661bf95a7d14183dadfb0967bd6338eb4eb2689e9c227761e1640e6a033b8725fabc783

同时，为了避免其他Realm的干扰，数据库中我只配置一个JdbcRealm。

此时如果我不做其他修改的话，登录必然会失败，原因很简单：我登录时输入的密码是123，但是数据库中的密码是一个很长的字符串，所以登录肯定不会成功。通过打断点，我们发现最终的密码比对是在SimpleCredentialsMatcher类中的doCredentialsMatch方法中进行密码比对的，比对的方式也很简单，直接使用了对用户输入的密码和数据库中的密码生成byte数组然后进行比较，最终的比较在MessageDigest类的isEqual方法中。部分逻辑如下：

protected boolean equals(Object tokenCredentials, Object accountCredentials) {
        ...
        ...
        //获取用户输入密码的byte数组
        byte[] tokenBytes = this.toBytes(tokenCredentials);
        //获取数据库中密码的byte数组
        byte[] accountBytes = this.toBytes(accountCredentials);
        return MessageDigest.isEqual(tokenBytes, accountBytes);
        ...
}

MessageDigest的isEqual方法如下：

public static boolean isEqual(byte[] digesta, byte[] digestb) {
    if (digesta == digestb) return true;
    if (digesta == null || digestb == null) {
        return false;
    }
    if (digesta.length != digestb.length) {
        return false;
    }

    int result = 0;
    // time-constant comparison
    for (int i = 0; i < digesta.length; i++) {
        result |= digesta[i] ^ digestb[i];
    }
    return result == 0;
}

都是很容易理解的比较代码，这里不赘述。我们现在之所以登录失败是因为没有对用户输入的密码进行加密，通过对源代码的分析，我们发现是因为在AuthenticatingRealm类的assertCredentialsMatch方法中获取了一个名为SimpleCredentialsMatcher的密码比对器，这个密码比对器中比对的方法就是简单的比较，因此如果我们能够将这个密码比对器换掉就好了。我们来看一下CredentialsMatcher的继承关系：

我们发现这个刚好有一个Sha512CredentialsMatcher比对器，这个比对器的doCredentialsMatch方法在它的父类HashedCredentialsMatcher，方法内容如下：

public boolean doCredentialsMatch(AuthenticationToken token, AuthenticationInfo info) {
    Object tokenHashedCredentials = hashProvidedCredentials(token, info);
    Object accountCredentials = getCredentials(info);
    return equals(tokenHashedCredentials, accountCredentials);
}

这时我们发现获取tokenHashedCredentials的方式不像以前那样简单粗暴了，而是调用了hashProvidedCredentials方法，而hashProvidedCredentials方法最终会来到下面这个重载方法中：

protected Hash hashProvidedCredentials(Object credentials, Object salt, int hashIterations) {
    String hashAlgorithmName = assertHashAlgorithmName();
    return new SimpleHash(hashAlgorithmName, credentials, salt, hashIterations);
}

这几行代码似曾相识，很明显，是系统帮我们对用户输入的密码进行了转换。了解了这些之后，那我只需要将shiro.ini修改成如下样子即可实现登录了：

sha512=org.apache.shiro.authc.credential.Sha512CredentialsMatcher
# 迭代次数
sha512.hashIterations=1024
jdbcRealm=org.apache.shiro.realm.jdbc.JdbcRealm
dataSource=com.alibaba.druid.pool.DruidDataSource
dataSource.driverClassName=com.mysql.jdbc.Driver
dataSource.url=jdbc:mysql://localhost:3306/shiroDemo
dataSource.username=root
dataSource.password=123
jdbcRealm.dataSource=$dataSource
jdbcRealm.permissionsLookupEnabled=true
# 修改JdbcRealm中的credentialsMatcher属性
jdbcRealm.credentialsMatcher=$sha512
securityManager.realms=$jdbcRealm

如此之后，我们再进行登录测试，就可以登录成功了。

本小节案例下载：github.com/lenve/shiroSamples/archive/refs/tags/v6.zip

7. Shiro中密码加盐

7.1 密码为什么要加盐

不管是消息摘要算法还是安全散列算法，如果原文一样，生成密文也是一样的，这样的话，如果两个用户的密码原文一样，存到数据库中密文也就一样了，还是不安全，我们需要做进一步处理，常见解决方案就是加盐。盐从那里来呢？我们可以使用用户id（因为一般情况下，用户id是唯一的），也可以使用一个随机字符，我这里采用第一种方案。

7.2 Shiro中如何实现加盐

shiro中加盐的方式很简单，在用户注册时生成密码密文时，就要加入盐，如下几种方式：

Md5Hash md5Hash = new Md5Hash("123", "sang", 1024);
Sha512Hash sha512Hash = new Sha512Hash("123", "sang", 1024);
SimpleHash md5 = new SimpleHash("md5", "123", "sang", 1024);
SimpleHash sha512 = new SimpleHash("sha-512", "123", "sang", 1024)

然后我们首先将sha512生成的字符串放入数据库中，接下来我要配置一下我的jdbcRealm，因为我要指定我的盐是什么。在这里我的盐就是我的用户名，每个用户的用户名是不一样的，因此这里没法写死，在JdbcRealm中，系统提供了四种不同的SaltStyle，如下：

SaltStyle	含义
NO_SALT	默认，密码不加盐
CRYPT	密码是以Unix加密方式储存的
COLUMN	salt是单独的一列储存在数据库中
EXTERNAL	salt没有储存在数据库中，需要通过JdbcRealm.getSaltForUser(String)函数获取

四种不同的SaltStyle对应了四种不同的密码处理方式，部分源码如下：

switch (saltStyle) {
case NO_SALT:
    password = getPasswordForUser(conn, username)[0];
    break;
case CRYPT:
    // TODO: separate password and hash from getPasswordForUser[0]
    throw new ConfigurationException("Not implemented yet");
    //break;
case COLUMN:
    String[] queryResults = getPasswordForUser(conn, username);
    password = queryResults[0];
    salt = queryResults[1];
    break;
case EXTERNAL:
    password = getPasswordForUser(conn, username)[0];
    salt = getSaltForUser(username);
}

在COLUMN这种情况下，SQL查询结果应该包含两列，第一列是密码，第二列是盐，这里默认执行的SQL在JdbcRealm一开头就定义好了，如下：

protected static final String DEFAULT_SALTED_AUTHENTICATION_QUERY = "select password, password_salt from users where username = ?";

即系统默认的盐是数据表中的password_salt提供的，但是我这里是username字段提供的，所以这里我一会要自定义这条SQL。自定义方式很简单，修改shiro.ini文件，添加如下两行：

jdbcRealm.saltStyle=COLUMN
jdbcRealm.authenticationQuery=select password,username from users where username=?

首先设置saltStyle为COLUMN，然后重新定义authenticationQuery对应的SQL。注意返回列的顺序很重要，不能随意调整。如此之后，系统就会自动把username字段作为盐了。

不过，由于ini文件中不支持枚举，saltStyle的值实际上是一个枚举类型，所以我们在测试的时候，需要增加一个枚举转换器在我们的main方法中，如下：

BeanUtilsBean.getInstance().getConvertUtils().register(new AbstractConverter() {
    @Override
    protected String convertToString(Object value) throws Throwable {
        return ((Enum) value).name();
    }

    @Override
    protected Object convertToType(Class type, Object value) throws Throwable {
        return Enum.valueOf(type, value.toString());
    }

    @Override
    protected Class getDefaultType() {
        return null;
    }
}, JdbcRealm.SaltStyle.class);

当然，以后当我们将shiro和web项目整合之后，就不需要这个转换器了。

如此之后，我们就可以再次进行登录测试了，会发现没什么问题了。

7.3 非JdbcRealm如何配置盐

OK，刚刚是在JdbcRealm中配置了盐，如果没用JdbcRealm，而是自己定义的普通Realm，要怎么解决配置盐的问题？

首先要说明一点是，我们前面的文章在自定义Realm时都是通过实现Realm接口实现的，这种方式有一个缺陷，就是密码比对需要我们自己完成，一般在项目中，我们自定义Realm都是通过继承AuthenticatingRealm或者AuthorizingRealm，因为这两个方法中都重写了getAuthenticationInfo方法，而在getAuthenticationInfo方法中，调用doGetAuthenticationInfo方法获取登录用户，获取到之后，会调用assertCredentialsMatch方法进行密码比对，而我们直接实现Realm接口则没有这一步，部分源码如下：

public final AuthenticationInfo getAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
    AuthenticationInfo info = getCachedAuthenticationInfo(token);
    if (info == null) {
        //调用doGetAuthenticationInfo获取info，这个doGetAuthenticationInfo是我们在自定义Realm中自己实现的
        info = doGetAuthenticationInfo(token);
        log.debug("Looked up AuthenticationInfo [{}] from doGetAuthenticationInfo", info);
        if (token != null && info != null) {
            cacheAuthenticationInfoIfPossible(token, info);
        }
    } else {
        log.debug("Using cached authentication info [{}] to perform credentials matching.", info);
    }
    if (info != null) {
        //获取到info之后，进行密码比对
        assertCredentialsMatch(token, info);
    } else {
        log.debug("No AuthenticationInfo found for submitted AuthenticationToken [{}].  Returning null.", token);
    }

    return info;
}

基于上面所述的原因，这里我先继承AuthenticatingRealm，如下：

public class MyRealm extends AuthenticatingRealm {
    public String getName() {
        return "MyRealm";
    }
    public boolean supports(AuthenticationToken token) {
        return token instanceof UsernamePasswordToken;
    }
    protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
        String username = token.getPrincipal().toString();
        if (!"sang".equals(username)) {
            throw new UnknownAccountException("用户不存在");
        }
        String dbPassword = "a593ccad1351a26cf6d91d5f0f24234c6a4da5cb63208fae56fda809732dcd519129acd74046a1f9c5992db8903f50ebf3c1091b3aaf67a05c82b7ee470d9e58";
        return new SimpleAuthenticationInfo(username, dbPassword, ByteSource.Util.bytes(username), getName());
    }
}

关于这个类，我说如下几点：

1. 用户名我这里还是手动判断了下，实际上这个地方要从数据库查询用户信息，如果查不到用户信息，则直接抛UnknownAccountException

2. 返回的SimpleAuthenticationInfo中，第二个参数是密码，正常情况下，这个密码是从数据库中查询出来的，我这里直接写死了

3. 第三个参数是盐值，这样构造好SimpleAuthenticationInfo之后返回，shiro会去判断用户输入的密码是否正确

上面的核心步骤是第三步，系统去自动比较密码输入是否正确，在比对的过程中，需要首先对用户输入的密码进行加盐加密，既然加盐加密，就会涉及到credentialsMatcher，这里我们要用的credentialsMatcher实际上和在JdbcRealm中用的credentialsMatcher一样，只需要在配置文件中增加如下一行即可：

MyRealm.credentialsMatcher=$sha512

sha512和我们上文定义的一致，这里就不再重复说了。

本小节案例下载：github.com/lenve/shiroSamples/archive/refs/tags/v7.zip

8. Shiro中自定义带角色和权限的Realm

密码加密加盐小伙伴们应该没有问题了，但是前面几篇文章又给我们带来了一个新的问题：我们前面IniRealm、JdbcRealm以及自定义的MyRealm，其中前两个我们都能实现用户认证以及授权，即既能管理用户登录，又能管理用户角色，而我们自定义的MyRealm，目前还只能实现登录，不能实现授权，本文我们就来看看自定义Realm如何实现授权。

8.1 问题追踪

上篇文章我们没有实现自定义Realm的授权操作，但是这个并不影响我们调用hasRole方法去获取用户的权限，我在上文测试代码上的currentUser.hasRole上面打断点，通过层层追踪，我们发现最终来到了ModularRealmAuthorizer类的hasRole方法中，部分源码如下：

public boolean hasRole(PrincipalCollection principals, String roleIdentifier) {
    assertRealmsConfigured();
    for (Realm realm : getRealms()) {
        if (!(realm instanceof Authorizer)) continue;
        if (((Authorizer) realm).hasRole(principals, roleIdentifier)) {
            return true;
        }
    }
    return false;
}

我们看到在这里会遍历所有的realm，如果这个realm是Authorizer的实例，则会进行进一步的授权操作，如果不是Authorizer的实例，则直接跳过，而我们只有一个自定义的MyRealm继承自AuthenticatingRealm，很明显不是Authorizer的实例，所以这里必然返回false，授权失败，所以要解决授权问题，第一步，得先让我们的MyRealm成为Authorizer的实例。

8.2 解决方案

如下图是Authorizer的继承关系：

小伙伴们看到，在Authorizer的实现类中有一个AuthorizingRealm，打开这个类，我们发现它的继承关系如下：

public abstract class AuthorizingRealm extends AuthenticatingRealm
        implements Authorizer, Initializable, PermissionResolverAware, RolePermissionResolverAware {
            ...
        }

我们发现，这个AuthorizingRealm不仅是Authorizer的实现类，同时也是我们上文所用的AuthenticatingRealm的实现类，既然AuthorizingRealm同时是这两个类的实现类，那么我把MyRealm的继承关系由AuthenticatingRealm改为AuthorizingRealm，肯定不会影响我上文的功能，修改之后的MyRealm如下(部分关键代码)：

public class MyRealm extends AuthorizingRealm {
    protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException {
        String username = token.getPrincipal().toString();
        if (!"sang".equals(username)) {
            throw new UnknownAccountException("用户不存在");
        }
        String dbPassword = "a593ccad1351a26cf6d91d5f0f24234c6a4da5cb63208fae56fda809732dcd519129acd74046a1f9c5992db8903f50ebf3c1091b3aaf67a05c82b7ee470d9e58";
        return new SimpleAuthenticationInfo(username, dbPassword, ByteSource.Util.bytes(username), getName());
    }

    protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
        Set<String> roles = new HashSet<String>();
        if ("sang".equals(principals.getPrimaryPrincipal().toString())) {
            roles.add("普通用户");
        }
        return new SimpleAuthorizationInfo(roles);
    }
}

继承了AuthorizingRealm之后，需要我们实现doGetAuthorizationInfo方法。在这个方法中，我们配置用户的权限。这里我为了方便，直接添加了普通用户这个权限，实际上，这里应该根据用户名去数据库里查询权限，查询方式不赘述。

通过源码追踪，我们发现最终授权会来到AuthorizingRealm类的如下两个方法中：

public boolean hasRole(PrincipalCollection principal, String roleIdentifier) {
    AuthorizationInfo info = getAuthorizationInfo(principal);
    return hasRole(roleIdentifier, info);
}

protected boolean hasRole(String roleIdentifier, AuthorizationInfo info) {
    return info != null && info.getRoles() != null && info.getRoles().contains(roleIdentifier);
}

这两个方法的逻辑很简单，第一个方法中调用的getAuthorizationInfo方法会最终调用到我们自定义的doGetAuthorizationInfo方法，第二个hasRole方法接收的两个参数，第一个是用户申请的角色，第二个是用户具备的角色集，一个简单的contains函数就判断出用户是否具备某个角色了。

但是这个时候，用户只有角色，没有权限，我们可以对doGetAuthorizationInfo方法做进一步的完善，如下：

protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection principals) {
    Set<String> roles = new HashSet<String>();
    Set<String> permiss = new HashSet<String>();
    if ("sang".equals(principals.getPrimaryPrincipal().toString())) {
        roles.add("普通用户");
        permiss.add("book:update");
    }
    SimpleAuthorizationInfo info = new SimpleAuthorizationInfo(roles);
    info.setStringPermissions(permiss);
    return info;
}

当然，正常情况下，权限也应当是从数据库中查询得到的，我这里简化下。

那么这个角色是怎么验证的呢？追踪源码我们来到了AuthorizingRealm类的如下两个方法中：

public boolean isPermitted(PrincipalCollection principals, Permission permission) {
    AuthorizationInfo info = getAuthorizationInfo(principals);
    return isPermitted(permission, info);
}

//visibility changed from private to protected per SHIRO-332
protected boolean isPermitted(Permission permission, AuthorizationInfo info) {
    Collection<Permission> perms = getPermissions(info);
    if (perms != null && !perms.isEmpty()) {
        for (Permission perm : perms) {
            if (perm.implies(permission)) {
                return true;
            }
        }
    }
    return false;
}

第一个isPermitted方法中调用了getAuthorizationInfo方法，而getAuthorizationInfo方法最终会调用到我们自己定义的doGetAuthorizationInfo方法，即获取到用户的角色权限信息，然后在第二个方法中进行遍历判断，查看是否具备相应的权限，第二个isPermitted方法的第一个参数就是用户要申请的权限。

本小节案例下载：github.com/lenve/shiroSamples/archive/refs/tags/v8.zip

9. Shiro整合Spring

9.1 Spring&SpringMVC环境搭建

Spring和SpringMVC环境的搭建，整体上来说，还是比较容易的，因为这个不是本文的重点，因此这里我不做详细介绍，小伙伴可以在文末下载源码查看Spring+SpringMVC环境的搭建。同时，由于MyBatis的整合相对要容易很多，这里为了降低项目复杂度，我也就先不引入MyBatis。

对于项目依赖，除了Spring、SpringMVC、Shiro相关的依赖，还需要加入Shiro和Spring整合的jar，如下：

<dependency>
    <groupId>org.apache.shiro</groupId>
    <artifactId>shiro-spring</artifactId>
    <version>RELEASE</version>
</dependency>

9.2 整合Shiro

搭建好Spring+SpringMVC环境之后，整合Shiro我们主要配置两个地方：

1. web.xml中配置代理过滤器，如下：

<filter>
    <filter-name>shiroFilter</filter-name>
    <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    <init-param>
        <param-name>targetFilterLifecycle</param-name>
        <param-value>true</param-value>
    </init-param>
</filter>
<filter-mapping>
    <filter-name>shiroFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

这样之后，当DelegatingFilterProxy拦截到所有请求之后，都会委托给shiroFilter来处理，shiroFilter是我们第二步在Spring容器中配置的一个实例。

2. 配置Spring容器

在Spring容器中至少有两个Bean需要我们配置，一个就是第一步中的shiroFilter，还有一个就是SecurityManager，完整配置如下：

<bean class="org.apache.shiro.web.mgt.DefaultWebSecurityManager" id="securityManager">
</bean>
<bean class="org.apache.shiro.spring.web.ShiroFilterFactoryBean" id="shiroFilter">
    <property name="securityManager" ref="securityManager"/>
    <property name="loginUrl" value="/login.jsp"></property>
    <property name="successUrl" value="/success.jsp"/>
    <property name="unauthorizedUrl" value="/unauthorized.jsp"/>
    <property name="filterChainDefinitions">
        <value>
            /**=authc
        </value>
    </property>
</bean>

这是一个非常简单的配置，我们在以后的文章中还会继续完善它，关于这个配置我说如下几点：

1. 首先我们需要配置一个securityManager，到时候我们的realm要配置在这里。

2. 还要配置一个名为shiroFilter的bean，这个名字要和web.xml中代理过滤器的名字一致。

3. shiroFilter中，loginUrl表示登录页面地址。

4. successUrl表示登录成功地址。

5. unauthorizedUrl表示授权失败地址。

6. filterChainDefinitions中配置的/**=authc表示所有的页面都需要认证(登录)之后才能访问。

7. authc实际上是一个过滤器，这个我们在后文还会再详细说到。

8. 匹配符遵循Ant风格路径表达式,这里可以配置多个，匹配顺序从上往下匹配到了就不再匹配了。比如下面这个写法：

/a/b/*=anon
/a/**=authc

假设我的路径是/a/b/c那么就会匹配到第一个过滤器anon，而不会匹配到authc，所以这里的顺序很重要。

OK，这些配置写完后，在webpap目录下创建对应的jsp文件，如下：

此时，启动项目去浏览器中访问，无论我们访问什么地址，最后都会回到login.jsp页面，因为所有的页面（即使不存在的地址）都需要认证后才可以访问。

本小节案例：github.com/lenve/shiroSamples/archive/refs/tags/v9.zip

10. Shiro处理登录的三种方式

10.1 准备工作

很明显，不管是那种登录，都离不开数据库，这里数据库我采用我们前面的数据库，这里不做赘述(文末可以下载数据库脚本)，但是我这里需要首先配置JdbcRealm，在applicationContext.xml中首先配置数据源，如下：

<context:property-placeholder location="classpath:db.properties"/>
<bean class="com.alibaba.druid.pool.DruidDataSource" id="dataSource">
    <property name="username" value="${db.username}"/>
    <property name="password" value="${db.password}"/>
    <property name="url" value="${db.url}"/>
</bean>

有了数据源之后，接下来配置JdbcRealm，如下：

<bean class="org.apache.shiro.realm.jdbc.JdbcRealm" id="jdbcRealm">
    <property name="dataSource" ref="dataSource"/>
    <property name="credentialsMatcher">
        <bean class="org.apache.shiro.authc.credential.HashedCredentialsMatcher">
            <property name="hashAlgorithmName" value="sha-512"/>
            <property name="hashIterations" value="1024"/>
        </bean>
    </property>
    <property name="saltStyle" value="COLUMN"/>
    <property name="authenticationQuery" value="select password, username from users where username = ?"/>
</bean>

JdbcRealm中这几个属性和我们本系列第七篇文章基本是一致的，首先我们配置了密码比对器为HashedCredentialsMatcher，相应的算法为sha512，密码加密迭代次数为1024次，然后我们配置了密码的盐从数据表的列中来，username列就是我们的盐，这些配置和前文都是一致的，不清楚的小伙伴可以参考我们本系列第七篇文章。

10.2 自定义登录逻辑

自定义登录逻辑比较简单，首先我们把login.jsp页面进行简单改造：

<form action="/login" method="post">
    <table>
        <tr>
            <td>用户名：</td>
            <td><input type="text" name="username"></td>
        </tr>
        <tr>
            <td>密码：</td>
            <td><input type="password" name="password"></td>
        </tr>
        <tr>
            <td colspan="2"><input type="submit" value="登录"></td>
        </tr>
    </table>
</form>

然后创建我们的登录处理Controller，如下：

@PostMapping("/login")
public String login(String username, String password) {
    Subject currentUser = SecurityUtils.getSubject();
    UsernamePasswordToken token = new UsernamePasswordToken(username, password);
    try {
        currentUser.login(token);
        return "success";
    } catch (AuthenticationException e) {
    }
    return "login";
}

登录成功我们就去success页面，登录失败就回到登录页面。做完这两步之后，我们还要修改shiroFilter中的filterChainDefinitions属性，要设置/login接口可以匿名访问，如下：

<bean class="org.apache.shiro.spring.web.ShiroFilterFactoryBean" id="shiroFilter">
    <property name="securityManager" ref="securityManager"/>
    <property name="loginUrl" value="/login.jsp"></property>
    <property name="successUrl" value="/success.jsp"/>
    <property name="unauthorizedUrl" value="/unauthorized.jsp"/>
    <property name="filterChainDefinitions">
        <value>
            /login=anon
            /**=authc
        </value>
    </property>
</bean>

做完这些之后，就可以去login.jsp页面测试登录了。

上面中方式是我们自己写登录逻辑，shiro也给我们提供了两种不用自己写登录逻辑的登录方式，请继续往下看。

10.3 基于HTTP的认证

shiro中也提供了基于http协议的认证，当然，这种认证也得有数据库的辅助，数据配置和前文一样，我们只需要修改一个配置即可，如下：

<bean class="org.apache.shiro.spring.web.ShiroFilterFactoryBean" id="shiroFilter">
    <property name="securityManager" ref="securityManager"/>
    <property name="filterChainDefinitions">
        <value>
            /**=authcBasic
        </value>
    </property>
</bean>

这个表示所有的页面都要经过基于http的认证。此时我们打开任意一个页面，认证方式如下：

10.4 表单登录

表单登录和基于HTTP的登录类似，都是不需要我们自己写登录逻辑的登录，但是出错的逻辑还是要稍微处理下，首先修改shiroFilter：

<bean class="org.apache.shiro.spring.web.ShiroFilterFactoryBean" id="shiroFilter">
    <property name="securityManager" ref="securityManager"/>
    <property name="loginUrl" value="/login"/>
    <property name="successUrl" value="/success.jsp"/>
    <property name="filterChainDefinitions">
        <value>
            /**=authc
        </value>
    </property>
</bean>

配置登录页面，也配置登录成功后的跳转页面，同时设置所有页面都要登录后才能访问。

配置登录页面请求，如下：

@RequestMapping("/login")
public String login(HttpServletRequest req, Model model) {
    String shiroLoginFailure = (String) req.getAttribute("shiroLoginFailure");
    if (UnknownAccountException.class.getName().equals(shiroLoginFailure)) {
        model.addAttribute("error", "账户不存在!");
    }
    if (IncorrectCredentialsException.class.getName().equals(shiroLoginFailure)) {
        model.addAttribute("error", "密码不正确!");
    }
    return "login";
}

如果登录失败，那么在request中会有一个shiroLoginFailure的属性中保存了登录失败的异常类名，通过判断这个类名，我们就可以知道是什么原因导致了登录失败。

OK，配置好这两步之后，就可以去登录页面测试了。

10.5 注销登录

注销登录比较简单，就一个过滤器，按如下方式配置：

<property name="filterChainDefinitions">
    <value>
        /logout=logout
        /**=authc
    </value>
</property>

通过get请求访问/logout即可注销登录。

本小节有三个案例，下载地址如下：

• github.com/lenve/shiroSamples/archive/refs/tags/v10.1.zip
• github.com/lenve/shiroSamples/archive/refs/tags/v10.2.zip
• github.com/lenve/shiroSamples/archive/refs/tags/v10.3.zip

11. Shiro中的授权问题

11.1 配置角色

本文的案例在上文的基础上完成，因此Realm这一块我依然采用JdbcRealm，相关的授权就不必配置了。但是这里的数据库脚本有更新，小伙伴需要下载重新执行（github.com/lenve/shiroSamples/blob/v11/shiroDemo.sql）。

先来介绍下目前数据库中用户的情况，数据库中有两个用户，sang具有admin的角色，同时具有book:*和author:create两个权限，lisi具有user的角色，同时具有user:info和user:delete两个权限。修改shiroFilter，如下：

<bean class="org.apache.shiro.spring.web.ShiroFilterFactoryBean" id="shiroFilter">
    <property name="securityManager" ref="securityManager"/>
    <property name="loginUrl" value="/login"/>
    <property name="successUrl" value="/success.jsp"/>
    <property name="unauthorizedUrl" value="/unauthorized.jsp"/>
    <property name="filterChainDefinitions">
        <value>
            /admin.jsp=authc,roles[admin]
            /user.jsp=authc,roles[user]
            /logout=logout
            /**=authc
        </value>
    </property>
</bean>

关于这里的配置，我说如下几点：

1. unauthorizedUrl表示授权失败时展示的页面
2. filterChainDefinitions中我们配置了admin.jsp页面必须登录后才能访问，同时登录的用户必须具有admin角色，user.jsp也是必须登录后才能访问，同时登录的用户必须具有user角色

11.2 测试

测试时我们分别用sang/123和lisi/123进行登录，登录成功后分别访问user.jsp和admin.jsp就能看到效果。

11.3 配置权限

上面的方式是配置角色，但是还没有配置权限，要配置权限，首先要在jdbcRealm中添加允许权限信息的查询：

<property name="permissionsLookupEnabled" value="true"/>

然后配置下shiroFilter：

<property name="filterChainDefinitions">
    <value>
        /admin.jsp=authc,roles[admin]
        /user.jsp=authc,roles[user]
        /userinfo.jsp=authc,perms[user:info]
        /bookinfo.jsp=authc,perms[book:info]
        /logout=logout
        /**=authc
    </value>
</property>

这里假设访问userinfo.jsp需要user:info权限，访问bookinfo.jsp需要book:info权限。

OK，做完这些之后就可以测试了，分别用sang/123和lisi/123进行登录，登录成功后分别访问bookinfo.jsp和userinfo.jsp就可以看到不同效果了。

本小节案例下载：github.com/lenve/shiroSamples/archive/refs/tags/v11.zip

12. Shiro中的JSP标签

12.1 缘起

上篇文章中，我们在success.jsp中写了很多像下面这种超链接：

<h1>登录成功！</h1>
<h3><a href="/logout">注销</a></h3>
<h3><a href="/admin.jsp">admin.jsp</a></h3>
<h3><a href="/user.jsp">user.jsp</a></h3>
<h3><a href="/bookinfo.jsp">bookinfo.jsp</a></h3>
<h3><a href="/userinfo.jsp">userinfo.jsp</a></h3>

但是对于不同身份的用户，并不是每一个链接都是有效的，点击无效的链接会进入到未授权的页面，这样用户体验并不好，最好能够把不可达的链接自动隐藏起来，同时，我也希望能够方便获取当前登录用户的信息等，考虑到这些需求，我们来聊聊shiro中的jsp标签。

12.2 标签介绍

shiro中的标签并不多，主要有如下几种：

1. shiro:guest

shiro:guest标签只有在当前未登录时显示里边的内容，如下：

<shiro:guest>
    欢迎【游客】访问!
</shiro:guest>

2. shiro:user

shiro:user是在用户登录之后显示该标签中的内容，无论是通过正常的登录还是通过Remember Me登录，如下：

<shiro:user>
    欢迎【<shiro:principal/>】访问!
</shiro:user>

3. shiro:principal

shiro:principal用来获取当前登录用户的信息，显示效果如下：

4.shiro:authenticated

和shiro:user相比，shiro:authenticated的范围变小，当用户认证成功且不是通过Remember Me认证成功，这个标签中的内容才会显示出来：

<shiro:authenticated>
    用户【<shiro:principal/>】身份认证通过，不是通过Remember Me认证!
</shiro:authenticated>

5. shiro:notAuthenticated

shiro:notAuthenticated也是在用户未认证的情况下显示内容，和shiro:guest不同的是，对于通过Remember Me方式进行的认证，shiro:guest不会显示内容，而shiro:notAuthenticated会显示内容(因为此时并不是游客，但是又确实未认证)，如下：

<shiro:notAuthenticated>
    用户未进行身份认证
</shiro:notAuthenticated>

6. shiro:lacksRole

当用户不具备某个角色时候，显示内容，如下：

<shiro:lacksRole name="admin">
    用户不具备admin角色
</shiro:lacksRole>

7. shiro:lacksPermission

当用户不具备某个权限时显示内容：

<shiro:lacksPermission name="book:info">
    用户不具备book:info权限
</shiro:lacksPermission>

8. shiro:hasRole

当用户具备某个角色时显示的内容：

<shiro:hasRole name="admin">
    <h3><a href="/admin.jsp">admin.jsp</a></h3>
</shiro:hasRole>

9. shiro:hasAnyRoles

当用户具备多个角色中的某一个时显示的内容：

<shiro:hasAnyRoles name="user,aaa">
    <h3><a href="/user.jsp">user.jsp</a></h3>
</shiro:hasAnyRoles>

10. shiro:hasPermission

当用户具备某一个权限时显示的内容：

<shiro:hasPermission name="book:info">
    <h3><a href="/bookinfo.jsp">bookinfo.jsp</a></h3>
</shiro:hasPermission>

本小节案例下载：github.com/lenve/shiroSamples/archive/refs/tags/v12.zip

13.Shiro 中的缓存机制

13.1 添加依赖

使用缓存，首先需要添加相关依赖，如下：

<dependency>
    <groupId>org.apache.shiro</groupId>
    <artifactId>shiro-ehcache</artifactId>
    <version>1.4.0</version>
</dependency>

13.2 添加配置文件

ehcache的配置文件主要参考官方的配置，在resources目录下创建ehcache.xml文件，内容如下：

<ehcache>
    <diskStore path="java.io.tmpdir/shiro-spring-sample"/>
    <defaultCache
            maxElementsInMemory="10000"
            eternal="false"
            timeToIdleSeconds="120"
            timeToLiveSeconds="120"
            overflowToDisk="false"
            diskPersistent="false"
            diskExpiryThreadIntervalSeconds="120"
    />
    <cache name="shiro-activeSessionCache"
           maxElementsInMemory="10000"
           eternal="true"
           overflowToDisk="true"
           diskPersistent="true"
           diskExpiryThreadIntervalSeconds="600"/>
    <cache name="org.apache.shiro.realm.SimpleAccountRealm.authorization"
           maxElementsInMemory="100"
           eternal="false"
           timeToLiveSeconds="600"
           overflowToDisk="false"/>
</ehcache>

这些都是ehcache缓存中常规的配置，含义我就不一一解释了，文末下载源码有注释。

13.3 缓存配置

接下来我们只需要在applicationContext中简单配置下缓存即可，配置方式如下：

<bean class="org.apache.shiro.cache.ehcache.EhCacheManager" id="cacheManager">
    <property name="cacheManagerConfigFile" value="classpath:ehcache.xml"/>
</bean>
<bean class="org.apache.shiro.web.mgt.DefaultWebSecurityManager" id="securityManager">
    <property name="realm" ref="jdbcRealm"/>
    <property name="cacheManager" ref="cacheManager"/>
</bean>

首先配置EhCacheManager类，指定缓存位置，然后在DefaultWebSecurityManager中引入cacheManager即可，如此之后，我们的缓存就应用上了。

13.4 测试

由于我这里使用了JdbcRealm，如果使用了自定义Realm那么可以通过打日志看是否使用了缓存，使用了JdbcRealm之后，我们可以通过打断点来查看是否应用了缓存，比如我执行如下代码：

subject.checkRole("admin");
subject.checkPermission("book:info");

通过断点跟踪，发现最终会来到AuthorizingRealm的getAuthorizationInfo方法中，在该方法中，首先会去缓存中检查数据，如果缓存中有数据，则不会执行doGetAuthorizationInfo方法（数据库操作就在doGetAuthorizationInfo方法中进行），如果缓存中没有数据，则会执行doGetAuthorizationInfo方法，并且在执行成功后将数据保存到缓存中（前提是配置了缓存，cache不为null），此时我们通过断点，发现执行了缓存而没有查询数据库中的数据，部分源码如下：

protected AuthorizationInfo getAuthorizationInfo(PrincipalCollection principals) {
    AuthorizationInfo info = null;
    Cache<Object, AuthorizationInfo> cache = getAvailableAuthorizationCache();
    if (cache != null) {
        Object key = getAuthorizationCacheKey(principals);
        info = cache.get(key);
    }
    if (info == null) {
        info = doGetAuthorizationInfo(principals);
        if (info != null && cache != null) {
            Object key = getAuthorizationCacheKey(principals);
            cache.put(key, info);
        }
    }
    return info;
}

OK，整体来说shiro中的缓存配置还是非常简单的。

That’s all.

本小节案例下载地址：github.com/lenve/shiroSamples/archive/v13.zip

待续。。。