基于redis的認證方式分析
redis解決短信驗證碼時效性，以及使用token的方式判斷是否登錄的問題，(沒用jwt)
這里面使用兩個攔截器的方式解決：1. 給token有效期重繪 2.判斷用戶是否已登錄
目前驗證用戶是否已登錄，仍然是用到redis和服務端程式去判斷，這個和使用session的判斷方式有點相似，因為也會用到服務端資源，
但是token與session還是有非常大的不同，認證通過后，(認證資訊)session都是保存在記憶體中（服務端服務器中）占記憶體，如果是分布式的架構，那么也會影響性能，
而對于token的方式，認證通過后，(認證資訊)token都是保存在redis中的，即使是分布式系統，對于該token都能拿到，也就實作了單點登錄 就是在多個系統中，用戶只需一次登錄，各個系統即可感知該用戶已經登錄，
且能控制用戶登錄狀態的，
jwt分析
頭部，載體，簽名
服務端根據秘鑰資訊，生成jwt(token)，將token作為資料回傳，然后用戶每次請求過來都在請求頭攜帶該token，
如果用戶攜帶token過來，服務端會用秘鑰去決議該token，看是否通過，如果通過則代表該用戶已登錄，
key-value : token-userInfo 存入redis中
可以控制該token的有效期(也就是用戶登錄的有效期)，且能夠將用戶的一些資訊保存到redis中
用戶請求到達服務端，服務端根據秘鑰再簽發一個jwt(token)，與用戶攜帶的token作比較，如果一致，則再去操作redis
security認證授權分析
認證流程：
呼叫框架方法，重寫登錄認證邏輯，JWT的載體可以存東西
將token回傳給用戶，讓他每次訪問都攜帶過來，
而決議token能得到它里面的載體，包含key的資訊，能根據這個條件去redis中查找用戶是否已經登錄已經他的權限資訊，
要讓用戶注銷，那么就洗掉redis中的對應k-v，那么如果它再想請求需要登錄才能訪問的介面，會被jwt攔截器給攔截住，
每次用戶訪問需要登錄才能訪問的介面時，都會走jwt攔截器這么一個流程，
網上看到的解決方案，就是將權限資訊也放在jwt的載體中，而不是redis的v中，這樣符合邏輯嗎？
答：不行，1.此時的放redis中起到一個單點登錄，且能做登錄超時下線的功能，能夠控制用戶的狀態，只使用jwt的話，是無法控制用戶登錄狀態的，
如果需要給這個方案加一個token重繪機制呢？
加一個過濾器，攔截所有請求，且在jwt過濾器之前執行，實質上就是重繪該用戶對應于redis中的key，
如果請求頭中沒有攜帶token => 直接放行
如果攜帶了 => 那么jwt決議token => 去redis中操作 => 判斷該key是否過期
=> 是，放行
=>否，更新token有效期
再次回顧了security的知識，三更的那個jwt過濾器是必要的，這種方式和session的方式還是具有區別，
- 對于session的方式，(認證資訊)session都是保存在記憶體中（服務端服務器中）占記憶體
- 對于token的方式，認證通過后，(認證資訊)token都是保存在redis中的
- 且重新整合加入了token重繪機制
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/522891.html
標籤：其他
上一篇：JWT的介紹和使用
下一篇：java基礎-列舉型別