古時候寫代碼，許可權這塊寫過一個庫，基本就是一個泛型介面，裡面有幾個方法： 如驗證輸入的principal和credentials，返回token和authorities和roles，role就是一堆authorities集，也就說就是返回一堆authorities。然後每次請求會拿token找到au ...
古時候寫代碼，許可權這塊寫過一個庫，基本就是一個泛型介面，裡面有幾個方法：
如驗證輸入的principal和credentials，返回token和authorities和roles，role就是一堆authorities集，也就說就是返回一堆authorities。然後每次請求會拿token找到authorities，然後再判斷當前請求的資源（其實就是url）包不包括在authorities內。
這介面實現不複雜，也可很複雜自己實現，因為是介面，裡面的方法參數都帶了很多上下文，所以基本可以獲取到所有有用的信息。當年用這介面幾乎就沒解決不了的許可權問題。
後來用spring，更簡單了，就是aop一下controller，然後類似那種介面鑒權，不aop就用filter或者攔截器一樣的。
再後來，發現spring security粗略研究下。好呀，什麼AuthenticationManager，AuthenticationProvider，UserDetailsService，SecurityContextHolder，SecurityInterceptor眼花繚亂，無從下手。而且，不知道是我沒註意還是眼瞎，這玩意兒似乎和web或者webflux強耦合。當時有個需求是session（其實就是token）放在redis里，有個同事為實現這簡單東西似乎要重寫整個HttpSession類？
還有也是因為我們的許可權配置是在另一個服務里，所以獲取許可權的時候要重寫UserDetailsService？
不知道是我同事水平不夠還是版本太老，反正看的我瑟瑟發抖。
有必要系統學習這東西嗎？其實我看半天整個spring security實現的東西似乎和我自己的那種介面思想沒什麼區別。現在有新項目了，到底要不要系統學習spring security，是我理解太膚淺？
Spring Security就是個垃圾框架
這觀點完全正確，因為他把所有擴展完全用介面概念去做，僅適合中小型項目。
對稍大項目，要求多端登錄，設備標識等特殊需求實現起來異常複雜。一旦要變更，其給的介面根本無法滿足企業需求。
shrio才是好框架，雖簡單，但對經驗豐富的程式員僅需2~3天就可實現所有spring security功能，且擴展性更強。
我為了學spring security花了一個月時間才掌握所有知識點，但概念太多，幾個月後讓我改登錄，直接懵了。相信我，任何一個程式員面對spring security更新，加上隔幾個月或半年之後，大部分人都懵逼，因為原有的介面不能用了。
而shrio則不同，介面實現幾乎無變化，但是要求必須精通jwt和oauth協議。精通這兩個協議，最多一周而且就算過幾年，改登錄需求，依然可以快速上手。
那些說spring security好的，大部分都是搞培訓或裝13，不要相信。
Sa-token也很香
之前粗略看spring security，沒太看懂，sa-token跟著官方文檔給項目裡加了下，感覺真的簡單，還能實現token自動續期的問題，太香！
本文由博客一文多發平臺 OpenWrite 發佈！
