認證鑑權與API權限控制在微服務架構中的設計與實現（四）

引言：本文系《認證鑑權與API權限控制在微服務架構中的設計與實現》系列的完結篇，前面三篇已經將認證鑑權與API權限控制的流程和主要細節講解完。本文比較長，對這個系列進行收尾，主要內容包括對授權和鑑權流程之外的endpoint以及Spring Security過濾器部分踩坑的經歷。歡迎閱讀本系列文章。

1. 前文回顧

首先還是照例對前文進行回顧。在第一篇認證鑑權與API權限控制在微服務架構中的設計與實現（一）介紹了該項目的背景以及技術調研與最後選型。第二篇認證鑑權與API權限控制在微服務架構中的設計與實現（二）畫出了簡要的登錄和校驗的流程圖，並重點講解了用戶身份的認證與token發放的具體實現。第三篇認證鑑權與API權限控制在微服務架構中的設計與實現（三）先介紹了資源服務器配置，以及其中涉及的配置類，後面重點講解了token以及API級別的鑑權。

本文將會講解剩餘的兩個內置端點：註銷和刷新token。註銷token端點的處理與Spring Security默認提供的有些’/logout’有些區別，不僅清空SpringSecurityContextHolder中的信息，還要增加對存儲token的清空。另一個刷新token端點其實和之前的請求授權是一樣的API，只是參數中的grant_type不一樣。

除了以上兩個內置端點，後面將會重點講下幾種Spring Security過濾器。API級別的操作權限校驗本來設想是通過Spring Security的過濾器實現，特地把這邊學習了一遍，踩了一遍坑。

最後是本系列的總結，並對於存在的不足和後續工作進行論述。

2. 其他端點

2.1 註銷端點

在第一篇中提到了Auth系統內置的註銷端點 /logout，如果還記得第三篇資源服務器的配置，下面的關於/logout配置一定不陌生。

//...

.and().logout()

.logoutUrl("/logout")

.clearAuthentication(true)

.logoutSuccessHandler(new HttpStatusReturningLogoutSuccessHandler())

.addLogoutHandler(customLogoutHandler());

上面配置的主要作用是：

設置註銷的URL
清空Authentication信息
設置註銷成功的處理方式
設置自定義的註銷處理方式

當然在LogoutConfigurer中還有更多的設置選項，筆者此處列出項目所需要的配置項。這些配置項圍繞着LogoutFilter過濾器。順帶講一下Spring Security的過濾器。其使用了springSecurityFillterChian作爲了安全過濾的入口，各種過濾器按順序具體如下：

SecurityContextPersistenceFilter：與SecurityContext安全上下文信息有關

HeaderWriterFilter：給http響應添加一些Header

CsrfFilter：防止csrf攻擊，默認開啓

LogoutFilter：處理註銷的過濾器

UsernamePasswordAuthenticationFilter：表單認證過濾器

RequestCacheAwareFilter：緩存request請求

SecurityContextHolderAwareRequestFilter：此過濾器對ServletRequest進行了一次包裝，使得request具有更加豐富的API

AnonymousAuthenticationFilter：匿名身份過濾器

SessionManagementFilter：session相關的過濾器，常用來防止session-fixation protection attack，以及限制同一用戶開啓多個會話的數量

ExceptionTranslationFilter：異常處理過濾器

FilterSecurityInterceptor：web應用安全的關鍵Filter

各種過濾器簡單標註了作用，在下一節重點講其中的幾個過濾器。註銷過濾器排在靠前的位置，我們一起看下LogoutFilter的UML類圖。

logoutFilter類圖

類圖和我們之前配置時的思路是一致的，HttpSecurity創建了LogoutConfigurer，我們在這邊配置了LogoutConfigurer的一些屬性。同時LogoutConfigurer根據這些屬性創建了LogoutFilter。

LogoutConfigurer的配置，第一和第二點就不用再詳細解釋了，一個是設置端點，另一個是清空認證信息。
對於第三點，配置註銷成功的處理方式。由於項目是前後端分離，客戶端只需要知道執行成功該API接口的狀態，並不用返回具體的頁面或者繼續向下傳遞請求。因此，這邊配置了默認的HttpStatusReturningLogoutSuccessHandler，成功直接返回狀態碼200。
對於第四點配置，自定義註銷處理的方法。這邊需要藉助TokenStore，對token進行操作。TokenStore在之前文章的配置中已經講過，使用的是JdbcTokenStore。首先校驗請求的合法性，如果合法則對其進行操作，先後移除refreshToken和existingAccessToken。

public class CustomLogoutHandler implements LogoutHandler {

//...

@Override

public void logout(HttpServletRequest request, HttpServletResponse response, Authentication authentication) {

//確定注入了tokenStore

Assert.notNull(tokenStore, "tokenStore must be set");

//獲取頭部的認證信息

String token = request.getHeader("Authorization");

Assert.hasText(token, "token must be set");

//校驗token是否符合JwtBearer格式

if (isJwtBearerToken(token)) {

token = token.substring(6);

OAuth2AccessToken existingAccessToken = tokenStore.readAccessToken(token);

OAuth2RefreshToken refreshToken;

if (existingAccessToken != null) {

if (existingAccessToken.getRefreshToken() != null) {

LOGGER.info("remove refreshToken!", existingAccessToken.getRefreshToken());

refreshToken = existingAccessToken.getRefreshToken();

tokenStore.removeRefreshToken(refreshToken);

}

LOGGER.info("remove existingAccessToken!", existingAccessToken);

tokenStore.removeAccessToken(existingAccessToken);

}

return;

} else {

throw new BadClientCredentialsException();

}

}

//...

}

執行如下請求：

method: get

url: http://localhost:9000/logout

header:{Authorization: Basic ZnJvbnRlbmQ6ZnJvbnRlbmQ=}

註銷成功則會返回200，將token和SecurityContextHolder進行清空。

2.2 刷新端點

在第一篇就已經講過，由於token的時效一般不會很長，而refresh token一般週期會很長，爲了不影響用戶的體驗，可以使用refresh token去動態的刷新token。刷新token主要與RefreshTokenGranter有關，CompositeTokenGranter管理一個List列表，每一種grantType對應一個具體的真正授權者，refresh_ token對應的granter就是RefreshTokenGranter，而granter內部則是通過grantType來區分是否是各自的授權類型。執行如下請求：

method: post

url: http://localhost:12000/oauth/token?grant_type=refresh_token&refresh_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJYLUtFRVRTLVVzZXJJZCI6ImQ2NDQ4YzI0LTNjNGMtNGI4MC04MzcyLWMyZDYxODY4ZjhjNiIsInVzZXJfbmFtZSI6ImtlZXRzIiwic2NvcGUiOlsiYWxsIl0sImF0aSI6ImJhZDcyYjE5LWQ5ZjMtNDkwMi1hZmZhLTA0MzBlN2RiNzllZCIsImV4cCI6MTUxMDk5NjU1NiwianRpIjoiYWE0MWY1MjctODE3YS00N2UyLWFhOTgtZjNlMDZmNmY0NTZlIiwiY2xpZW50X2lkIjoiZnJvbnRlbmQifQ.mICT1-lxOAqOU9M-Ud7wZBb4tTux6OQWouQJ2nn1DeE

header:{Authorization: Basic ZnJvbnRlbmQ6ZnJvbnRlbmQ=}

在refresh_ token正確的情況下，其返回的response和/oauth/token得到正常的響應是一樣的。具體的代碼可以參閱第二篇的講解。

3. `Spring Security`過濾器

在上一節我們介紹了內置的兩個端點的實現細節，還提到了HttpSecurity過濾器，因爲註銷端點的實現就是通過過濾器的作用。核心的過濾器主要有：

FilterSecurityInterceptor

UsernamePasswordAuthenticationFilter

SecurityContextPersistenceFilter

ExceptionTranslationFilter

這一節將重點介紹其中的UsernamePasswordAuthenticationFilter和FilterSecurityInterceptor。

3.1 `UsernamePasswordAuthenticationFilter`

筆者在剛開始看關於過濾器的文章，對於UsernamePasswordAuthenticationFilter有不少的文章介紹。如果只是引入Spring-Security，必然會與/login端點熟悉。SpringSecurity強制要求我們的表單登錄頁面必須是以POST方式向/login URL提交請求，而且要求用戶名和密碼的參數名必須是username和password。如果不符合，則不能正常工作。原因在於，當我們調用了HttpSecurity對象的formLogin方法時，其最終會給我們註冊一個過濾器UsernamePasswordAuthenticationFilter。看一下該過濾器的源碼。

public class UsernamePasswordAuthenticationFilter extends

AbstractAuthenticationProcessingFilter {

//用戶名、密碼

public static final String SPRING_SECURITY_FORM_USERNAME_KEY = "username";

public static final String SPRING_SECURITY_FORM_PASSWORD_KEY = "password";

private String usernameParameter = SPRING_SECURITY_FORM_USERNAME_KEY;

private String passwordParameter = SPRING_SECURITY_FORM_PASSWORD_KEY;

private boolean postOnly = true;

//post請求/login

public UsernamePasswordAuthenticationFilter() {

super(new AntPathRequestMatcher("/login", "POST"));

}

//實現抽象類AbstractAuthenticationProcessingFilter的抽象方法，嘗試驗證

public Authentication attemptAuthentication(HttpServletRequest request,

HttpServletResponse response) throws AuthenticationException {

if (postOnly && !request.getMethod().equals("POST")) {

throw new AuthenticationServiceException(

"Authentication method not supported: " + request.getMethod());

}

String username = obtainUsername(request);

String password = obtainPassword(request);

//···

username = username.trim();

UsernamePasswordAuthenticationToken authRequest = new UsernamePasswordAuthenticationToken(

username, password);

//···

return this.getAuthenticationManager().authenticate(authRequest);

}

}

public abstract class AbstractAuthenticationProcessingFilter extends GenericFilterBean

implements ApplicationEventPublisherAware, MessageSourceAware {

//...

//調用requiresAuthentication，判斷請求是否需要authentication，如果需要則調用attemptAuthentication

//有三種結果可能返回：

//1.Authentication對象

//2. AuthenticationException

//3. Authentication對象爲空

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain)

throws IOException, ServletException {

HttpServletRequest request = (HttpServletRequest) req;

HttpServletResponse response = (HttpServletResponse) res;

//不需要校驗，繼續傳遞

if (!requiresAuthentication(request, response)) {

chain.doFilter(request, response);

return;

}

Authentication authResult;

try {

authResult = attemptAuthentication(request, response);

if (authResult == null) {

// return immediately as subclass has indicated that it hasn't completed authentication

return;

}

sessionStrategy.onAuthentication(authResult, request, response);

}

//...

catch (AuthenticationException failed) {

// Authentication failed

unsuccessfulAuthentication(request, response, failed);

return;

}

// Authentication success

if (continueChainBeforeSuccessfulAuthentication) {

chain.doFilter(request, response);

}

successfulAuthentication(request, response, chain, authResult);

}

//實際執行的authentication，繼承類必須實現該抽象方法

public abstract Authentication attemptAuthentication(HttpServletRequest request,

HttpServletResponse response) throws AuthenticationException, IOException,

ServletException;

//成功authentication的默認行爲

protected void successfulAuthentication(HttpServletRequest request,

HttpServletResponse response, FilterChain chain, Authentication authResult)

throws IOException, ServletException {

//...

}

//失敗authentication的默認行爲

protected void unsuccessfulAuthentication(HttpServletRequest request,

HttpServletResponse response, AuthenticationException failed)

throws IOException, ServletException {

//...

}

...

//設置AuthenticationManager

public void setAuthenticationManager(AuthenticationManager authenticationManager) {

this.authenticationManager = authenticationManager;

}

...

}

UsernamePasswordAuthenticationFilter因爲繼承了AbstractAuthenticationProcessingFilter才擁有過濾器的功能。AbstractAuthenticationProcessingFilter要求設置一個authenticationManager，authenticationManager的實現類將實際處理請求的認證。AbstractAuthenticationProcessingFilter將攔截符合過濾規則的request，並試圖執行認證。子類必須實現 attemptAuthentication 方法，這個方法執行具體的認證。
認證之後的處理和上註銷的差不多。如果認證成功，將會把返回的Authentication對象存放在SecurityContext，並調用SuccessHandler，也可以設置指定的URL和指定自定義的處SuccessHandler。如果認證失敗，默認會返回401代碼給客戶端，也可以設置URL，指定自定義的處理FailureHandler。

基於UsernamePasswordAuthenticationFilter自定義的AuthenticationFilte還是挺多案例的，這邊推薦一篇博文Spring Security(五)–動手實現一個IP_Login，寫得比較詳細。

3.2 `FilterSecurityInterceptor`

FilterSecurityInterceptor是filterchain中比較複雜，也是比較核心的過濾器，主要負責web應用安全授權的工作。首先看下對於自定義的FilterSecurityInterceptor配置。

@Override

public void configure(HttpSecurity http) throws Exception {

...

//添加CustomSecurityFilter，過濾器的順序放在FilterSecurityInterceptor

http.antMatcher("/oauth/check_token").addFilterAt(customSecurityFilter(), FilterSecurityInterceptor.class);

}

//提供實例化的自定義過濾器

@Bean

public CustomSecurityFilter customSecurityFilter() {

return new CustomSecurityFilter();

}

從上述配置可以看到，在FilterSecurityInterceptor的位置註冊了CustomSecurityFilter，對於匹配到/oauth/check_token，則會調用該進入該過濾器。下圖爲FilterSecurityInterceptor的類圖，在其中還添加了CustomSecurityFilter和相關實現的接口的類，方便讀者對比着看。

FilterSecurityInterceptor類圖

CustomSecurityFilter是模仿FilterSecurityInterceptor實現，繼承AbstractSecurityInterceptor和實現Filter接口。整個過程需要依賴AuthenticationManager、AccessDecisionManager和FilterInvocationSecurityMetadataSource。
AuthenticationManager是認證管理器，實現用戶認證的入口；AccessDecisionManager是訪問決策器，決定某個用戶具有的角色，是否有足夠的權限去訪問某個資源；FilterInvocationSecurityMetadataSource是資源源數據定義，即定義某一資源可以被哪些角色訪問。
從上面的類圖中可以看到自定義的CustomSecurityFilter同時又實現了
AccessDecisionManager和FilterInvocationSecurityMetadataSource。分別爲SecureResourceFilterInvocationDefinitionSource和SecurityAccessDecisionManager。下面分析下主要的配置。

//通過一個實現的filter，對HTTP資源進行安全處理

public class FilterSecurityInterceptor extends AbstractSecurityInterceptor implements Filter {

//被filter chain真實調用的方法，通過invoke代理

public void doFilter(ServletRequest request, ServletResponse response,

FilterChain chain) throws IOException, ServletException {

FilterInvocation fi = new FilterInvocation(request, response, chain);

invoke(fi);

}

//代理的方法

public void invoke(FilterInvocation fi) throws IOException, ServletException {

//...省略

}

}

上述代碼是FilterSecurityInterceptor中的實現，具體實現細節就沒列出了，我們這邊重點在於對自定義的實現進行講解。

public class CustomSecurityFilter extends AbstractSecurityInterceptor implements Filter {

@Autowired

SecureResourceFilterInvocationDefinitionSource invocationSource;

@Autowired

private AuthenticationManager authenticationManager;

@Autowired

private SecurityAccessDecisionManager decisionManager;

//設置父類中的屬性

@PostConstruct

public void init() {

super.setAccessDecisionManager(decisionManager);

super.setAuthenticationManager(authenticationManager);

}

//主要的過濾方法，與原來的一致

@Override

public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {

//logger.info("doFilter in Security ");

//構造一個FilterInvocation，封裝request, response, chain

FilterInvocation fi = new FilterInvocation(servletRequest, servletResponse, filterChain);

//beforeInvocation會調用SecureResourceDataSource中的邏輯，類似於aop中的before

InterceptorStatusToken token = super.beforeInvocation(fi);

try {

//執行下一個攔截器

fi.getChain().doFilter(fi.getRequest(), fi.getResponse());

} finally {

//完成後續工作，類似於aop中的after

super.afterInvocation(token, null);

}

}

//...

//資源源數據定義，設置爲自定義的SecureResourceFilterInvocationDefinitionSource

@Override

public SecurityMetadataSource obtainSecurityMetadataSource() {

return invocationSource;

}

}

上面自定義的CustomSecurityFilter，與我們之前的講解是一樣的流程。主要依賴的三個接口都有在實現中實例化注入。看下父類的beforeInvocation方法，其中省略了一些不重要的代碼片段。

protected InterceptorStatusToken beforeInvocation(Object object) {

//根據SecurityMetadataSource獲取配置的權限屬性

Collection<ConfigAttribute> attributes = this.obtainSecurityMetadataSource().getAttributes(object);

//...

//判斷是否需要對認證實體重新認證，默認爲否

Authentication authenticated = authenticateIfRequired();

// Attempt authorization

try {

//決策管理器開始決定是否授權，如果授權失敗，直接拋出AccessDeniedException

this.accessDecisionManager.decide(authenticated, object, attributes);

}

catch (AccessDeniedException accessDeniedException) {

publishEvent(new AuthorizationFailureEvent(object, attributes, authenticated,

accessDeniedException));

throw accessDeniedException;

}

}

上面代碼可以看出，第一步是根據SecurityMetadataSource獲取配置的權限屬性，accessDecisionManager會用到權限列表信息。然後判斷是否需要對認證實體重新認證，默認爲否。第二步是接着決策管理器開始決定是否授權，如果授權失敗，直接拋出AccessDeniedException。

(1). 獲取配置的權限屬性

public class SecureResourceFilterInvocationDefinitionSource implements FilterInvocationSecurityMetadataSource, InitializingBean {

private PathMatcher matcher;

//map保存配置的URL對應的權限集

private static Map<String, Collection<ConfigAttribute>> map = new HashMap<>();

//根據傳入的對象URL進行循環

@Override

public Collection<ConfigAttribute> getAttributes(Object o) throws IllegalArgumentException {

logger.info("getAttributes");

//應該做instanceof

FilterInvocation filterInvocation = (FilterInvocation) o;

//String method = filterInvocation.getHttpRequest().getMethod();

String requestURI = filterInvocation.getRequestUrl();

//循環資源路徑，當訪問的Url和資源路徑url匹配時，返回該Url所需要的權限

for (Iterator<Map.Entry<String, Collection<ConfigAttribute>>> iterator = map.entrySet().iterator(); iter.hasNext(); ) {

Map.Entry<String, Collection<ConfigAttribute>> entry = iterator.next();

String url = entry.getKey();

if (matcher.match(url, requestURI)) {

return map.get(requestURI);

}

}

return null;

}

//...

//設置權限集，即上述的map

@Override

public void afterPropertiesSet() throws Exception {

logger.info("afterPropertiesSet");

//用來匹配訪問資源路徑

this.matcher = new AntPathMatcher();

//可以有多個權限

Collection<ConfigAttribute> atts = new ArrayList<>();

ConfigAttribute c1 = new SecurityConfig("ROLE_ADMIN");

atts.add(c1);

map.put("/oauth/check_token", atts);

}

}

上面是getAttributes()實現的具體細節，將請求的URL取出進行匹配事先設定的受限資源，最後返回需要的權限、角色。系統在啓動的時候就會讀取到配置的map集合，對於攔截到請求進行匹配。代碼中註釋比較詳細，這邊不多說。

(2). 決策管理器

public class SecurityAccessDecisionManager implements AccessDecisionManager {

//...

@Override

public void decide(Authentication authentication, Object o, Collection<ConfigAttribute> collection) throws AccessDeniedException, InsufficientAuthenticationException {

logger.info("decide url and permission");

//集合爲空

if (collection == null) {

return;

}

Iterator<ConfigAttribute> ite = collection.iterator();

//判斷用戶所擁有的權限，是否符合對應的Url權限，如果實現了UserDetailsService，則用戶權限是loadUserByUsername返回用戶所對應的權限

while (ite.hasNext()) {

ConfigAttribute ca = ite.next();

String needRole = ca.getAttribute();

for (GrantedAuthority ga : authentication.getAuthorities()) {

logger.info("GrantedAuthority: {}", ga);

if (needRole.equals(ga.getAuthority())) {

return;

}

}

}

logger.error("AccessDecisionManager: no right!");

throw new AccessDeniedException("no right!");

}

//...

}

上面的代碼是決策管理器的實現，其邏輯也比較簡單，將請求所具有的權限與設定的受限資源所需的進行匹配，如果具有則返回，否則拋出沒有正確的權限異常。默認提供的決策管理器有三種，分別爲AffirmativeBased、ConsensusBased、UnanimousBased，篇幅有限，我們這邊不再擴展了。

補充一下，所具有的權限是通過之前配置的認證方式，有password認證和client認證兩種。我們之前在授權服務器中配置了withClientDetails，所以用frontend身份驗證獲得的權限是我們預先配置在數據庫中的authorities。

4. 總結

Auth系統主要功能是授權認證和鑑權。項目微服務化後，原有的單體應用基於HttpSession認證鑑權不能滿足微服務架構下的需求。每個微服務都需要對訪問進行鑑權，每個微應用都需要明確當前訪問用戶以及其權限，尤其當有多個客戶端，包括web端、移動端等等，單體應用架構下的鑑權方式就不是特別合適了。權限服務作爲基礎的公共服務，也需要微服務化。

筆者的設計中，Auth服務一方面進行授權認證，另一方面是基於token進行身份合法性和API級別的權限校驗。對於某個服務的請求，經過網關會調用Auth服務，對token合法性進行驗證。同時筆者根據當前項目的整體情況，存在部分遺留服務，這些遺留服務又沒有足夠的時間和人力立馬進行微服務改造，而且還需要繼續運行。爲了適配當前新的架構，採取的方案就是對這些遺留服務的操作API，在Auth服務進行API級別的操作權限鑑定。API級別的操作權限校驗需要的上下文信息需要結合業務，與客戶端進行商定，應該在token能取到相應信息，傳遞給Auth服務，不過應儘量減少在header取上下文校驗的信息。

筆者將本次開發Auth系統所涉及的大部分代碼及源碼進行了解析，至於沒有講到的一些內容和細節，讀者可以自行擴展。

5. 不足與後續工作

5.1 存在的不足

API級別操作權限校驗的通用性

(1). 對於API級別操作權限校驗，需要在網關處調用時構造相應的上下文信息。上下文信息基本依賴於 token中的payload，如果信息太多引起token太長，導致每次客戶端的請求頭部長度變長。

(2). 並不是所有的操作接口都能覆蓋到，這個問題是比較嚴重的，根據上下文集合很可能出現好多接口的權限沒法鑑定，最後的結果就是API級別操作權限校驗失敗的是絕對沒有權限訪問該接口，而通過不一定能訪問，因爲該接口涉及到的上下文根本沒法完全得到。我們的項目在現階段，定義的最小上下文集合能勉強覆蓋到，但是對於後面擴增的服務接口真的是不樂觀。

(3). 每個服務的每個接口都在Auth服務註冊其所需要的權限，太過麻煩，Auth服務需要額外維護這樣的信息。
網關處調用Auth服務帶來的系統吞吐量瓶頸

(1). 這個其實很容易理解，Auth服務作爲公共的基礎服務，大多數服務接口都會需要鑑權，Auth服務需要經過複雜。

(2). 網關調用Auth服務，阻塞調用，只有等Auth服務返回校驗結果，纔會做進一步處理。雖說Auth服務可以多實例部署，但是併發量大了之後，其瓶頸明顯可見，嚴重可能會造成整個系統的不可用。

5.2 後續工作

從整個系統設計角度來講，API級別操作權限後期將會分散在各個服務的接口上，由各個接口負責其所需要的權限、身份等。Spring Security對於接口級別的權限校驗也是支持的，之所以採用這樣的做法，也是爲了兼容新服務和遺留的服務，主要是針對遺留服務，新的服務採用的是分散在各個接口之上。
將API級別操作權限分散到各個服務接口之後，相應的能提升Auth服務的響應。網關能夠及時的對請求進行轉發或者拒絕。
API級別操作權限所需要的上下文信息對各個接口真的設計的很複雜，這邊我們確實花了時間，同時管理移動服務的好幾百操作接口所對應的權限，非常煩。！

本文作者： aoho
本文鏈接： http://blueskykong.com/2017/10/26/security4/

認證鑑權與API權限控制在微服務架構中的設計與實現（四）

1. 前文回顧

2. 其他端點

2.1 註銷端點

2.2 刷新端點

3. `Spring Security`過濾器

3.1 `UsernamePasswordAuthenticationFilter`

3.2 `FilterSecurityInterceptor`

4. 總結

5. 不足與後續工作

5.1 存在的不足

5.2 後續工作

【簡寫Mybatis-02】註冊機的實現以及SqlSession處理

手繪二維碼

.NET藉助虛擬網卡實現一個簡單異地組網工具

SpringBoot + Zookeeper的服務註冊與發現

第三方登錄 ---Github

JAVA_HOME路徑配置無效的問題

使用appassembler打包springboot項目時出現的主類無法找到問題

安裝oracle碰到的大坑

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結

認證鑑權與API權限控制在微服務架構中的設計與實現（四）

1. 前文回顧

2. 其他端點

2.1 註銷端點

2.2 刷新端點

3. Spring Security過濾器

3.1 UsernamePasswordAuthenticationFilter

3.2 FilterSecurityInterceptor

4. 總結

5. 不足與後續工作

5.1 存在的不足

5.2 後續工作

3. `Spring Security`過濾器

3.1 `UsernamePasswordAuthenticationFilter`

3.2 `FilterSecurityInterceptor`