目錄前言傳統AOP實現擴展Interceptor實現擴展ArgumentResolver實現擴展Filter擴展小結前言

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

好久沒輸出了，于是挑一個方面總結一下，希望在梳理過程中再了解一些其他的東西。由于 Java 繁榮的生態，下面每一個模塊都有大量的文章專門講述。所以我選了另外一個角度，從實際問題出發，將這些分散的知識串聯起來，各位可以作為一個綜述來看。各個模塊的極致詳細介紹，大家可以去翻官方文檔或看網絡上的其他博客。

需求很簡單清晰，跟產品們提的妖艷需求一點也不一樣：在我們的 web 框架里添加一個通用的 appkey 白名單校驗功能，希望它的擴展性更好一些。

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

傳統AOP

對于這種需求，首先想到的當然是 Spring-boot 提供的 AOP 接口，只需要在 Controller 方法前添加切點，然后再對切點進行處理即可。

實現

其使用步驟如下：

使用 @Aspect 聲明一下切面類 WhitelistAspect； 在切面類內添加一個切點 whitelistPointcut()，為了實現此切點靈活可裝配的能力，這里不使用 execution 全部攔截，而是添加一個注解 @Whitelist，被注解的方法才會校驗白名單。 在切面類中使用 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() { } }

在Controller方法上添加 @Whitelist 注解實現功能。

擴展

本例中使用了 注解 來聲明切點，并且我實現了通過注解參數來聲明要校驗的白名單，如果之后還需要添加其他白名單的話，如通過 UID 來校驗，則可以為此注解添加 uid() 等方法，實現自定義校驗。

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

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

Interceptor

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

實現

實現步驟如下：

定義攔截器類 AppkeyInterceptor 類并實現 HandlerInterceptor 接口。 實現其 preHandle() 方法； 在 preHandle 方法內通過注解和參數判斷是否需要攔截請求，攔截請求時接口返回 false； 在自定義的 WebMvcConfigurerAdapter 類內注冊此攔截器；

AppkeyInterceptor 類如下：

@Componentpublic 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 路徑下。

@Configurationpublic 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 接口。

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

實現的 AuthParamResolver 類如下：

@Componentpublic 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內配置：

@Configurationpublic 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 也需要顯示配置：

@Configurationpublic 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 被攔截了自然不需要后續再進行處理，然后是 參數解析器，最后才是 切面的切點。我將四種方式在一個項目內全部實現后，輸出日志也證明了這個結論。

到此這篇關于Springboot實現通用Auth認證的幾種方式的文章就介紹到這了,更多相關Springboot 通用Auth認證 內容請搜索好吧啦網以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持好吧啦網！