基於Token認證的多點登錄和WebApi保護
原文 基於Token認證的多點登錄和WebApi保護
在文章中有錯誤的地方,或是有建議或意見的地方,請大家多多指正,郵箱: [email protected]
一天張三,李四,王五,趙六去動物園,張三沒買票,李四制作了個假票,王五買了票,趙六要直接FQ進動物園
到了門口,驗票的時候,張三沒有買票被拒絕進入動物園,李四因為買假票而被補,趙六被執勤人員抓獲,只有張三進去了動物園
後來大家才知道,當一個用戶帶著自己的信息去買票的時候,驗證自己的信息是否正確,那真實的身份證(正確的用戶名和密碼),驗證通過以後通過身份證信息和票據打印時間(用戶登錄時間)生成一個新的動物園參觀票(Token令牌),給了用戶一個,在動物園門口也保存了票據信息(相當與客戶端和服務端都保存一份),在進動物園的時候兩個票據信息對比,正確的就可以進動物園玩了
這就是我理解的Token認證.當然可能我的比喻不太正確,望大家多多諒解
下面是我們在服務端定義的授權過濾器
思路是根據切面編程的思想,相當於二戰時期城樓門口設立的卡,當用戶想api發起請求的時候,授權過濾器在api執行動作之前執行,獲取到用戶信息
如果發現用戶沒有登錄,我們會判斷用戶要訪問的頁面是否允許匿名訪問
用戶沒有登錄但是允許匿名訪問,放行客戶端的請求
用戶沒有登錄且不允許匿名訪問,不允許通過,告訴客戶端,狀態碼403或401,請求被拒絕了
如果發現用戶登錄,判斷用戶的良民證(Token令牌)是真的還是假的
用戶登錄,且良民證是真的,放行
發現良民證造價,抓起來,不允許訪問
當然,這裏可以加權限,驗證是否有某個操作的權限
好了,服務端有驗證了,客戶端也不能拉下啊,客戶端使用了動作過濾器,在用戶操作之前或用戶操作之後驗證登錄信息(這裏可以加權限,驗證是否有某個操作的權限)
客戶端驗證思路和服務端驗證差不多
下面是客戶端驗證代碼:
但是有良民證也不能也不能無限制的待在城裏啊,我們做了一個時效性,在城市裏什麽時也不做到達一定的時長後得驅逐出城啊(類似與遊戲中的掛機超過一定時間後T出本局遊戲)
在這裏使用的Redis記錄良民證(Token),思路是用戶登錄之後生成的新的Token保存在Redis上,設定保存時間20分鐘,當有用戶有動作之後更新Redis保存有效期
下面是服務端驗證token的,token有效,從新寫入到Redis
以上就是Token認證
現在說說單點登錄的思路
張三登錄了qq:123456,生成了一個Token以鍵值對的方式保存在了數據庫,鍵就是qq號,值就是qq信息和登錄時間生成的一個Token
李四也登錄了qq123456,qq信息是一致的,但是qq登錄時間不同,生成了一個新的Token,在保存的時候發現Redis裏已經存在這個qq的鍵了,說明這是已經有人登錄了,在這裏可以判斷是否繼續登錄,登錄後新的Token信息覆蓋了張三登錄QQ生成的Token,張三的Token失效了,當他再次請求的時候發現Token對應不上,被T下線了
多點登錄也是,可以通過qq號加客戶端類型作為鍵,這樣手機qq登錄的鍵是 123456_手機,電腦登錄的鍵是123456_電腦,這樣在保存到Redis的時候就不會發生沖突,可以保持手機和電腦同時在線
但是有一個人用手機登錄qq 123456了,就會覆蓋redis中鍵為123456_手機的Token信息,導致原先登錄那個人的信息失效,被強制下線
來展示代碼
判斷是否可以登錄
客戶端類型實體
這是我們的客戶端類型:
獲取token需要的用戶信息和登錄時間的實體Model
這是我們的用戶Model
生成Token用的實體
登錄成功,通過JWT非對稱加密生成Token
下面是JWT加密和解密的代碼
將獲取到的Token保存到Redis
基於Token認證的多點登錄和WebApi保護