本篇內容介紹了“spring security的內部filter是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
我們提供的服務有：成都做網(wǎng)站、網(wǎng)站制作、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、興縣ssl等。為上千多家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的興縣網(wǎng)站制作公司
我們在用spring boot 配合spring security和oauth3的時候經(jīng)常會把這兩個類都用上，網(wǎng)上很多教程都沒有告訴我們他們之間的關系是什么？如果同時在處理同一個Url（如：/api/**）應該是哪個生效？spring security的內部filter是個什么樣子？帶著這些疑問我們一層層的來扒開。
Java在正常servelet處理http的請求可能會經(jīng)過很多的filter，大體例子像下面這個：
圖片.png
而spring security又是怎么處理的呢，詳見下圖：
圖片.png
從圖中可以看出spring security自己有一個叫FilterChainProxy代理類，該類也實現(xiàn)了servlet接口。FilterChainProxy``內部有一個List
圖片.png
比如來了一個請求，url是：/foo/**，那么他會被會第一個filter chain處理，后面的兩個filter chain會被忽略掉。`
當我們在spring boot引入了spring-security的相關包時，security默認會為我們創(chuàng)建一個默認WebSecurityConfigurerAdapter，他攔截所有的http請求(/**),且這個Order的值是：SecurityProperties.BASIC_AUTH_ORDER。Security默認還會為我們創(chuàng)建一些filter：
圖片.png
每個filter的作用可以在spring security中文檔中找到。
當然你可以通過配置文件設置security.basic.enabled=false 來讓默認的失效，或者你可以自定義一個并添加@Order值更低的WebSecurityConfigurerAdapter (or WebSecurityConfigurer) 的`@Bean``，比如像下面的代碼：
重慶分公司
重慶分公司
@Order(SecurityProperties.BASIC_AUTH_ORDER - 10)
public class ApplicationConfigurerAdapter extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.antMatcher("/foo/**")
...;
}
}WebSecurityConfigurerAdapter與ResourceServerConfigurerAdapter同時在的話且都配置了處理url為：/api/**，默認是后者會生效。我們在寫ResourceServerConfigurerAdapter時，基本上會這么寫：
圖片.png
為什么是后者生效呢，因為默認的WebSecurityConfigurerAdapter里的@Order值是100（我們可以在該類上可以明確看到@Order(100)），而我們在ResourceServerConfigurerAdapter上添加了@EnableResourceServer注解，這個玩意兒是干什么用的呢？他其中之一就是定義了@Order值為3（該注解里引用了ResourceServerConfiguration，這個類里面定義了Order值）.在spring 的體系里Order值越小優(yōu)先級越高，所以ResourceServerConfigurerAdapter優(yōu)先級比另外一個更高，他會優(yōu)先處理，而WebSecurityConfigurerAdapter會失效。
如果我們想讓WebSecurityConfigurerAdapter比ResourceServerConfigurerAdapter優(yōu)先級高的話，只須要讓前者的@Order值比后者的@Order值更低就行了。
注意：我們每聲明一個*Adapter類，都會產生一個filterChain。前面我們講到一個request（匹配url）只能被一個filterChain處理，這就解釋了為什么二者Adapter同時在的時候，前者默認為什么會失效的原因。我們可以在FilterChainProxy中的getFilters(HttpServletRequest request)方法中可以看到有哪些filter chain，并處理哪些url，例如：
圖片.png
a.如果我們通過這種方式配置的話，requestMatcher值為顯示No fields to display:
圖片.png
b.如果通過這種方式配置的話，requestMatcher值為顯示match到的url :/aa/**
圖片.png
具體為什么，見下文。
他們所屬的功能模塊不同，前者spring security的，后者是spring security oauth3里的。他們都是Adapter，他們都會產生一個filter Chain，他們兩者可以相互配合來對不同的Url進行權限控制。
但是，我們經(jīng)常在寫代碼的時候經(jīng)常會出現(xiàn)這種情況，當我們在做oauth3的時候，當把兩個類同時放在項目的時候，都聲明了對http url的不同處理，但是就是ResourceServerConfigurerAdapter會把的http配置信息完全被覆蓋掉，最后形成了，所有的請求只會在ResourceServerConfigurerAdapter的fitler chain中處理，導致用戶不知道這兩者到底是怎么回事。
這其實是因為對spring security的配置不熟悉導致的，也就是antMatcher()``和authorizeRequests().antMatchers()。
讓我們看兩個例子：
例1：
圖片.png
圖片.png
上面這個例子，本意是想/api/* 端點須要被認證且要有USER權限;/user/**的端點須要被認證，但是最終的結果是WebSecurityConfigurerAdapter相關的配置信息沒生效。
我們使用postman來測試一下：
圖片.png
圖片.png
從這結果我們可以看出來：/user/* 的端點沒有被保護起來，/api/*的端點實際是被ResourceServerConfigurerAdapter產生的filter chain進行處理的。
這和我們想要的效果不一樣呢，該怎么辦呢，我們來看看例子2：
例2：
圖片.png
圖片.png
postman測試：
圖片.png
圖片.png
可以看出來/api/的端點實際是被ResourceServerConfigurerAdapter產生的filter chain進行處理的。而/user/ 的端點也被保護起來，但是這次被處理的是由WebSecurityConfigurerAdapter產生的filter chain進行處理的。
讓我們來看stackoverflow上的解釋：
圖片.png
大體意思就是antMatcher()``是HttpSecurity的一個方法，他只告訴了Spring我只配置了一個我這個Adapter能處理哪個的url，它與authorizeRequests()沒有任何關系。
然后使用authorizeRequests().antMatchers()是告訴你在antMatchers()中指定的一個或多個路徑,比如執(zhí)行permitAll()或hasRole()。他們在第一個http.antMatcher()匹配時就會生效。
所以，WebSecurityConfigurerAdapter與ResourceServerConfigurerAdapter同時使用，其實和spring security的多個HttpSecurity配置是一樣的，原理也差不多是一樣的。
用官方的例子：
圖片.png
1、按照正常的方式配置驗證
2、創(chuàng)建一個包含 @Order的 WebSecurityConfigurerAdapter實例來指定哪一個 WebSecurityConfigurerAdapter應該被首先考慮。
3、 http.antMatcher表明這個 HttpSecurity 只適用于以 /api/開頭的URL。
4、創(chuàng)建另一個 WebSecurityConfigurerAdapter實例。如果URL沒有以 /api/開頭，這個配置將會被使用。這個配置在 ApiWebSecurityConfigurationAdapter 之后生效，因為其含有一個 @Order值為1.沒有 @Order默認是最后一個生效。
“spring security的內部filter是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質量的實用文章！
