springboot之security?FilterSecurityInterceptor的使用要點(diǎn)記錄
spring security FilterSecurityInterceptor使用要點(diǎn)
FilterSecurityInterceptor是一個(gè)方法級(jí)的權(quán)限過濾器, 基本位于過濾鏈的最底部
該過濾器用于控制method級(jí)別的權(quán)限控制. 官方提供了2種默認(rèn)的方法權(quán)限控制寫法
一種是在方法上加注釋實(shí)現(xiàn),另一種是在configure配置中通過
@Secured("ROLE_ADMIN") //法1, 方法定義處加注釋, 需先在具體的配置里開啟此類配置 @EnableGlobalMethodSecurity(securedEnabled = true, prePostEnabled = true) 法2, 在復(fù)寫的configure里直接定義 .antMatchers("your match rule").authenticated() .antMatchers("your match rule").hasRole("ADMIN") //使用時(shí)權(quán)限會(huì)自動(dòng)加前綴ROLE_ADMIN
具體細(xì)節(jié)的代碼就不貼了,官方文檔一模一樣的都有.
上面兩種方法最終都會(huì)生成一個(gè)FilterSecurityInterceptor實(shí)例,放在上面過濾鏈底部. 用于方法級(jí)的鑒權(quán).
官方還提到了第三種方法,關(guān)于如何把過濾的規(guī)則放到更為靈活的位置,數(shù)據(jù)庫(kù)/本地文件/等等.
貼一段官方代碼
public class MyFilterSecurityMetadataSource implements FilterInvocationSecurityMetadataSource { //此方法用于鑒權(quán)過程中獲取當(dāng)前的請(qǐng)求URL需要哪種權(quán)限 public List<ConfigAttribute> getAttributes(Object object) { FilterInvocation fi = (FilterInvocation) object; String url = fi.getRequestUrl(); String httpMethod = fi.getRequest().getMethod(); List<ConfigAttribute> attributes = new ArrayList<ConfigAttribute>(); // Lookup your database (or other source) using this information and populate the // list of attributes return attributes; } public Collection<ConfigAttribute> getAllConfigAttributes() { return null; } public boolean supports(Class<?> clazz) { return FilterInvocation.class.isAssignableFrom(clazz); } }
具體思路就是通過自定義過濾器的MetadataSource
來實(shí)現(xiàn)規(guī)則的靈活配置,該部分實(shí)例默認(rèn)使用的是DefaultFilterInvocationSecurityMetadataSource
, 可以根據(jù)這里的源碼來編寫自己的MetadataSource.
內(nèi)部使用下面這個(gè)結(jié)構(gòu)來維護(hù)匹配規(guī)則和對(duì)應(yīng)的權(quán)限集
Map<RequestMatcher, Collection<ConfigAttribute>> requestMap
RequestMatcher和ConfigAttribute都是抽象類,需要找個(gè)能用的類,通過查閱源碼可以找到RequestMathcer的具體構(gòu)造實(shí)現(xiàn)
RequestMatchers.antMatchers(...)
不過該方法不能直接拿來用,寫了私有
public static List<RequestMatcher> antMatchers(HttpMethod httpMethod, String... antPatterns) { String method = httpMethod == null ? null : httpMethod.toString(); List<RequestMatcher> matchers = new ArrayList<>(); for (String pattern : antPatterns) { matchers.add(new AntPathRequestMatcher(pattern, method)); } return matchers; }
改用new AntPathRequestMatcher(pattern, method)
這個(gè)就行
ConfigAttribute有一個(gè)叫SecurityConfig
的實(shí)例, 構(gòu)造時(shí)傳入String就可以構(gòu)造對(duì)應(yīng)的權(quán)限實(shí)例
不過官方好像沒寫具體怎么注入這個(gè)自定義的MetadataSource???
找了半天好像都沒找到能直接注入到默認(rèn)的Filter的途徑, 沒辦法只能寫一個(gè)新的自定義FilterSecurityInterceptor
來注入, 通過configure里的addFilter()
方法放入過濾鏈
setSecurityMetadataSource()方法寫入自定義的rules源, 還需要注入AccessDecision和Authentication,
前者用于驗(yàn)證訪問權(quán)限, 繼承AccessDecisionManager
實(shí)現(xiàn)decide方法來編寫自定義的驗(yàn)證邏輯
decide
方法包含 Authentication
, 一個(gè)Object類型的FilterInvocation
實(shí)例, 一組ConfigAttribute
(要求的權(quán)限列表, 從MetaSource的getAttributes()
方法里取的, 完整的獲取和校驗(yàn)上層邏輯都封裝在AbstractSecurityInterceptor
的beforeInvocation()
方法里)
后者用于驗(yàn)證登錄授權(quán), 后者使用默認(rèn)的super.authenticationManager()
即可
完成自定義方法級(jí)過濾后碰到幾個(gè)問題,一個(gè)是加入了這個(gè)Filter后原先方法1和方法2設(shè)置的就都失效了.
這里直接說看源碼打斷點(diǎn)后的結(jié)論, 主要是因?yàn)樽远x的filter加入后, 和原先的默認(rèn)FilterSecurityInterceptor
會(huì)有互相排斥的問題, 具體表現(xiàn)為只要這兩個(gè)中的其中一個(gè)先執(zhí)行invoke()方法, 就會(huì)在request里追加一個(gè)名為__spring_security_filterSecurityInterceptor_filterApplied
的attribute表示FilterSecurityInterceptor
這個(gè)類型的過濾器已經(jīng)執(zhí)行過了. 當(dāng)另一個(gè)同類的FilterSecurityInterceptor
進(jìn)來時(shí)就直接跳過具體的invoke方法直接執(zhí)行下一個(gè)過濾器了.
過濾器的位置排序上, addFilter()加的自定義FilterSecurityInterceptor
排到了默認(rèn)的FilterSecurityInterceptor
之前,如果要放在默認(rèn)的后面, 用addFilterAfter()方法, 指定需要放在哪個(gè)過濾器后面.
所以對(duì)應(yīng)的解決辦法也很簡(jiǎn)單,覆寫自定義過濾器中的invoke方法,把加attribute
那段去掉.
我就不處理這個(gè)問題了, 其實(shí)這個(gè)地方算不算一個(gè)問題還得單獨(dú)考慮的, 包括上面自定義Metadata也是.
有這么幾個(gè)其實(shí)寫之前就該考慮好的問題.
- 系統(tǒng)里的方法級(jí)權(quán)限真的需要通過數(shù)據(jù)庫(kù)靈活配置嗎?
- 系統(tǒng)真的需要讓自定義的filter和默認(rèn)filter的權(quán)限規(guī)則同時(shí)生效嗎?
其實(shí)spring官方是推薦方法級(jí)權(quán)限就直接硬編碼的. 因?yàn)榭紤]到放在數(shù)據(jù)庫(kù)后, 安全上的風(fēng)險(xiǎn)實(shí)在太大了.
僅僅通過修改數(shù)據(jù)庫(kù),即使非admin角色的賬戶也是能獲取所有的操作權(quán)限的.
另一點(diǎn)是操作權(quán)限定義上的變更(哪些角色該有哪些操作權(quán)限?)本身就應(yīng)該是需要審計(jì)的,并且非常低頻的.
硬編碼在排除風(fēng)險(xiǎn)之余,對(duì)于實(shí)際使用的影響其實(shí)也是微乎其微的(無非每次確定要改了,發(fā)一次版)
至于我為何要寫自定義的FilterSecurityInterceptor
, 主要是系統(tǒng)的security集成在路由層,那邊不定義方法,法2在configure里硬編碼好像又太繁瑣,所以想在Metadatasource層用文件或者什么靜態(tài)常量的方法硬編碼.
不過最后寫完發(fā)現(xiàn)好像也不便利?并不快樂??? 為了這個(gè)目標(biāo)多寫了好多實(shí)現(xiàn)類,并不能輕松愉快地直接注入Metadatasource.
總結(jié)
以上為個(gè)人經(jīng)驗(yàn),希望能給大家一個(gè)參考,也希望大家多多支持腳本之家。
相關(guān)文章
Spring?Security權(quán)限管理實(shí)現(xiàn)接口動(dòng)態(tài)權(quán)限控制
這篇文章主要為大家介紹了Spring?Security權(quán)限管理實(shí)現(xiàn)接口動(dòng)態(tài)權(quán)限控制,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-06-06劍指Offer之Java算法習(xí)題精講二叉樹的構(gòu)造和遍歷
跟著思路走,之后從簡(jiǎn)單題入手,反復(fù)去看,做過之后可能會(huì)忘記,之后再做一次,記不住就反復(fù)做,反復(fù)尋求思路和規(guī)律,慢慢積累就會(huì)發(fā)現(xiàn)質(zhì)的變化2022-03-03Jmeter的接口測(cè)試詳細(xì)步驟并實(shí)現(xiàn)業(yè)務(wù)閉環(huán)
這篇文章主要介紹了Jmeter的接口測(cè)試詳細(xì)步驟并實(shí)現(xiàn)業(yè)務(wù)閉環(huán),文章圍繞主題展開詳細(xì)的內(nèi)容介紹,具有一定的參考價(jià)值,需要的小伙伴可以參考一下2022-08-08Java中ArrayIndexOutOfBoundsException 異常報(bào)錯(cuò)的解決方案
本文主要介紹了Java中ArrayIndexOutOfBoundsException 異常報(bào)錯(cuò)的解決方案,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-06-06jsp頁面中獲取servlet請(qǐng)求中的參數(shù)的辦法詳解
在JAVA WEB應(yīng)用中,如何獲取servlet請(qǐng)求中的參數(shù),本文講解了jsp頁面中獲取servlet請(qǐng)求中的參數(shù)的辦法2018-03-03Java的分支結(jié)構(gòu)與循環(huán)你知道多少
這篇文章主要為大家詳細(xì)介紹了Java的分支結(jié)構(gòu)與循環(huán),文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下,希望能夠給你帶來幫助2022-02-02SpringMVC中的DispatcherServlet初始化流程詳解
這篇文章主要介紹了SpringMVC中的DispatcherServlet初始化流程詳解,DispatcherServlet這個(gè)前端控制器是一個(gè)Servlet,所以生命周期和普通的Servlet是差不多的,在一個(gè)Servlet初始化的時(shí)候都會(huì)調(diào)用該Servlet的init()方法,需要的朋友可以參考下2023-12-12