shiro過濾器失效問題研究

專案使用了shiro 過濾器攔截請求，做一些限流，鑑權，白名單限制的事情，可是最近在上線乙個新功能時，新增了乙個攔截路徑，上線後，發現部分設定了攔截的路徑失效，導致專案回滾

這也告訴我們問題無大小，遇到問題後就要想辦法**，否則說不定在**就有乙個坑等著你。

經過之前的排查，排除正規表示式路徑覆蓋的懷疑，那麼就剩下***排序演算法了。下面貼一下我們出問題前的原始碼配置。

出問題時候原始碼配置

觀察因順序原因可能影響到的配置只有「/**」路徑的設定，去除後所有攔截生效。

通過閱讀相關原始碼，pathmatchingfilterchainresolver引起了我的注意。

該**就是取請求路徑，和配置的過濾器路徑做正則匹配。通過除錯發現此文討論問題出現前後，filterchainmanager.getchainnames()返回的過濾器配置路徑順序是不一致的。寫了個測試例子驗證下，輸出如下

就是因為/**的順序調整了，所以導致之後的shiro配置都失效了。

filterchainmanager.getchainnames()返回的為hashmap的keyset對應的set型別，其遍歷的是hashmap的node節點並返回，沒有做任何排序，其順序是hashmap在put時候通過key值的hashcode經過運算得到（hashmap的key是無順序的）。

在觀察一下出問題前後路徑的個數，是12個到13個的時候，這個不是偶然的，因為hashmap預設初始化的是16個容量，負載因子是0.75，在12個後所有key會rehash，正是因為rehash導致輸出的順序發生改變，導致類本次悲劇的再傳送。