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

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数据库连接池，因此首先添加如下依赖：

com.alibaba

druid

RELEASE

mysql

mysql-connector-java

5.1.27

2. 数据库创建

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

这里为了大家能够直观的看到表的关系，我使用了外键，实际工作中，视情况而定。然后向表中添加几条测试数据。数据库脚本小伙伴可以在github上下载到（https://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 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 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万个优快云用户资料的数据库，数据全部为明文储存，包含用户名、密码以及注册邮箱。事件发生后优快云在微博、官方网站等渠道发出了声明，解释说此数据库系2009年备份所用，因不明原因泄露，已经向警方报案。后又在官网网站发出了公开道歉信。在接下来的十多天里，金山、网易、京东、当当、新浪等多家公司被卷入到这次事件中。整个事件中最触目惊心的莫过于优快云把用户密码明文存储，由于很多用户是多个网站共用一个密码，因此一个网站密码泄露就会造成很大的安全隐患。由于有了这么多前车之鉴，我们现在做系统时，密码都要加密处理。

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

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

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

本小节案例下载：https://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和我们上文定义的一致，这里就不再重复说了。

本小节案例下载：https://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 roles = new HashSet();

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 roles = new HashSet();

Set permiss = new HashSet();

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 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方法的第一个参数就是用户要申请的权限。

本小节案例下载：https://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，如下：

org.apache.shiro

shiro-spring

RELEASE

9.2 整合Shiro

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

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

shiroFilter

org.springframework.web.filter.DelegatingFilterProxy

targetFilterLifecycle

true

shiroFilter

/*

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

2. 配置Spring容器

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

/**=authc

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

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页面，因为所有的页面（即使不存在的地址）都需要认证后才可以访问。

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

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

---

10.1 准备工作

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

<context:property-placeholder location=“classpath:db.properties”/>

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

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

10.2 自定义登录逻辑

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

用户名： 密码：

然后创建我们的登录处理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接口可以匿名访问，如下：

/login=anon

/**=authc

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

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

10.3 基于HTTP的认证

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

/**=authcBasic

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

10.4 表单登录

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

/**=authc

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

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

@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 注销登录

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

/logout=logout

/**=authc

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

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

• https://github.com/lenve/shiroSamples/archive/refs/tags/v10.1.zip

• https://github.com/lenve/shiroSamples/archive/refs/tags/v10.2.zip

• https://github.com/lenve/shiroSamples/archive/refs/tags/v10.3.zip

11. Shiro中的授权问题

---

11.1 配置角色

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

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

/admin.jsp=authc,roles[admin]

/user.jsp=authc,roles[user]

/logout=logout

/**=authc

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

1. unauthorizedUrl表示授权失败时展示的页面

2. filterChainDefinitions中我们配置了admin.jsp页面必须登录后才能访问，同时登录的用户必须具有admin角色，user.jsp也是必须登录后才能访问，同时登录的用户必须具有user角色

11.2 测试

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

11.3 配置权限

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

然后配置下shiroFilter：

/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

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

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

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

12. Shiro中的JSP标签

---

12.1 缘起

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

登录成功！

注销

admin.jsp

user.jsp

bookinfo.jsp

userinfo.jsp

但是对于不同身份的用户，并不是每一个链接都是有效的，点击无效的链接会进入到未授权的页面，这样用户体验并不好，最好能够把不可达的链接自动隐藏起来，同时，我也希望能够方便获取当前登录用户的信息等，考虑到这些需求，我们来聊聊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用来获取当前登录用户的信息，显示效果如下：