Spring Security
13 分钟 读完 (大约 1940 个字)

我又发现 Spring Security 中一个小秘密！

说来惭愧，Spring Security 系列前前后后写了 60 多篇文章了，竟然漏掉了如此重要的一块。

平时在公司项目中，都是能用则用，先把需求整出来，有的时候也不去深究它的原理，这无形中就给自己挖了大坑。

松哥这次就是，不过也因此又发现了 Spring Security 的一个用法，今天就和小伙伴们分享下。

1.缘起

事情是这样的，看过 vhr 项目（https://github.com/lenve/vhr）的小伙伴都知道 vhr 里边有一个动态权限管理功能，实现的思路就是重写了 FilterInvocationSecurityMetadataSource 以及决策管理器 AccessDecisionManager，代码就类似下面这样（小伙伴们可以在 GitHub 上查看完整代码）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Override
protected void configure(HttpSecurity http) throws Exception {
    http.authorizeRequests()
            .withObjectPostProcessor(new ObjectPostProcessor<FilterSecurityInterceptor>() {
                @Override
                public <O extends FilterSecurityInterceptor> O postProcess(O object) {
                    object.setAccessDecisionManager(customUrlDecisionManager);
                    object.setSecurityMetadataSource(customFilterInvocationSecurityMetadataSource);
                    return object;
                }
            })
            .and()
            .formLogin()
            .permitAll()
            .and()
            .csrf().disable();
}

昨天我想再写一个类似的功能，本想着很简单，三下五除二就搞定，大家看下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
http
        .authorizeRequests()
        .withObjectPostProcessor(new ObjectPostProcessor<FilterSecurityInterceptor>() {
            @Override
            public <O extends FilterSecurityInterceptor> O postProcess(O object) {
                object.setSecurityMetadataSource(customSecurityMetadataSource);
                object.setAccessDecisionManager(accessDecisionManager());
                return object;
            }
        })
        .and()
        .formLogin()
        .and()
        .csrf().disable();

小伙伴们能看出这两段代码的差别吗？

写完之后，启动项目，一启动就报错了！

我就有点懵。之前的 vhr 启动是没问题的，但是这次新的项目启动就有问题。

在 IDEA 中，通过 Ctrl+Shift+F 全局搜索，找到了异常抛出的位置：

如果 requestMap 变量为空，就会抛出异常。requestMap 就是我们在 configure 方法中配置的请求和权限的映射，不过在上面的案例中，我是想像 vhr 那样做动态权限管理，所以请求和角色的映射关系我是保存在数据库中，没有必要在代码中配置。

但是根据异常提示，我就先随便加一个映射，果然启动就不报错了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
http
        .authorizeRequests()
        .withObjectPostProcessor(new ObjectPostProcessor<FilterSecurityInterceptor>() {
            @Override
            public <O extends FilterSecurityInterceptor> O postProcess(O object) {
                object.setSecurityMetadataSource(customSecurityMetadataSource);
                object.setAccessDecisionManager(accessDecisionManager());
                return object;
            }
        })
        .antMatchers("/hello").hasRole("admin")
        .and()
        .formLogin()
        .and()
        .csrf().disable();

现在让我有两个郁闷的地方：

  1. vhr 为什么可以启动而不报错
  2. 这里代码中多出来的一行映射明显是累赘，最好能够去掉

2.问题分析

第一个问题很好办，仔细对比最开始贴出来的代码就能找到端倪，vhr 中的代码多了一个 permitAll 方法，这就是一个表达式，有了该方法，就意味着里边多了一个映射关系，/login -> permitAll，这样 requestMap 就不会为空，所以启动时就不报错了。

按照这个思路，我去修改了自己的代码，去除冗余的映射，加上 permitAll，这次果然可以了。

问题虽然解决了，但是心里还是有点膈应。

为什么呢？因为用户-角色-资源的映射关系我都保存在数据库中了，权限数据库类似下面这样：

既然所有的权限管理都保存在数据库中了，再在代码中配置似乎就不太合适！但是不配置，项目启动又会出错，看来还是得从源码入手。

于是松哥花了点时间，把这里涉及到的相关源码仔细梳理了一遍。

3.源码梳理

首先大家知道，Spring Security 中的权限控制有两种不同的方式：

  1. 通过 URL 请求地址进行控制。
  2. 通过方法进行控制。

如果通过 URL 请求地址进行控制，负责控制类配置的是 AbstractInterceptUrlConfigurer，我们来看下它的子类：

可以看到它有两个子类：

  • ExpressionUrlAuthorizationConfigurer
  • UrlAuthorizationConfigurer

两个都可以处理基于 URL 请求地址的权限控制。不同的是，第一个 ExpressionUrlAuthorizationConfigurer
支持权限表达式，第二个不支持。

什么是权限表达式？其实大家都有用，只是可能没注意过这些概念，下图就是 Spring Security 中提供的内置通用权限表达式：

图片源自网络

ExpressionUrlAuthorizationConfigurer 支持权限表达式的原因是因为它使用的投票器是 WebExpressionVoter，这个投票器就是用来处理权限表达式的。

而 UrlAuthorizationConfigurer 不支持权限表达式，是因为它使用的投票器是 RoleVoter 和 AuthenticatedVoter，这两者可以用来处理角色或者权限，但是没法处理权限表达式。

关于投票器，小伙伴们可以参考松哥之前的文章：Spring Security 权限管理的投票器与表决机制。

上面说的都是默认行为，我们也可以通过修改配置，让 UrlAuthorizationConfigurer 支持权限表达式，不过一般来说没必要这样做，如果需要支持权限表达式，直接用 ExpressionUrlAuthorizationConfigurer 即可。

当我们调用如下这行代码时：

1
http.authorizeRequests()

实际上就是通过 ExpressionUrlAuthorizationConfigurer 去配置基于 URL 请求地址的权限控制，所以它是支持权限表达式的。例如下面这段大家再熟悉不过的代码：

1
2
3
http.authorizeRequests()
        .antMatchers("/admin/**").hasRole("ADMIN")
        .antMatchers("/user/**").access("hasRole('USER')")

在 ExpressionUrlAuthorizationConfigurer 中创建 SecurityMetadataSource 时，就会检查映射关系，如果 requestMap 为空就会抛出异常：

1
2
3
4
5
6
7
8
9
10
11
12
@Override
ExpressionBasedFilterInvocationSecurityMetadataSource createMetadataSource(
		H http) {
	LinkedHashMap<RequestMatcher, Collection<ConfigAttribute>> requestMap = REGISTRY
			.createRequestMap();
	if (requestMap.isEmpty()) {
		throw new IllegalStateException(
				"At least one mapping is required (i.e. authorizeRequests().anyRequest().authenticated())");
	}
	return new ExpressionBasedFilterInvocationSecurityMetadataSource(requestMap,
			getExpressionHandler(http));
}

UrlAuthorizationConfigurer 中也有 createMetadataSource 方法，但是却是另外一套实现方案： 

1
2
3
4
5
@Override
FilterInvocationSecurityMetadataSource createMetadataSource(H http) {
	return new DefaultFilterInvocationSecurityMetadataSource(
			REGISTRY.createRequestMap());
}

UrlAuthorizationConfigurer 并不会检查 requestMap 是否为空，但是它会在 createRequestMap 方法中检查一下映射关系是否完整，例如下面这样：

1
2
3
.antMatchers("/admin/**").access("ROLE_ADMIN")
.mvcMatchers("/user/**").access("ROLE_USER")
.antMatchers("/getinfo");

最后的 /getinfo 没有指定需要的权限，这种就是不完整，就会抛出异常。

现在大家应该大致明白 ExpressionUrlAuthorizationConfigurer 和 UrlAuthorizationConfigurer 的区别了吧。

4.问题解决

ExpressionUrlAuthorizationConfigurer 会要求至少配置一个映射关系，UrlAuthorizationConfigurer 则无此要求。

当我们想要动态配置权限拦截时，一般来说也不会使用权限表达式，数据库中保存的就是普通的权限或者角色，所以这个时候我们可以选择 UrlAuthorizationConfigurer 而不是 ExpressionUrlAuthorizationConfigurer。

反映到代码上，就是下面这样：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
@Override
protected void configure(HttpSecurity http) throws Exception {
    ApplicationContext applicationContext = http.getSharedObject(ApplicationContext.class);
    http.apply(new UrlAuthorizationConfigurer<>(applicationContext))
            .withObjectPostProcessor(new ObjectPostProcessor<FilterSecurityInterceptor>() {
                @Override
                public <O extends FilterSecurityInterceptor> O postProcess(O object) {
                    object.setSecurityMetadataSource(customSecurityMetadataSource);
                    return object;
                }
            });
    http.formLogin()
            .and()
            .csrf().disable();
}

这样看起来就更合理一些，不用额外配置一条映射关系。

今天这篇文章可能对没了解过动态权限控制的小伙伴来说略难，大家可以参考松哥的 vhr（https://github.com/lenve/vhr）项目去了解下动态权限控制。当然，也可以参考松哥的[Spring Boot+Vue+微人事视频教程](https://mp.weixin.qq.com/s/EEmEL6tpuBT0qLfPwhj2OQ)，里边也有讲动态权限控制问题。

好啦，今天就和小伙伴们分享这么多，要不是这次遇到问题，我一直都懒得去研究 ExpressionUrlAuthorizationConfigurer 和 UrlAuthorizationConfigurer 有什么区别。感兴趣的小伙伴可以自己 DEBUG 验证下本文内容哦～

# Spring Security

喜欢这篇文章吗？扫码关注公众号【江南一点雨】，【江南一点雨】专注于 SPRING BOOT+微服务以及前后端分离技术，每天推送原创技术干货，关注后回复 JAVA，领取松哥为你精心准备的 JAVA 干货!

觉得不错，可以给小编加个鸡腿

聊一个 GitHub 上开源的 RBAC 权限管理系统，很6！
Spring Security 中最流行的权限管理模型！

评论

扫码关注微信公众号

分类

标签云

2019-article Actuator Blog Bug CAS CORS Chrome Docker Druid Ehcache ElasticJob ElasticSearch ElasticSerach Eureka FastDFS Flowable Flyway Freemarker Git GitHub HDC Https I18N IDEA IDEA，EasyCode IntelliJ IDEA JDK16 JWT Java JavaWeb JdbcTemplate Jedis Jenkins Jpa LiveReload Log Lombok MacBook MacBookPro Mail Maven MongoDB MyBatis MyBatisPlus MyCat MySQL MySQL8 Nacos Nginx OAuth2 PicGo Platform Plugin RabbitMQ Redis Resume SSM Shiro Spring Spring Boot Spring Cloud Spring Data Spring Security Spring6 SpringBoot SpringBoot3 SpringCloud SpringData SpringDataJpa SpringMVC SpringSecurity Swagger Swagger2 Swagger3 TLS Tencent Thymeleaf TienChin Transaction Video ViewResolver Vue Vue3 Web WebFlux blog docker domain elasticjob es gRPC hdz hexo huawei i18n idea java life mail nginx redis router saga seata tcc transaction vhr video vue vuepress weixin xa xxl-job yaml 七牛云 中间件 主从复制 事务 侃侃而谈 全局ID 分布式 分布式事务 分布式锁 前后端分离 华为 单体应用 外包 学习资源 定时任务 工具 干货汇总 延迟队列 微人事 微服务 杂谈 条件注解 死信队列 消息过期 消息驱动 源码解析 源码解读 生活 私活 程序人生 程序员 腾讯 自学 视频 视频教程 训练营 资料 逆向工程 面试

最新文章

归档

友链

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×