Spring-boot中實現通用Auth認證，有哪幾種方式？

前言

最近一直被無盡的業務需求淹沒，沒時間喘息，終於接到一個能讓我突破代碼溫馨區的活兒，解決它的過程很是曲折，一度讓我懷疑人生，不過收穫也很大，代碼方面不明顯，但感受本身抹掉了 java、Tomcat、Spring 一直擋在我眼前的一層紗。對它們的理解上了一個新的層次。

很久沒輸出了，因而挑一個方面總結一下，但願在梳理過程當中再瞭解一些其餘的東西。因爲 Java 繁榮的生態，下面每個模塊都有大量的文章專門講述。因此我選了另一個角度，從實際問題出發，將這些分散的知識串聯起來，各位能夠做爲一個綜述來看。各個模塊的極致詳細介紹，你們能夠去翻官方文檔或看網絡上的其餘博客。另外關注：碼猿技術專欄，在後臺回覆：「面試寶典」能夠獲取，高清PDF最新版3625頁互聯網大廠面試題。

需求很簡單清晰，跟產品們提的妖豔需求一點也不同：在咱們的 web 框架裏添加一個通用的 appkey 白名單校驗功能，但願它的擴展性更好一些。

這個 web 框架是部門前驅者基於 spring-boot 實現的，介於業務和 Spring 框架之間，作一些偏向於業務的通用性功能，如 日誌輸出、功能開關、通用參數解析等。日常是對業務透明的，最近一直忙於把需求作好，代碼寫好，甚至從沒注意過它的存在。

傳統AOP

---

對於這種需求，首先想到的固然是 Spring-boot 提供的 AOP 接口，只須要在 Controller 方法前添加切點，而後再對切點進行處理便可。

實現

其使用步驟以下：

1. 使用 @Aspect 聲明一下切面類 WhitelistAspect；
2. 在切面類內添加一個切點 whitelistPointcut()，爲了實現此切點靈活可裝配的能力，這裏不使用 execution 所有攔截，而是添加一個註解 @Whitelist，被註解的方法纔會校驗白名單。
3. 在切面類中使用 spring 的 AOP 註解 @Before 聲明一個通知方法 checkWhitelist() 在 Controller 方法被執行以前校驗白名單。

切面類僞代碼以下：

@Aspect
  public class WhitelistAspect {

    @Before(value = "whitelistPointcut() && @annotation(whitelist)")
    public void checkAppkeyWhitelist(JoinPoint joinPoint, Whitelist whitelist) {
        checkWhitelist();
        // 可以使用 joinPoint.getArgs() 獲取Controller方法的參數
        // 可使用 whitelist 變量獲取註解參數
    }

    @Pointcut("@annotation(com.zhenbianshu.Whitelist)")
    public void whitelistPointCut() {
    }
  }

複製代碼

4. 在Controller方法上添加 @Whitelist 註解實現功能。

擴展

本例中使用了 註解 來聲明切點，而且我實現了經過註解參數來聲明要校驗的白名單，若是以後還須要添加其餘白名單的話，如經過 UID 來校驗，則能夠爲此註解添加 uid() 等方法，實現自定義校驗。

此外，spring 的 AOP 還支持 execution（執行方法） 、bean（匹配特定名稱的 Bean 對象的執行方法）等切點聲明方法和 @Around（在目標函數執行中執行） 、@After（方法執行後） 等通知方法。

如此，功能已經實現了，但領導並不滿意=_=，緣由是項目中 AOP 用得太多了，都用濫了，建議我換一種方式。嗯，只好搞起。另外關注：碼猿技術專欄，在後臺回覆：「面試寶典」能夠獲取，高清PDF最新版3625頁互聯網大廠面試題。

Interceptor

---

Spring 的 攔截器(Interceptor) 實現這個功能也很是合適。顧名思義，攔截器用於在 Controller 內 Action 被執行前經過一些參數判斷是否要執行此方法，要實現一個攔截器，能夠實現 Spring 的 HandlerInterceptor 接口。

實現

實現步驟以下：

1. 定義攔截器類 AppkeyInterceptor 類並實現 HandlerInterceptor 接口。
2. 實現其 preHandle() 方法；
3. 在 preHandle 方法內經過註解和參數判斷是否須要攔截請求，攔截請求時接口返回 false；
4. 在自定義的 WebMvcConfigurerAdapter 類內註冊此攔截器；

AppkeyInterceptor 類以下：

@Component
public class WhitelistInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        Whitelist whitelist = ((HandlerMethod) handler).getMethodAnnotation(Whitelist.class);
        // whitelist.values(); 經過 request 獲取請求參數，經過 whitelist 變量獲取註解參數
        return true;
    }

    @Override
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
  // 方法在Controller方法執行結束後執行
    }

    @Override
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
  // 在view視圖渲染完成後執行
    }
}
複製代碼

擴展

要啓用 攔截器還要顯式配置它啓用，這裏咱們使用 WebMvcConfigurerAdapter 對它進行配置。須要注意，繼承它的的 MvcConfiguration 須要在 ComponentScan 路徑下。

@Configuration
public class MvcConfiguration extends WebMvcConfigurerAdapter {
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new WhitelistInterceptor()).addPathPatterns("/*").order(1);
        // 這裏能夠配置攔截器啓用的 path 的順序，在有多個攔截器存在時，任一攔截器返回 false 都會使後續的請求方法再也不執行
    }
}
複製代碼

還須要注意，攔截器執行成功後響應碼爲 200，但響應數據爲空。

當使用攔截器實現功能後，領導終於祭出大招了：咱們已經有一個 Auth 參數了，appkey 能夠從 Auth 參數裏取到，能夠把在不在白名單做爲 Auth 的一種方式，爲何不在 Auth 時校驗？emmm… 吐血中。

ArgumentResolver

---

參數解析器是 Spring 提供的用於解析自定義參數的工具，咱們經常使用的 @RequestParam 註解就有它的影子，使用它，咱們能夠將參數在進入Controller Action以前就組合成咱們想要的樣子。Spring 會維護一個 ResolverList， 在請求到達時，Spring 發現有自定義類型參數（非基本類型）， 會依次嘗試這些 Resolver，直到有一個 Resolver 能解析須要的參數。要實現一個參數解析器，須要實現 HandlerMethodArgumentResolver 接口。

實現

1. 定義自定義參數類型 AuthParam，類內有 appkey 相關字段；
2. 定義 AuthParamResolver 並實現 HandlerMethodArgumentResolver 接口；
3. 實現 supportsParameter() 接口方法將 AuthParam 與 AuthParamResolver 適配起來；
4. 實現 resolveArgument() 接口方法解析 reqest 對象生成 AuthParam 對象，並在此校驗 AuthParam ，確認 appkey 是否在白名單內；
5. 在 Controller Action 方法上簽名內添加 AuthParam 參數以啓用此 Resolver;

實現的 AuthParamResolver 類以下：

@Component
public class AuthParamResolver implements HandlerMethodArgumentResolver {

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        return parameter.getParameterType().equals(AuthParam.class);
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
        Whitelist whitelist = parameter.getMethodAnnotation(Whitelist.class);
        // 經過 webRequest 和 whitelist 校驗白名單
        return new AuthParam();
    }
}
複製代碼

擴展

固然，使用參數解析器也須要單獨配置，咱們一樣在 WebMvcConfigurerAdapter內配置：

@Configuration
public class MvcConfiguration extends WebMvcConfigurerAdapter {

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> argumentResolvers) {
        argumentResolvers.add(new AuthParamResolver());
    }
}

複製代碼

此次實現完了，我還有些不放心，因而在網上查找是否還有其餘方式能夠實現此功能，發現常見的還有 Filter。

Filter

---

Filter 並非 Spring 提供的，它是在 Servlet 規範中定義的，是 Servlet 容器支持的。被 Filter 過濾的請求，不會派發到 Spring 容器中。它的實現也比較簡單，實現 javax.servlet.Filter接口便可。

因爲不在 Spring 容器中，Filter 獲取不到 Spring 容器的資源，只能使用原生 Java 的 ServletRequest 和 ServletResponse 來獲取請求參數。

另外，在一個 Filter 中要顯示調用 FilterChain 的 doFilter 方法，否則認爲請求被攔截。實現相似：

public class WhitelistFilter implements javax.servlet.Filter {

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
  // 初始化後被調用一次
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
     // 判斷是否須要攔截
       chain.doFilter(request, response); // 請求經過要顯示調用
    }

    @Override
    public void destroy() {
     // 被銷燬時調用一次
    }
}
複製代碼

擴展

Filter 也須要顯示配置：

@Configuration
public class FilterConfiguration {

    @Bean
    public FilterRegistrationBean someFilterRegistration() {
        FilterRegistrationBean registration = new FilterRegistrationBean();
        registration.setFilter(new WhitelistFilter());
        registration.addUrlPatterns("/*");
        registration.setName("whitelistFilter");
        registration.setOrder(1); // 設置過濾器被調用的順序
        return registration;
    }
}

複製代碼

小結

---

四種實現方式都有其適合的場景，那麼它們之間的調用順序如何呢？

Filter 是 Servlet 實現的，天然是最早被調用，後續被調用的是 Interceptor 被攔截了天然不須要後續再進行處理，而後是 參數解析器，最後纔是 切面的切點。我將四種方式在一個項目內所有實現後，輸出日誌也證實了這個結論。

另外，做者已經完成了兩個專欄的文章Mybatis進階、Spring Boot 進階 ，已經將專欄文章整理成書，有須要的公衆號回覆關鍵詞Mybatis 進階、Spring Boot 進階免費獲取。

跳出具體實現，轉身來看這些實現，其實都有一些面向切面的影子。因爲以前本身的編程方式更偏向於面向過程編程，在使用 Java 面向對象後對比 AOP 和 面向過程當中的勾子，有些感悟，改日寫文整理一下。