按理說自己 new 出來的對(duì)象和容器是沒有關(guān)系的，但是在 Spring Security 框架中也 new 了很多對(duì)象出來，一樣也可以被容器管理，那么它是怎么做到的?

[[330985]]

今天來和大家聊一個(gè)略微冷門的話題，Spring Security 中的 ObjectPostProcessor 到底是干嘛用的?

如果大家研究過松哥的微人事項(xiàng)目，就會(huì)發(fā)現(xiàn)里邊的動(dòng)態(tài)權(quán)限配置有這樣一行代碼：

@Configuration 
public class SecurityConfig extends WebSecurityConfigurerAdapter { 
 
    @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() 
                ... 
    } 
} 

這里的 withObjectPostProcessor 到底該如何理解?

今天松哥就來和大家揭開謎題。

1.ObjectPostProcessor 的作用

我們先來看下 ObjectPostProcessor 到底有啥作用，先來看一下這個(gè)接口的定義：

package org.springframework.security.config.annotation; 
public interface ObjectPostProcessor<T> { 
 <O extends T> O postProcess(O object); 
} 

接口中就只有一個(gè) postProcess 方法。

我們?cè)賮砜纯?ObjectPostProcessor 的繼承關(guān)系：

兩個(gè)比較重要的實(shí)現(xiàn)類，其中 AutowireBeanFactoryObjectPostProcessor 值得一說，來看下 AutowireBeanFactoryObjectPostProcessor 的定義：

final class AutowireBeanFactoryObjectPostProcessor 
  implements ObjectPostProcessor<Object>, DisposableBean, SmartInitializingSingleton { 
 AutowireBeanFactoryObjectPostProcessor( 
   AutowireCapableBeanFactory autowireBeanFactory) { 
  this.autowireBeanFactory = autowireBeanFactory; 
 } 
 @SuppressWarnings("unchecked") 
 public <T> T postProcess(T object) { 
  if (object == null) { 
   return null; 
  } 
  T result = null; 
  try { 
   result = (T) this.autowireBeanFactory.initializeBean(object, 
     object.toString()); 
  } 
  catch (RuntimeException e) { 
   Class<?> type = object.getClass(); 
   throw new RuntimeException( 
     "Could not postProcess " + object + " of type " + type, e); 
  } 
  this.autowireBeanFactory.autowireBean(object); 
  if (result instanceof DisposableBean) { 
   this.disposableBeans.add((DisposableBean) result); 
  } 
  if (result instanceof SmartInitializingSingleton) { 
   this.smartSingletons.add((SmartInitializingSingleton) result); 
  } 
  return result; 
 } 
} 

AutowireBeanFactoryObjectPostProcessor 的源碼很好理解：

1. 首先在構(gòu)建 AutowireBeanFactoryObjectPostProcessor 對(duì)象時(shí)，傳入了一個(gè) AutowireCapableBeanFactory 對(duì)象，看過 Spring 源碼的小伙伴就知道，AutowireCapableBeanFactory 可以幫助我們手動(dòng)的將一個(gè)實(shí)例注冊(cè)到 Spring 容器中。
2. 在 postProcess 方法中，就是具體的注冊(cè)邏輯了，都很簡單，我就不再贅述。

由此可見，ObjectPostProcessor 的主要作用就是手動(dòng)注冊(cè)實(shí)例到 Spring 容器中去(并且讓實(shí)例走一遍 Bean 的生命周期)。

正常來說，我們項(xiàng)目中的 Bean 都是通過自動(dòng)掃描注入到 Spring 容器中去的，然而在 Spring Security 框架中，有大量的代碼不是通過自動(dòng)掃描注入到 Spring 容器中去的，而是直接 new 出來的，這樣做的本意是為了簡化項(xiàng)目配置。

這些直接 new 出來的代碼，如果想被 Spring 容器管理該怎么辦呢?那就得 ObjectPostProcessor 出場了。

2.框架舉例

接下來我隨便舉幾個(gè)框架中對(duì)象 new 的例子，大家看一下 ObjectPostProcessor 的作用：

HttpSecurity 初始化代碼(WebSecurityConfigurerAdapter#getHttp)：

protected final HttpSecurity getHttp() throws Exception { 
 if (http != null) { 
  return http; 
 } 
    ... 
    ... 
 http = new HttpSecurity(objectPostProcessor, authenticationBuilder, 
   sharedObjects); 
 ... 
    ... 
} 

WebSecurity 初始化代碼(WebSecurityConfiguration#setFilterChainProxySecurityConfigurer)：

public void setFilterChainProxySecurityConfigurer( 
  ObjectPostProcessor<Object> objectPostProcessor, 
  @Value("#{@autowiredWebSecurityConfigurersIgnoreParents.getWebSecurityConfigurers()}") List<SecurityConfigurer<Filter, WebSecurity>> webSecurityConfigurers) 
  throws Exception { 
 webSecurity = objectPostProcessor 
   .postProcess(new WebSecurity(objectPostProcessor)); 
    ... 
    ... 
} 

Spring Security 框架源碼中，隨處可見手動(dòng)裝配。Spring Security 中，過濾器鏈中的所有過濾器都是通過對(duì)應(yīng)的 xxxConfigure 來進(jìn)行配置的，而所有的 xxxConfigure 都是繼承自 SecurityConfigurerAdapter，如下：

而在這些 xxxConfigure 的 configure 方法中，無一例外的都會(huì)讓他們各自配置的管理器去 Spring 容器中走一圈，例如 AbstractAuthenticationFilterConfigurer#configure 方法：

public void configure(B http) throws Exception { 
 ... 
    ... 
 F filter = postProcess(authFilter); 
 http.addFilter(filter); 
} 

其他的 xxxConfigurer#configure 方法也都有類似的實(shí)現(xiàn)，小伙伴們可以自行查看，我就不再贅述了。

3.為什么這樣

直接將 Bean 通過自動(dòng)掃描注冊(cè)到 Spring 容器不好嗎?為什么要搞成這個(gè)樣子?

在 Spring Security 中，由于框架本身大量采用了 Java 配置，并且沒有將對(duì)象的各個(gè)屬性都暴露出來，這樣做的本意是為了簡化配置。然而這樣帶來的一個(gè)問題就是需要我們手動(dòng)將 Bean 注冊(cè)到 Spring 容器中去，ObjectPostProcessor 就是為了解決該問題。

一旦將 Bean 注冊(cè)到 Spring 容器中了，我們就有辦法去增強(qiáng)一個(gè) Bean 的功能，或者需修改一個(gè) Bean 的屬性。

例如一開始提到的動(dòng)態(tài)權(quán)限配置代碼：

@Configuration 
public class SecurityConfig extends WebSecurityConfigurerAdapter { 
 
    @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() 
                ... 
    } 
} 

權(quán)限管理本身是由 FilterSecurityInterceptor 控制的，系統(tǒng)默認(rèn)的 FilterSecurityInterceptor 已經(jīng)創(chuàng)建好了，而且我也沒辦法修改它的屬性，那么怎么辦呢?我們可以利用 withObjectPostProcessor 方法，去修改 FilterSecurityInterceptor 中的相關(guān)屬性。

上面這個(gè)配置生效的原因之一是因?yàn)?FilterSecurityInterceptor 在創(chuàng)建成功后，會(huì)重走一遍 postProcess 方法，這里通過重寫 postProcess 方法就能實(shí)現(xiàn)屬性修改，我們可以看下配置 FilterSecurityInterceptor 的方法(AbstractInterceptUrlConfigurer#configure)：

abstract class AbstractInterceptUrlConfigurer<C extends AbstractInterceptUrlConfigurer<C, H>, H extends HttpSecurityBuilder<H>> 
  extends AbstractHttpConfigurer<C, H> { 
 @Override 
 public void configure(H http) throws Exception { 
  FilterInvocationSecurityMetadataSource metadataSource = createMetadataSource(http); 
  if (metadataSource == null) { 
   return; 
  } 
  FilterSecurityInterceptor securityInterceptor = createFilterSecurityInterceptor( 
    http, metadataSource, http.getSharedObject(AuthenticationManager.class)); 
  if (filterSecurityInterceptorOncePerRequest != null) { 
   securityInterceptor 
     .setObserveOncePerRequest(filterSecurityInterceptorOncePerRequest); 
  } 
  securityInterceptor = postProcess(securityInterceptor); 
  http.addFilter(securityInterceptor); 
  http.setSharedObject(FilterSecurityInterceptor.class, securityInterceptor); 
 } 
} 

可以看到，securityInterceptor 對(duì)象創(chuàng)建成功后，還是會(huì)去 postProcess 方法中走一遭。

看懂了上面的代碼，接下來我再舉一個(gè)例子小伙伴們應(yīng)該一下就能明白：

@Configuration 
public class SecurityConfig extends WebSecurityConfigurerAdapter { 
 
    @Override 
    protected void configure(HttpSecurity http) throws Exception { 
        http.authorizeRequests() 
                .antMatchers("/admin/**").hasRole("admin") 
                ... 
                .and() 
                .formLogin() 
                .withObjectPostProcessor(new ObjectPostProcessor<UsernamePasswordAuthenticationFilter>() { 
                    @Override 
                    public <O extends UsernamePasswordAuthenticationFilter> O postProcess(O object) { 
                        object.setUsernameParameter("name"); 
                        return object; 
                    } 
                }) 
                ... 
    } 
} 

在這里，我把配置好的 UsernamePasswordAuthenticationFilter 過濾器再拎出來，修改一下用戶名的 key(正常來說，修改用戶名的 key 不用這么麻煩，這里主要是給大家演示 ObjectPostProcessor 的效果)，修改完成后，以后用戶登錄時(shí)，用戶名就不是 username 而是 name 了。

4.小結(jié)

好了，只要小伙伴們掌握了上面的用法，以后在 Spring Security 中，如果想修改某一個(gè)對(duì)象的屬性，但是卻不知道從哪里下手，那么不妨試試 withObjectPostProcessor!

本文轉(zhuǎn)載自微信公眾號(hào)「江南一點(diǎn)雨」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系江南一點(diǎn)雨公眾號(hào)。