我要评论一、 背景与痛点
在传统的 spring security 开发中（尤其是单体大应用），我们往往会在一个主配置类（如 securityconfig）里写死所有的 url 权限规则：
// 传统写法：随着业务增长，这个方法会变成几百行的“面条代码”
http.authorizehttprequests()
.requestmatchers("/admin/**").hasrole("admin")
.requestmatchers("/order/**").hasrole("user")
.requestmatchers("/pay/**").permitall()
// ... 无休止的追加 ...痛点：
- 严重耦合：基础架构层必须感知所有业务模块的 url 规则。
- 维护困难：多人开发时，大家都在修改同一个文件，代码冲突不断。
- 扩展性差：新增一个业务模块，必须去改主工程的代码。
二、 核心架构设计
为了解决上述问题，我们引入了 “插拔式” 的设计模式。核心由三个部分组成：
- 调度中心：主配置类（只负责调度，不负责具体规则）。
- 标准协议：
authorizerequestscustomizer抽象类（定义怎么配）。 - 业务实现：各模块的 customizer（具体配什么）。
1. 调度中心：主 securityfilterchain
在主配置类（如 yudaowebsecurityconfigureradapter）中，我们不再硬编码规则，而是利用 spring 的 自动注入（dependency injection） 特性。
// 1. 注入所有实现了 customizer 接口的 bean
@resource
private list<authorizerequestscustomizer> authorizerequestscustomizers;
@bean
protected securityfilterchain filterchain(httpsecurity httpsecurity) throws exception {
httpsecurity
// ... 其他配置 ...
.authorizehttprequests(c -> {
// 2. 核心逻辑：遍历所有注入的 customizer，让它们自己定义规则
authorizerequestscustomizers.foreach(customizer -> customizer.customize(c));
// 3. 兜底规则（最后执行）
c.anyrequest().authenticated();
});
return httpsecurity.build();
}解析：主配置类变成了一个“容器”，它根本不知道 /order 需要什么权限，它只负责把话筒交给各个业务模块，让模块自己“发言”。
2. 标准协议：authorizerequestscustomizer
我们需要定义一个抽象类，既作为统一的接口类型，又可以提供一些通用的工具方法（如 api 前缀处理）。
public abstract class authorizerequestscustomizer
implements customizer<authorizehttprequestsconfigurer<httpsecurity>.authorizationmanagerrequestmatcherregistry>, ordered {
@resource
private webproperties webproperties;
// 提供通用方法的封装，避免各模块硬编码前缀
protected string buildadminapi(string url) {
return webproperties.getadminapi().getprefix() + url;
}
protected string buildappapi(string url) {
return webproperties.getappapi().getprefix() + url;
}
// 默认优先级，业务模块可以通过重写此方法调整自己在过滤器链中的位置
@override
public int getorder() {
return 0;
}
}3. 业务实现：模块化的 customizer
假设我们有一个 “基础设施模块 (infra)”，它需要开放 swagger 文档和一些监控断点，我们不需要改主工程，只需在 infra 模块内部写一个 bean：
@configuration
public class infrasecurityconfiguration {
@bean("infraauthorizerequestscustomizer")
public authorizerequestscustomizer infraauthorizerequestscustomizer() {
return new authorizerequestscustomizer() {
@override
public void customize(authorizehttprequestsconfigurer<httpsecurity>.authorizationmanagerrequestmatcherregistry registry) {
// 定义该模块独有的权限规则
registry.requestmatchers(buildadminapi("/infra/file/**")).permitall() // 文件下载免登录
.requestmatchers("/swagger-ui/**").permitall() // swagger 免登录
.requestmatchers("/druid/**").hasrole("admin"); // 数据库监控需管理员
}
// 可选：如果需要在其他规则之前生效，可以调高优先级
@override
public int getorder() {
return -10;
}
};
}
}三、 工作原理深度解析
这个机制之所以能工作，依赖于 spring 容器强大的生命周期管理：
- 启动扫描 (scanning)：
spring boot 启动时，扫描所有加了@configuration的类。 - bean 注册 (registration)：
各个业务模块（infra, order, pay）定义的authorizerequestscustomizer被实例化并注册到 spring 容器中。 - 依赖收集 (collection)：
当初始化主配置类yudaowebsecurityconfigureradapter时，@resource private list<authorizerequestscustomizer> list这行代码会触发 spring 去容器里查找所有类型为authorizerequestscustomizer的 bean，并将它们装进一个 list 集合中。 - 规则应用 (application)：
在构建securityfilterchain时，代码遍历这个 list，依次调用customize()方法。 - 最终生效 (finalization)：
spring security 将这些分散定义的规则合并成一个完整的requestmatcher链条。
四、 优缺点总结
优点
- 开闭原则 (open/closed principle)：对扩展开放（新增模块只需加新 bean），对修改关闭（无需动主配置）。
- 高内聚：业务模块的权限规则写在业务模块内部，代码物理距离更近，更容易理解。
- 灵活性：通过
ordered接口，可以精确控制规则的生效顺序（例如：通用黑名单规则优先级最高，普通业务规则优先级居中，兜底规则优先级最低）。
注意事项
- 顺序问题：spring security 的匹配原则是 “先匹配生效（first match wins）”。如果一个优先级高的 customizer 配置了
/**->permitall，那么后面所有模块的规则都会失效。因此使用ordered进行顺序管理至关重要。
到此这篇关于spring security 进阶：基于 customizer 的分布式权限配置架构设计的文章就介绍到这了,更多相关spring security customizer分布式权限配置内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论