一、 背景與痛點(diǎn)

在傳統(tǒng)的 Spring Security 開發(fā)中（尤其是單體大應(yīng)用），我們往往會(huì)在一個(gè)主配置類（如 SecurityConfig）里寫死所有的 URL 權(quán)限規(guī)則：

// 傳統(tǒng)寫法：隨著業(yè)務(wù)增長(zhǎng)，這個(gè)方法會(huì)變成幾百行的“面條代碼”
http.authorizeHttpRequests()
    .requestMatchers("/admin/**").hasRole("ADMIN")
    .requestMatchers("/order/**").hasRole("USER")
    .requestMatchers("/pay/**").permitAll()
    // ... 無(wú)休止的追加 ...

痛點(diǎn)：

1. 嚴(yán)重耦合：基礎(chǔ)架構(gòu)層必須感知所有業(yè)務(wù)模塊的 URL 規(guī)則。
2. 維護(hù)困難：多人開發(fā)時(shí)，大家都在修改同一個(gè)文件，代碼沖突不斷。
3. 擴(kuò)展性差：新增一個(gè)業(yè)務(wù)模塊，必須去改主工程的代碼。

二、 核心架構(gòu)設(shè)計(jì)

為了解決上述問(wèn)題，我們引入了 “插拔式” 的設(shè)計(jì)模式。核心由三個(gè)部分組成：

1. 調(diào)度中心：主配置類（只負(fù)責(zé)調(diào)度，不負(fù)責(zé)具體規(guī)則）。
2. 標(biāo)準(zhǔn)協(xié)議：AuthorizeRequestsCustomizer 抽象類（定義怎么配）。
3. 業(yè)務(wù)實(shí)現(xiàn)：各模塊的 Customizer（具體配什么）。

1. 調(diào)度中心：主 SecurityFilterChain

在主配置類（如 YudaoWebSecurityConfigurerAdapter）中，我們不再硬編碼規(guī)則，而是利用 Spring 的 自動(dòng)注入（Dependency Injection） 特性。

// 1. 注入所有實(shí)現(xiàn)了 Customizer 接口的 Bean
@Resource
private List<AuthorizeRequestsCustomizer> authorizeRequestsCustomizers;
@Bean
protected SecurityFilterChain filterChain(HttpSecurity httpSecurity) throws Exception {
    httpSecurity
        // ... 其他配置 ...
        .authorizeHttpRequests(c -> {
            // 2. 核心邏輯：遍歷所有注入的 Customizer，讓它們自己定義規(guī)則
            authorizeRequestsCustomizers.forEach(customizer -> customizer.customize(c));
            // 3. 兜底規(guī)則（最后執(zhí)行）
            c.anyRequest().authenticated();
        });
    return httpSecurity.build();
}

解析：主配置類變成了一個(gè)“容器”，它根本不知道 /order 需要什么權(quán)限，它只負(fù)責(zé)把話筒交給各個(gè)業(yè)務(wù)模塊，讓模塊自己“發(fā)言”。

2. 標(biāo)準(zhǔn)協(xié)議：AuthorizeRequestsCustomizer

我們需要定義一個(gè)抽象類，既作為統(tǒng)一的接口類型，又可以提供一些通用的工具方法（如 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;
    }
    // 默認(rèn)優(yōu)先級(jí)，業(yè)務(wù)模塊可以通過(guò)重寫此方法調(diào)整自己在過(guò)濾器鏈中的位置
    @Override
    public int getOrder() {
        return 0;
    }
}

3. 業(yè)務(wù)實(shí)現(xiàn)：模塊化的 Customizer

假設(shè)我們有一個(gè) “基礎(chǔ)設(shè)施模塊 (Infra)”，它需要開放 Swagger 文檔和一些監(jiān)控?cái)帱c(diǎn)，我們不需要改主工程，只需在 Infra 模塊內(nèi)部寫一個(gè) Bean：

@Configuration
public class InfraSecurityConfiguration {
    @Bean("infraAuthorizeRequestsCustomizer")
    public AuthorizeRequestsCustomizer infraAuthorizeRequestsCustomizer() {
        return new AuthorizeRequestsCustomizer() {
            @Override
            public void customize(AuthorizeHttpRequestsConfigurer<HttpSecurity>.AuthorizationManagerRequestMatcherRegistry registry) {
                // 定義該模塊獨(dú)有的權(quán)限規(guī)則
                registry.requestMatchers(buildAdminApi("/infra/file/**")).permitAll() // 文件下載免登錄
                        .requestMatchers("/swagger-ui/**").permitAll() // Swagger 免登錄
                        .requestMatchers("/druid/**").hasRole("ADMIN"); // 數(shù)據(jù)庫(kù)監(jiān)控需管理員
            }
            // 可選：如果需要在其他規(guī)則之前生效，可以調(diào)高優(yōu)先級(jí)
            @Override
            public int getOrder() {
                return -10;
            }
        };
    }
}

三、 工作原理深度解析

這個(gè)機(jī)制之所以能工作，依賴于 Spring 容器強(qiáng)大的生命周期管理：

1. 啟動(dòng)掃描 (Scanning)：
   Spring Boot 啟動(dòng)時(shí)，掃描所有加了 @Configuration 的類。
2. Bean 注冊(cè) (Registration)：
   各個(gè)業(yè)務(wù)模塊（Infra, Order, Pay）定義的 AuthorizeRequestsCustomizer 被實(shí)例化并注冊(cè)到 Spring 容器中。
3. 依賴收集 (Collection)：
   當(dāng)初始化主配置類 YudaoWebSecurityConfigurerAdapter 時(shí)，@Resource private List<AuthorizeRequestsCustomizer> list 這行代碼會(huì)觸發(fā) Spring 去容器里查找所有類型為 AuthorizeRequestsCustomizer 的 Bean，并將它們裝進(jìn)一個(gè) List 集合中。
4. 規(guī)則應(yīng)用 (Application)：
   在構(gòu)建 SecurityFilterChain 時(shí)，代碼遍歷這個(gè) List，依次調(diào)用 customize() 方法。
5. 最終生效 (Finalization)：
   Spring Security 將這些分散定義的規(guī)則合并成一個(gè)完整的 RequestMatcher 鏈條。

四、 優(yōu)缺點(diǎn)總結(jié)

優(yōu)點(diǎn)

• 開閉原則 (Open/Closed Principle)：對(duì)擴(kuò)展開放（新增模塊只需加新 Bean），對(duì)修改關(guān)閉（無(wú)需動(dòng)主配置）。
• 高內(nèi)聚：業(yè)務(wù)模塊的權(quán)限規(guī)則寫在業(yè)務(wù)模塊內(nèi)部，代碼物理距離更近，更容易理解。
• 靈活性：通過(guò) Ordered 接口，可以精確控制規(guī)則的生效順序（例如：通用黑名單規(guī)則優(yōu)先級(jí)最高，普通業(yè)務(wù)規(guī)則優(yōu)先級(jí)居中，兜底規(guī)則優(yōu)先級(jí)最低）。

注意事項(xiàng)

• 順序問(wèn)題：Spring Security 的匹配原則是 “先匹配生效（First Match Wins）”。如果一個(gè)優(yōu)先級(jí)高的 Customizer 配置了 /** -> permitAll，那么后面所有模塊的規(guī)則都會(huì)失效。因此使用 Ordered 進(jìn)行順序管理至關(guān)重要。

到此這篇關(guān)于Spring Security 進(jìn)階：基于 Customizer 的分布式權(quán)限配置架構(gòu)設(shè)計(jì)的文章就介紹到這了,更多相關(guān)Spring Security Customizer分布式權(quán)限配置內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論