maven and jwt

以目前淺薄的理解，jwt就是一種加密token的手段，這個token也只有本身能解開，若是客戶端以cookie存這個token，可能會存在cookie被竊取的狀況。

另外，jwt這中加密方式由於有過時時間的參與（當前登錄時間+延遲時長），因此每次請求zull都要判斷當前時間是否大於你的設置（這裏能夠形成多用戶同一個帳戶同時登錄），若是大於了，解密出來的東西就和預期不符，就要從新登錄。因此有刷新token的機制存在，怎麼刷？猜想就是客戶端在token將死以前從新獲取token唄（反正是無狀態的，多發的。）。固然，若是你遇到只能一個帳號單一在線的須要，刷token的方式我以爲是不可行的。

 

經過jwt我很快想通不少問題，大概都是隱約的猜想。好比單點登錄，web登錄了，手機也要登錄。刷驗證碼唄，其實就是請求了一個鏈接，這個鏈接推送消息給鑑權中心，發現已經登錄了，ok，推送給手機一個token，並告訴它，ok，你登錄吧。

 

---------

 

在作jwt時，由於考慮到複用性，把登錄單獨提出來。登錄和zull鑑權就是單獨的模塊，可是他們都公用jwt工具類和user實體對象啊。抽象到common裏。

怎麼調取呢？mavne的pom里加上對common的引用就能夠了。這裏就想到了mavne可能把common打包成jar給登錄模塊和鑑權模塊引用了。懶得查的那麼細緻了。猜想了一下就打住了。

 

--------

 

springcloud的熔斷php能不能實現呢？

我感受行，好比作個網關，外部請求網關，網關調用內網接口，調用時要判斷下超時時間。

springcloud的鑑權中心php能不能實現呢？

我感受也行，jwt又不是限制在單一語言的標準，它適用與多種語言。

。。。。

 

--------

 

總感受jwt比較重要，好比你作好一個jwt的鑑權中心看成網關作轉發，那麼另一個項目就專心作業務好了。前面一個門神，後面一頓業務增刪改查。。。

 

https://gitee.com/fleam/jwt