本文的前提是建立在假定你已經熟知jwt和session是什么及相應的作業原理和用法皆有所了解，生產中也有實際的使用，
關于jwt的一些不足之處，可以參考這里：（譯）別再使用 JWT 作為 Session 系統！問題重重且很危險，
JWT存在的意義是什么？很顯然就是：自包含，去中心化，無狀態化！ 這是他存在的核心價值和意義，除去這兩點JWT可以說是一無是處！又長又啰嗦，還不安全，動不動就超長，比如我一個專案有500多選單，我嘗試使用jwt，且在payload存入用戶角色，比如管理員就有60-100個角色，生成的JWT-TOKEN長度都快趕上一本小說或自傳的長度了，哈哈哈哈！當然這是蒙太奇手法，夸張了點！
如果你正在嘗試使用JWT構建session方案，我直接告訴你，趕緊放棄！越早越好！JWT 在作為 session 時， 最大的痛苦就是自動續期和指定失效 2 個方面是致命傷，而且無解！不管你用任何方式實作，最終都拋離了jwt存在的本源
最重要的，不要考慮在服務器維護 JWT，比如在服務端維護一個 token 黑名單以實作指定失效這種操作！又或者維護一個refresh_Token串列以實作自動續期，不管你是以任何方法、任何方案都不要嘗試！直接放棄！不然最終就變成了為用而用、越搞越復雜，讓本身無狀態的jwt 變成了有狀態，最終失去了jwt存在的意義！倒不如一開始就直接用自定義token 存redis來的又直接又方便又高效！
反過來想想，你傾慕于jwt的無狀態化和去中心化，想著不依賴session,可以為所欲為的橫向擴展而不用操心session的復制同步和跨域訪問問題，但是你又想實作服務器可以管控簽發的jwt token 可以做到人走茶涼，注銷了就作廢這個jwt token.你能做到嗎？答案是no.你根本做不到，jwt token中自帶的過期時間，讓服務端對簽發的jwt token徹底失控,你要想實作，你就要在服務器維護黑名單，而且還要各種折騰寫redis保存，而且你要實作jwt-token過期后能自動續期，你還要費勁心思，實作refresh Token，access_Token，來加持，將refresh Token存在服務端redis中，，，，，這里省略一萬字，不想多說了，都已經用redis了，給前端一個固定不過期的token又或者在redis中保存一個有過期時間的token，每次請求在攔截器中更新redis中token的過期時間難道不香嗎？取用戶資訊的時候直接從token中獲取，退出后干掉redis 中的token！不但前端省事后端也省事啊！
不說了，給大家幾個連接自己去看看，有這種牢騷的人還不至我一個人
https://blog.csdn.net/KimSoft/article/details/107305108
https://blog.csdn.net/weixin_39612058/article/details/110801369
https://blog.csdn.net/m0_37809141/article/details/86572697
https://blog.csdn.net/qq_32565267/article/details/104651829
https://learnku.com/articles/22616
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/247151.html
標籤：其他
上一篇：基于服務器搭建部署的疫情動態地圖
下一篇：實作隱私計算的相關技術