spring security對於用戶身份的判斷是通過一系列的過濾器來完成的，如果你採用的是自定義過濾器鏈的方式來實現自己的需求，那麼需要特別注意過濾器鏈的順序問題。
但是除了過濾器的順序，還有一個特別需要注意的，就是providers順序
一個較爲典型的問題是：爲什麼我的用戶是密碼錯誤，但是卻拋出用戶不存在的異常呢？（而不是拋出身份檢查失敗異常）
這就是因爲配置的org.springframework.security.providers.ProviderManager中的providers順序不合適導致的了，過濾器的檢查，是一個鏈表的形式，如果當前的過濾器能匹配成功，那麼則會停止並進入成功邏輯。如果失敗，則進入下一個過濾器鏈，如果是最後一個過濾器鏈，那麼就拋出檢查失敗的異常。而對於其中某一個過濾器而言，我們會制定相關的authenticationManager，用戶向上提供數據來源等。於是必然的，我們在系統中會配置多個UserDetailsService，用於向spring security提供我們自己的數據源DAO相關操作，過濾器在使用的時候是以按照配置的順序來執行的。
而這可能使得當前用戶的信息被其中的一個Provider所識別，但是如果是密碼錯誤等，那個存有當前用戶信息數據的Provider沒有能夠匹配成功，而導致進入了下一個Provider，而下一個Provider並沒有當前用戶的數據，所以會拋出當前用戶不存在。
這樣的話，就應該調整Provider的順序，將最重要的最希望提示的那個放到最後面去。
比如現在有三個:
<beans:property name="providers">
<beans:list>
<beans:ref local="rememberMeAuthenticationProvider" />
<beans:ref local="memoryAuthenticationProvider" />
<beans:ref local="dbAuthenticationProvider" />
</beans:list>
</beans:property>
數據庫中的用戶是最重要最普遍的，而內存中的通常是一些隱藏用戶，這樣的話就可以將最大範圍的用戶的信息準確展示
最近整理了學習材料，有需要的請下載，我放微信裏面了，方便下載，還能交流，掃描我的二維碼頭像即可。