FilterChainProxy 是一個(gè)代理，真正起作用的是 FilterChainProxy 中 SecurityFilterChain 所包含的各個(gè) Filter ，同時(shí)

這些 Filter 作為 Bean 被 Spring 管理，它們是 Spring Security 核心，各有各的職責(zé)，但他們并不直接處理用戶的 認(rèn)

證 ，也不直接處理用戶的 授權(quán) ，而是把它們交給了認(rèn)證管理器（ AuthenticationManager ）和決策管理器

（ AccessDecisionManager ）進(jìn)行處理，下圖是 FilterChainProxy 相關(guān)類的 UML 圖示。

spring Security 功能的實(shí)現(xiàn)主要是由一系列過濾器鏈相互配合完成。

下面介紹過濾器鏈中主要的幾個(gè)過濾器及其作用：

SecurityContextPersistenceFilter 這個(gè) Filter 是整個(gè)攔截過程的入口和出口（也就是第一個(gè)和最后一個(gè)攔截

器），會在請求開始時(shí)從配置好的 SecurityContextRepository 中獲取 SecurityContext ，然后把它設(shè)置給

SecurityContextHolder 。在請求完成后將 SecurityContextHolder 持有的 SecurityContext 再保存到配置好

的 SecurityContextRepository ，同時(shí)清除 securityContextHolder 所持有的 SecurityContext ；

UsernamePasswordAuthenticationFilter 用于處理來自表單提交的認(rèn)證。該表單必須提供對應(yīng)的用戶名和密

碼，其內(nèi)部還有登錄成功或失敗后進(jìn)行處理的 AuthenticationSuccessHandler 和

AuthenticationFailureHandler ，這些都可以根據(jù)需求做相關(guān)改變；

FilterSecurityInterceptor 是用于保護(hù) web 資源的，使用 AccessDecisionManager 對當(dāng)前用戶進(jìn)行授權(quán)訪問，前

面已經(jīng)詳細(xì)介紹過了；

ExceptionTranslationFilter 能夠捕獲來自 FilterChain 所有的異常，并進(jìn)行處理。但是它只會處理兩類異常：

AuthenticationException 和 AccessDeniedException ，其它的異常它會繼續(xù)拋出。

1. 用戶提交用戶名、密碼被 SecurityFilterChain 中的 UsernamePasswordAuthenticationFilter 過濾器獲取到，

封裝為請求 Authentication ，通常情況下是 UsernamePasswordAuthenticationToken 這個(gè)實(shí)現(xiàn)類。

2. 然后過濾器將 Authentication 提交至認(rèn)證管理器（ AuthenticationManager ）進(jìn)行認(rèn)證

3. 認(rèn)證成功后， AuthenticationManager 身份管理器返回一個(gè)被填充滿了信息的（包括上面提到的權(quán)限信息，

身份信息，細(xì)節(jié)信息，但密碼通常會被移除） Authentication 實(shí)例。

4. SecurityContextHolder 安全上下文容器將第 3 步填充了信息的 Authentication ，通過

SecurityContextHolder.getContext().setAuthentication(…) 方法，設(shè)置到其中。

可以看出 AuthenticationManager 接口（認(rèn)證管理器）是認(rèn)證相關(guān)的核心接口，也是發(fā)起認(rèn)證的出發(fā)點(diǎn)，它

的實(shí)現(xiàn)類為 ProviderManager 。而 Spring Security 支持多種認(rèn)證方式，因此 ProviderManager 維護(hù)著一個(gè)

List<AuthenticationProvider> 列表，存放多種認(rèn)證方式，最終實(shí)際的認(rèn)證工作是由

AuthenticationProvider 完成的。咱們知道 web 表單的對應(yīng)的 AuthenticationProvider 實(shí)現(xiàn)類為

DaoAuthenticationProvider ，它的內(nèi)部又維護(hù)著一個(gè) UserDetailsService 負(fù)責(zé) UserDetails 的獲取。最終

AuthenticationProvider 將 UserDetails 填充至 Authentication 。

通過前面的 Spring Security 認(rèn)證流程 我們得知，認(rèn)證管理器（ AuthenticationManager ）委托

AuthenticationProvider 完成認(rèn)證工作。

AuthenticationProvider 是一個(gè)接口，定義如下：

public interface AuthenticationProvider {
    Authentication authenticate(Authentication authentication) throws AuthenticationException;
    boolean supports(Class<?> var1);
}

authenticate () 方法定義了 認(rèn)證的實(shí)現(xiàn)過程 ，它的參數(shù)是一個(gè) Authentication ，里面包含了登錄用戶所提交的用

戶、密碼等。而返回值也是一個(gè) Authentication ，這個(gè) Authentication 則是在認(rèn)證成功后，將用戶的權(quán)限及其他信

息重新組裝后生成。

Spring Security 中維護(hù)著一個(gè) List<AuthenticationProvider> 列表，存放多種認(rèn)證方式，不同的認(rèn)證方式使用不

同的 AuthenticationProvider 。如使用用戶名密碼登錄時(shí)，使用 AuthenticationProvider1 ，短信登錄時(shí)使用

AuthenticationProvider2 等等這樣的例子很多。

每個(gè) AuthenticationProvider 需要實(shí)現(xiàn) supports （） 方法來表明自己支持的認(rèn)證方式，如我們使用表單方式認(rèn)證，

在提交請求時(shí) Spring Security 會生成 UsernamePasswordAuthenticationToken ，它是一個(gè) Authentication ，里面

封裝著用戶提交的用戶名、密碼信息。而對應(yīng)的，哪個(gè) AuthenticationProvider 來處理它？

public boolean supports(Class<?> authentication) {
    return UsernamePasswordAuthenticationToken.class.isAssignableFrom(authentication);
}

也就是說當(dāng) web 表單提交用戶名密碼時(shí)， Spring Security 由 DaoAuthenticationProvider 處理。

最后，我們來看一下 Authentication ( 認(rèn)證信息 ) 的結(jié)構(gòu)，它是一個(gè)接口，我們之前提到的

UsernamePasswordAuthenticationToken 就是它的實(shí)現(xiàn)之一：

public interface Authentication extends Principal, Serializable {
    Collection<? extends GrantedAuthority> getAuthorities();
    Object getCredentials();
    Object getDetails();
    Object getPrincipal();
    boolean isAuthenticated();
    void setAuthenticated(boolean var1) throws IllegalArgumentException;
}

UserDetailsService

現(xiàn)在咱們現(xiàn)在知道 DaoAuthenticationProvider 處理了 web 表單的認(rèn)證邏輯，認(rèn)證成功后既得到一個(gè)

Authentication(UsernamePasswordAuthenticationToken 實(shí)現(xiàn) ) ，里面包含了身份信息（ Principal ）。這個(gè)身份 信息就是一個(gè) Object ，大多數(shù)情況下它可以被強(qiáng)轉(zhuǎn)為 UserDetails 對象。

DaoAuthenticationProvider 中包含了一個(gè) UserDetailsService 實(shí)例，它負(fù)責(zé)根據(jù)用戶名提取用戶信息

UserDetails( 包含密碼 ) ，而后 DaoAuthenticationProvider 會去對比 UserDetailsService 提取的用戶密碼與用戶提交

的密碼是否匹配作為認(rèn)證成功的關(guān)鍵依據(jù)，因此可以通過將自定義的 UserDetailsService 公開為 spring bean 來定 義自定義身份驗(yàn)證。

很多人把 DaoAuthenticationProvider 和 UserDetailsService 的職責(zé)搞混淆，其實(shí) UserDetailsService 只負(fù)責(zé)從特定 的地方（通常是數(shù)據(jù)庫）加載用戶信息，僅此而已。而DaoAuthenticationProvider 的職責(zé)更大，它完成完整的認(rèn) 證流程，同時(shí)會把UserDetails 填充至 Authentication 。

上面一直提到 UserDetails 是用戶信息，咱們看一下它的真面目：

public interface UserDetails extends Serializable {
    Collection<? extends GrantedAuthority> getAuthorities();
    String getPassword();
    String getUsername();
    boolean isAccountNonExpired();
    boolean isAccountNonLocked();
    boolean isCredentialsNonExpired();
    boolean isEnabled();
}

PasswordEncoder

public interface PasswordEncoder {
    String encode(CharSequence var1);
    boolean matches(CharSequence var1, String var2);
    default boolean upgradeEncoding(String encodedPassword) {
    return false;
    }
}

@Bean
public PasswordEncoder passwordEncoder() {
    return NoOpPasswordEncoder.getInstance();
}

授權(quán)流程

（不過后面我們都會從數(shù)據(jù)庫中拿）

授權(quán)決策

自定義認(rèn)證

自定義登錄頁面

@Configuration//就相當(dāng)于springmvc.xml文件
public class WebConfig implements WebMvcConfigurer {


    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
        registry.addViewController("/").setViewName("redirect:/login-view");
        registry.addViewController("/login-view").setViewName("login");

    }

}

//配置安全攔截機(jī)制
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/r/**").authenticated()
.anyRequest().permitAll()
.and()
.formLogin() (1)
.loginPage("/login‐view") (2)
.loginProcessingUrl("/login") (3)
.successForwardUrl("/login‐success") (4)
.permitAll();
}

問題解決

spring security 為防止 CSRF （ Cross-site request forgery 跨站請求偽造）的發(fā)生，限制了除了 get 以外的大多數(shù)方法。

解決方法 1 ：

屏蔽 CSRF 控制，即 spring security 不再限制 CSRF 。

配置 WebSecurityConfig

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.csrf().disable() //屏蔽CSRF控制，即spring security不再限制CSRF
    ...
}

連接數(shù)據(jù)庫認(rèn)證

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

UserDetails 中的密碼存儲 BCrypt 格式

前邊實(shí)現(xiàn)了從數(shù)據(jù)庫查詢用戶信息，所以數(shù)據(jù)庫中的密碼應(yīng)該存儲 BCrypt 格式

編寫 LoginController ，實(shí)現(xiàn) /r/r1 、 /r/r2 的測試資源，并修改 loginSuccess 方法，注意 getUsername 方法， Spring

Security 獲取當(dāng)前登錄用戶信息的方法為 SecurityContextHolder.getContext().getAuthentication()

@RestController
public class LoginController {

    @RequestMapping(value = "/login-success",produces = {"text/plain;charset=UTF-8"})
    public String loginSuccess(){
        //提示具體用戶名稱登錄成功
        return getUsername()+" 登錄成功";
    }

    /**
     * 測試資源1
     * @return
     */
    @GetMapping(value = "/r/r1",produces = {"text/plain;charset=UTF-8"})
    public String r1(){
        return getUsername()+" 訪問資源1";
    }

    /**
     * 測試資源2
     * @return
     */
    @GetMapping(value = "/r/r2",produces = {"text/plain;charset=UTF-8"})
    public String r2(){
        return getUsername()+" 訪問資源2";
    }

    //獲取當(dāng)前用戶信息
    private String getUsername(){
        String username = null;
        //當(dāng)前認(rèn)證通過的用戶身份
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        //用戶身份
        Object principal = authentication.getPrincipal();
        if(principal == null){
            username = "匿名";
        }
        if(principal instanceof org.springframework.security.core.userdetails.UserDetails){
            UserDetails userDetails = (UserDetails) principal;
            username = userDetails.getUsername();
        }else{
            username = principal.toString();
        }
        return username;
    }
}

會話控制

通過以下配置方式對該選項(xiàng)進(jìn)行配置：

@Override
protected void configure(HttpSecurity http) throws Exception {
    http.sessionManagement()
    .sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
}

默認(rèn)情況下， Spring Security 會為每個(gè)登錄成功的用戶會新建一個(gè) Session ，就是 ifRequired 。

若選用 never ，則指示 Spring Security 對登錄成功的用戶不創(chuàng)建 Session 了，但若你的應(yīng)用程序在某地方新建了

session ，那么 Spring Security 會用它的。

若使用 stateless ，則說明 Spring Security 對登錄成功的用戶不會創(chuàng)建 Session 了，你的應(yīng)用程序也不會允許新建

session 。并且它會暗示不使用 cookie ，所以每個(gè)請求都需要重新進(jìn)行身份驗(yàn)證。這種無狀態(tài)架構(gòu)適用于 REST API

及其無狀態(tài)認(rèn)證機(jī)制。

spring boot 配置文件

session 超時(shí)之后，可以通過 Spring Security 設(shè)置跳轉(zhuǎn)的路徑

http.sessionManagement()
    .expiredUrl("/login‐view?error=EXPIRED_SESSION")
    .invalidSessionUrl("/login‐view?error=INVALID_SESSION");

Spring security 默認(rèn)實(shí)現(xiàn)了 logout 退出，訪問 /logout ，果然不出所料，退出功能 Spring 也替我們做好了。

但是，類似于配置登錄功能，咱們可以進(jìn)一步自定義退出功能：

@Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
//...
.and()
.logout() (1)
.logoutUrl("/logout") (2)
.logoutSuccessUrl("/login‐view?logout") (3)
.logoutSuccessHandler(logoutSuccessHandler) (4)
.addLogoutHandler(logoutHandler) (5)
.invalidateHttpSession(true); (6)
}

logoutHandler ：

一般來說， LogoutHandler 的實(shí)現(xiàn)類被用來執(zhí)行必要的清理，因而他們不應(yīng)該拋出異常。

下面是 Spring Security 提供的一些實(shí)現(xiàn)：

PersistentTokenBasedRememberMeServices 基于持久化 token 的 RememberMe 功能的相關(guān)清理

TokenBasedRememberMeService 基于 token 的 RememberMe 功能的相關(guān)清理

CookieClearingLogoutHandler 退出時(shí) Cookie 的相關(guān)清理

CsrfLogoutHandler 負(fù)責(zé)在退出時(shí)移除 csrfToken

SecurityContextLogoutHandler 退出時(shí) SecurityContext 的相關(guān)清理

鏈?zhǔn)?/span> API 提供了調(diào)用相應(yīng)的 LogoutHandler 實(shí)現(xiàn)的快捷方式，比如 deleteCookies() 。