距離上一篇博客《關於技術人員自身能力提升的一些思考》已經相隔將近一個月,如今纔去更新博文,一方面工做上面確實有點忙,另一方面本身也可能真的最近有所鬆懈。老貓也就不去找說辭了。前端
上次發佈博文以後,網友反響其實仍是挺大的,每一個人都有本身的見解。大概是這樣的,老貓截取了其中一些網友的留言。
vue
其實從上面的留言裏面能夠看到兩種意見,第一種,同意學習研究技術,主要目的做爲知識儲備。一旦用到,從新翻看學習的成本會比較低,即便忘記了。第二種,同意經過實際的開源項目去實踐相關的技術,這樣纔會更加深入。程序員
後來老貓想了想仍是決定綜合以上兩種意見,首先業餘時間作個開源的項目出來,另外的話同時也把裏面的相關的技術點也細扣一下,而後分享給你們。web
思來想去不曉得以什麼樣的開源系統做爲切入會比較好,做爲一個後端程序員,咱們接觸最多的就是咱們的後端系統,固然最基礎的話仍是權限系統。固然這是老貓選擇權限系統的第一個緣由。spring
基礎的權限系統完成以後,其實也能夠在此之上拓展一些其餘的業務出來,其實老貓也同時在預謀另一個產品,在此先賣個關子,老貓後續會公開,因此歡迎你們持續關注老貓。這是第二個緣由。數據庫
將近畢業季,相信不少軟件學院的學生黨還在苦苦糾結於作個怎樣的畢業設計。因此在此,老貓也但願能給你們一些思路,或者說給一個比較簡單而又拓展性比較強的模板,你們能夠拿去自行拓展本身的想法,代碼總體的學習成本並非很高。這是其三。後端
老貓是後端程序員,對於前端只能說會用,並不精通,更不用說本身去開發出漂亮的前端頁面,可是後端系統的vue相關的系統頁面有不少現成的開源代碼,用來作系統都很是漂亮,能夠直接拿來作系統,固然最簡單就是權限系統了,這是其四。緩存
這就是以上四點老貓決定總權限系統入手的緣由。安全
全部的系統都是從單體架構開始的,因爲業務比較簡單,因此老貓剛開始的時候先不考慮微服務,後面老貓在進行需求擴展的時候再去作相關的微服務改造。可是老貓此次的權限系統仍是作成先後端分離的模式,主要思路就是shiro+jwt+vue去實現相關的登陸權限功能。cookie
關於企業級的登陸以及權限驗證的話市面上有比較成熟的開源框架,通常會有這兩個,分別是spring security以及shiro。
聊聊二者的共同功能,二者都具備:
(1)認證功能(2)受權功能(3)加密功能(4)會話管理(5)緩存支持 (6)rememberMe功能。
看看不一樣點:
一、Spring Security 基於Spring 開發,依賴spring容器,項目若使用 Spring 做爲基礎,配合 Spring Security 作權限更加方便。Shiro 依賴性低,不須要任何框架和容器,能夠獨立運行,因此這就致使 Shiro 須要和 Spring 進行整合開發;
二、Spring Security 功能比 Shiro 更加豐富些(聽說控制粒度能夠更細),另外的Spring Security對Oauth、OpenID有支持,然而shiro須要手動去實現 ;
三、Spring Security 社區資源相對比 Shiro 更加豐富;Spring Security對Oauth、OpenID也有支持,Shiro則須要本身手動實現。並且Spring Security的權限細粒度更高,spring security 接口 RequestMatcher 用於匹配路徑,對路徑作特殊的請求,相似於shiro的抽象類 PathMatchingFilter,可是 RequestMatcher 做用粒度更細
四、Shiro 簡單,易用,功能也強大,Spring Security 上手複雜些;
五、shiro 不只僅可使用在web中,還支持非web項目它能夠工做在任何應用環境中。在集羣會話時Shiro最重要的一個好處或許就是它的會話是獨立於容器的。
綜上,雖然spring security看起來比shrio更增強大,另外還有shiro所不具有的對Oauth、OpenID的支持,可是這些都不是關鍵。談到權限的控制粒度,shiro徹底能夠經過數據庫的查詢層面去作掉。關於Oauth以及OpenID支持。因爲是web應用,因此現租戶與各個產品間單點登陸已經經過cookies實現。另外的最大的緣由的話主要仍是shiro相對而言更加容易上手一些。不得不提一嘴的是 SpringSide網站的權限也是用Shrio作的。
因此結論就很明顯了,老貓仍是決定用shiro去作權限認證。
勿以善小而不爲,複雜的業務系統老是從最簡單的系統開始。基礎的技術千篇一概,有趣的系統演化鳳毛麟角。因此與其死啃乾貨,不如從系統真實去實戰,just do it !,just do it ! 因此接下來開始,但願你們就和老貓共同開啓開源之旅了。在開源中成長,在開源中去結合實際場景學習一些新的知識。flow me!