token詳解

原文鏈接:https://blog.csdn.net/cmj6706/article/details/79032703

一、我們先解釋一下Token的含義
1、Token的引入:
Token是在客戶端頻繁向服務端請求數據,服務端頻繁的去數據庫查詢用戶名和密碼並進行對比,判斷用戶名和密碼正確與否,並作出相應提示,在這樣的背景下,Token便應運而生。
2、Token的定義:
Token是服務端生成的一串字符串,以作客戶端進行請求的一個令牌,當第一次登錄後,服務器生成一個Token便將此Token返回給客戶端,以後客戶端只需帶上這個Token前來請求數據即可,無需再次帶上用戶名和密碼。
3、使用Token的目的:
Token的目的是爲了減輕服務器的壓力,減少頻繁的查詢數據庫,使服務器更加健壯。
4.Token 的優點:
擴展性更強,也更安全點,非常適合用在 Web 應用或者移動應用上。Token 的中文有人翻譯成 “令牌”,我覺得挺好,意思就是,你拿着這個令牌,才能過一些關卡。
5.Token一般用在三個地方:
①防止表單重複提交
②anti csrf攻擊(跨站點請求僞造)
③身份驗證(單點登錄)
瞭解了Token的意義後,我們就更明確的知道爲什麼要用他了。

二、如何使用Token?
這是本文的重點,在這裏我就介紹常用的兩種方式。
1、用設備號/設備mac地址作爲Token(推薦)
客戶端:客戶端在登錄的時候獲取設備的設備號/mac地址,並將其作爲參數傳遞到服務端。
服務端:服務端接收到該參數後,便用一個變量來接收同時將其作爲Token保存在數據庫,並將該Token設置到session中,客戶端每次請求的時候都要統一攔截,並將客戶端傳遞的token和服務器端session中的token進行對比,如果相同則放行,不同則拒絕。 分析:此刻客戶端和服務器端就統一了一個唯一的標識Token,而且保證了每一個設備擁有了一個唯一的會話。該方法的缺點是客戶端需要帶設備號/mac地址作爲參數傳遞,而且服務器端還需要保存;優點是客戶端不需重新登錄,只要登錄一次以後一直可以使用,至於超時的問題是有服務器這邊來處理,如何處理?若服務器的Token超時後,服務器只需將客戶端傳遞的Token向數據庫中查詢,同時並賦值給變量Token,如此,Token的超時又重新計時。
2、用session值作爲Token
客戶端:客戶端只需攜帶用戶名和密碼登陸即可。
客戶端:客戶端接收到用戶名和密碼後並判斷,如果正確了就將本地獲取sessionID作爲Token返回給客戶端,客戶端以後只需帶上請求數據即可。
分析:這種方式使用的好處是方便,不用存儲數據,但是缺點就是當session過期後,客戶端必須重新登錄才能進行訪問數據。
三、使用過程中出現的問題以及解決方案?
 剛纔我們輕鬆介紹了Token的兩種使用方式,但是在使用過程中我們還出現各種問題,Token第一種方法中我們隱藏了一個在網絡不好或者併發請求時會導致多次重複提交數據的問題。
該問題的解決方案:將session和Token套用,如此便可解決,如何套用呢?請看這段解釋:
session是一個在單個操作人員整個操作過程中,與服務端保持通信的唯一識別信息。在同一操作人員的多次請求中,session始終保證是同一個對象,而不是多個對象,因爲可以對其加鎖。當同一操作人員多個請求進入時,可以通過session限制只能單向通行
本文正是通過使用session以及在session中加入token,來驗證同一個操作人員是否進行了併發重複的請求,在後一個請求到來時,使用session中的token驗證請求中的token是否一致,當不一致時,被認爲是重複提交,將不准許通過。
 這就是解決重複提交的方案。
四、基於 Token 的身份驗證方法
使用基於 Token 的身份驗證方法,在服務端不需要存儲用戶的登錄記錄。大概的流程是這樣的:
客戶端使用用戶名跟密碼請求登錄
服務端收到請求,去驗證用戶名與密碼
驗證成功後,服務端會簽發一個 Token,再把這個 Token發送給客戶端
客戶端收到 Token 以後可以把它存儲起來,比如放在Cookie 裏或者 Local Storage 裏
客戶端每次向服務端請求資源的時候需要帶着服務端簽發的 Token
服務端收到請求,然後去驗證客戶端請求裏面帶着的 Token,如果驗證成功,就向客戶端返回請求的數據

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章