Token ,Cookie和Session的區別

2021-08-29 10:12:27 字數 2665 閱讀 2192

在做介面測試時,經常會碰到請求引數為token的型別,但是可能大部分測試人員對token,cookie,session的區別還是一知半解。為此我查閱大量的資料做了如下總結。 

此篇文章也許是最全最通俗的關於token ,cookie和session的區別的文章,好好揣摩文章的每乙個字,也許你會有更深的理解!

cookie

cookie 是乙個非常具體的東西,指的就是瀏覽器裡面能永久儲存的一種資料,僅僅是瀏覽器實現的一種資料儲存功能。

cookie由伺服器生成,傳送給瀏覽器,瀏覽器把cookie以kv形式儲存到某個目錄下的文字檔案內,下一次請求同一**時會把該cookie傳送給伺服器。由於cookie是存在客戶端上的,所以瀏覽器加入了一些限制確保cookie不會被惡意使用,同時不會佔據太多磁碟空間,所以每個域的cookie數量是有限的。

session

session 從字面上講,就是會話。這個就類似於你和乙個人交談,你怎麼知道當前和你交談的是張三而不是李四呢?對方肯定有某種特徵(長相等)表明他就是張三。

session 也是類似的道理,伺服器要知道當前發請求給自己的是誰。為了做這種區分,伺服器就要給每個客戶端分配不同的「身份標識」,然後客戶端每次向伺服器發請求的時候,都帶上這個「身份標識」,伺服器就知道這個請求來自於誰了。至於客戶端怎麼儲存這個「身份標識」,可以有很多種方式,對於瀏覽器客戶端,大家都預設採用 cookie 的方式。

伺服器使用session把使用者的資訊臨時儲存在了伺服器上,使用者離開**後session會被銷毀。這種使用者資訊儲存方式相對cookie來說更安全,可是session有乙個缺陷:如果web伺服器做了負載均衡,那麼下乙個操作請求到了另一台伺服器的時候session會丟失。

token

token的意思是「令牌」,是使用者身份的驗證方式,最簡單的token組成:uid(使用者唯一的身份標識)、time(當前時間的時間戳)、sign(簽名,由token的前幾位+鹽以雜湊演算法壓縮成一定長的十六進製制字串,可以防止惡意第三方拼接token請求伺服器)。還可以把不變的引數也放進token,避免多次查庫

傳統身份驗證

http 是一種沒有狀態的協議,也就是它並不知道是誰是訪問應用。這裡我們把使用者看成是客戶端,客戶端使用使用者名稱還有密碼通過了身份驗證,不過下回這個客戶端再傳送請求時候,還得再驗證一下。

解決的方法就是,當使用者請求登入的時候,如果沒有問題,我們在服務端生成一條記錄,這個記錄裡可以說明一下登入的使用者是誰,然後把這條記錄的 id 號傳送給客戶端,客戶端收到以後把這個 id 號儲存在 cookie 裡,下次這個使用者再向服務端傳送請求的時候,可以帶著這個 cookie ,這樣服務端會驗證乙個這個 cookie 裡的資訊,看看能不能在服務端這裡找到對應的記錄,如果可以,說明使用者已經通過了身份驗證,就把使用者請求的資料返回給客戶端。

上面說的就是 session,我們需要在服務端儲存為登入的使用者生成的 session ,這些 session 可能會儲存在記憶體,磁碟,或者資料庫裡。我們可能需要在服務端定期的去清理過期的 session 。

基於 token 的身份驗證

使用基於 token 的身份驗證方法,在服務端不需要儲存使用者的登入記錄。大概的流程是這樣的:

那麼我的問題來了: 1.伺服器上的token儲存到資料庫中,每次查詢會不會很費時。如果不儲存到資料庫,應該儲存到**呢。 2.客戶端得到的token肯定要加密儲存的,傳送token的時候再解密。儲存到資料庫還是配置檔案呢?

token是個憑條,不過它比門票溫柔多了,門票丟了重新花錢買,token丟了重新操作下認證乙個就可以了,因此token丟失的代價是可以忍受的——前提是你別丟太頻繁,要是讓使用者隔三差五就認證一次那就損失使用者體驗了。

基於這個出發點,如果你認為用資料庫來保持token查詢時間太長,會成為你系統的瓶頸或者隱患,可以放在記憶體當中。 

比如memcached、redis,kv方式很適合你對token查詢的需求。 

這個不會太佔記憶體,比如你的token是32位字串,要是你的使用者量在百萬級或者千萬級,那才多少記憶體。 

要是資料量真的大到單機記憶體扛不住,或者覺得一宕機全丟風險大,只要這個token生成是足夠均勻的,高低位切一下分到不同機器上就行,記憶體絕對不會是問題。

客戶端方面這個除非你有乙個非常安全的辦法,比如作業系統提供的隱私資料儲存,那token肯定會存在洩露的問題。比如我拿到你的手機,把你的token拷出來,在過期之前就都可以以你的身份在別的地方登入。 

解決這個問題的乙個簡單辦法 

1、在儲存的時候把token進行對稱加密儲存,用時解開。 

2、將請求url、時間戳、token三者進行合併加鹽簽名,服務端校驗有效性。 

這兩種辦法的出發點都是:竊取你儲存的資料較為容易,而反彙編你的程式hack你的加密解密和簽名演算法是比較難的。然而其實說難也不難,所以終究是防君子不防小人的做法。話說加密儲存乙個你要是被人扒開客戶端看也不會被噴明文儲存…… 

方法1它拿到儲存的密文解不開、方法2它不知道你的簽名演算法和鹽,兩者可以結合食用。 

但是如果token被人拷走,他自然也能植入到自己的手機裡面,那到時候他的手機也可以以你的身份來用著,這你就瞎了。 

於是可以提供乙個讓使用者可以主動expire乙個過去的token類似的機制,在被盜的時候能遠端止損。

在網路層面上token明文傳輸的話會非常的危險,所以建議一定要使用https,並且把token放在post body裡。

Token ,Cookie和Session的區別

cookie 是乙個非常具體的東西,指的就是瀏覽器裡面能永久儲存的一種資料,僅僅是瀏覽器實現的一種資料儲存功能。cookie由伺服器生成,傳送給瀏覽器,瀏覽器把cookie以kv形式儲存到某個目錄下的文字檔案內,下一次請求同一 時會把該cookie傳送給伺服器。由於cookie是存在客戶端上的,所以...

Token ,Cookie和Session的區別

在做介面測試時,經常會碰到請求引數為token的型別,但是可能大部分測試人員對token,cookie,session的區別還是一知半解。為此我查閱大量的資料做了如下總結。此篇文章也許是最全最通俗的關於token cookie和session的區別的文章,好好揣摩文章的每乙個字,也許你會有更深的理解...

Token ,Cookie和Session的區別

在做介面測試時,經常會碰到請求引數為token的型別,但是可能大部分測試人員對token,cookie,session的區別還是一知半解。cookie 是乙個非常具體的東西,指的就是瀏覽器裡面能永久儲存的一種資料,僅僅是瀏覽器實現的一種資料儲存功能。cookie由伺服器生成,傳送給瀏覽器,瀏覽器把c...