基於Token認證的多點登陸和WebApi保護

原文 基於Token認證的多點登陸和WebApi保護

在文章中有錯誤的地方,或是有建議或意見的地方,請你們多多指正,郵箱: linjie.rd@gmail.com

　　一天張三,李四,王五,趙六去動物園,張三沒買票,李四製做了個假票,王五買了票,趙六要直接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