這是一篇隨筆和心得，不會寫入任何的一種代碼。只是提供一種邏輯。
在我之后，我會發現這種邏輯尤為重要
最近在做一套通用的權限管理項目，考慮使用的是Shiro 的這個框架。認證和鑒權就是權限框架所解決的問題。
對於認證，使用默認的SecurityManager時 Shiro 采用的是將所有的Session信息寫入到內存中，來維持會話信息。詳情可以看 DefaultSessionManager
DefaultSessionManager 中使用的是基於內存的Session 管理機制，由於面向對象若自己定義的Session管理類繼承了其中的某個Session管理類。對於類的初始化皆有調用構造器時隱式的調用父類的構造器進行先初始化
所以對於會話的管理，則轉移到了如何對於內存中session的管理，單機情況下用戶的注銷。在調用注銷后，則可以通過使內存中的session失效來實現。
但是在集群環境中並不適合。所以需要通過一種方式來將session持久化保存到一個地方便於session的管理。
這里選用的是redis 並且重寫了SessionDao 並且注入容器中用於操作Session
繼承並且重寫SessionManager 中的GetSessionId方法， 在每次的請求頭中獲取某一個指定前綴的Token
如果獲取不到的話 則調用父類的從Cookie中獲取。
由於指定了SecurityManager 中的緩存管理器和UserRealm中的緩存管理器為Redis的CacheManage
所以在用戶的登錄后的信息，以及用戶第一次訪問需要權限的資源信息時會調用自定義realm中的授權方法，來校驗用戶是否有對應的權限。
而如果確定用戶是否可以訪問不同的權限呢？ 在每一次用戶獲取權限信息時根據不同的業務邏輯將不同的權限字符串或者角色字符串授予指定的角色或者用戶即可。
那么在更新用戶的權限信息時，由於redis中的權限信息並不會被更新，所以可以對redis中的信息設置某個前綴，在對其進行授后，使其信息失效。這樣被授權方，不需要重新登錄。在下次訪問授權資源的時候則會重新查詢數據庫權限。
2、第二種方法則是通過jwt 來做校驗
jwt做校驗的邏輯其實和上述差不多，可以把權限信息放到jwt中在用戶訪問的時候對其進行解密。 這樣服務端則不需要來維護用戶的權限信息。
shiro 關閉產生會話，則在用戶登錄成功后 頒發jwt 然后用戶在請求中 一般是頭部附帶jwt信息。
在服務端獲取到token后對其進行解密，然后去訪問服務器的資源。
后面的話不想多說了， 某位大佬一句話說的好，就是你想什么是jwt？ 它是用來解決什么問題的？ 有什么好處？ 有什么弊端？