Cookie、Session、Token

如今作的社區管理項目分爲三端:web,app,小程序端,要作到三端適配,那麼就存在用戶登陸的問題,那麼就須要考慮如何作到三端適配問題,因此就隨便記錄了cookie,session,token問題;

1.什麼是Cookie？

 

 Cookie 技術產生源於 HTTP 協議在互聯網上的急速發展。隨着互聯網時代的策馬奔騰，帶寬等限制不存在了，人們須要更復雜的互聯網交互活動，就必須同服務器保持活動狀態（簡稱：保活）。

 

因而，在瀏覽器發展初期，爲了適應用戶的需求技術上推出了各類保持 Web 瀏覽狀態的手段，其中就包括了 Cookie 技術。Cookie 在計算機中是個存儲在瀏覽器目錄中的文本文件，當瀏覽器運行時，存儲在 RAM 中發揮做用 （此種 Cookies 稱做 Session Cookies），一旦用戶從該網站或服務器退出，Cookie 可存儲在用戶本地的硬盤上 （此種 Cookies 稱做 Persistent Cookies）。

 

Cookie 起源：1993 年，網景公司僱員 Lou Montulli 爲了讓用戶在訪問某網站時，進一步提升訪問速度，同時也爲了進一步實現我的化網絡，發明了今天普遍使用的 Cookie。（因此，適當的偷懶也會促進人類計算機發展史的一小步~）

 

Cookie時效性：目前有些 Cookie 是臨時的，有些則是持續的。臨時的 Cookie 只在瀏覽器上保存一段規定的時間，一旦超過規定的時間，該 Cookie 就會被系統清除。

 

Cookie使用限制：Cookie 必須在 HTML 文件的內容輸出以前設置；不一樣的瀏覽器 (Netscape Navigator、Internet Explorer) 對 Cookie 的處理不一致，使用時必定要考慮；客戶端用戶若是設置禁止 Cookie，則 Cookie 不能創建。 而且在客戶端，一個瀏覽器能建立的 Cookie 數量最多爲 300 個，而且每一個不能超過 4KB，每一個 Web 站點能設置的 Cookie 總數不能超過 20 個。

執行流程：

 

A：首先，客戶端會發送一個http請求到服務器端。

 

B： 服務器端接受客戶端請求後，發送一個http響應到客戶端，這個響應頭，其中就包含Set-Cookie頭部。 

 

C：在客戶端發起的第二次請求（注意：若是服務器須要咱們帶上Cookie，咱們就須要在B步驟上面拿到這個Cookie而後做爲請求頭一塊兒發起第二次請求），提供給了服務器端能夠用來惟一標識客戶端身份的信息。這時，服務器端也就能夠判斷客戶端是否啓用了cookies。儘管，用戶可能在和應用程序交互的過程當中忽然禁用cookies的使用，可是，這個狀況基本是不太可能發生的，因此能夠不加以考慮，這在實踐中也被證實是對的。

 

爲了方便理解，能夠先看下這張流程執行圖加深概念

 

 

那麼，在瀏覽器上面的請求頭和Cookie在那？下圖給你們截取了其中一種。

 

 

那麼，上面都是談瀏覽器上的Cookie，那麼在Android開發中，咱們該如何去管理和使用Cookie？

Okhttp做爲經典到爆的網絡框架，它的API（本文是基於Okhttp3.0版本以上，3.0如下的版本API有所不一樣）是經過OkhttpClient中的CookieJar或者攔截器去管理Cookie的。理論上，咱們只需在構建單例OkhttpClient的時候，設置cookiejar或者攔截器，而後具體的操做（具體的操做也就是保存Cookie，取Cookie），Okhttp框架就會幫咱們自動管理Cookie。

2.Session

 

Session是對於服務端來講的，客戶端是沒有Session一說的。Session是服務器在和客戶端創建鏈接時添加客戶端鏈接標誌，最終會在服務器軟件（Apache、Tomcat、JBoss）轉化爲一個臨時Cookie發送給給客戶端，當客戶端第一請求時服務器會檢查是否攜帶了這個Session（臨時Cookie），若是沒有則會添加Session，若是有就拿出這個Session來作相關操做。

 

在這裏引用別人家的一個小故事來加深印象：

 

在說session是啥以前，咱們先來講說爲何會出現session會話，它出現的機理是什麼？

 

咱們知道，咱們用瀏覽器打開一個網頁，用到的是HTTP協議，瞭解計算機的應該都知道這個協議，它是無狀態的，什麼是無狀態呢？就是說這一次請求和上一次請求是沒有任何關係的，互不認識的，沒有關聯的。可是這種無狀態的的好處是快速。因此就會帶來一個問題就是，我但願幾個請求的頁面要有關聯，好比：我在www.a.com/login.php裏面登錄了，我在www.a.com/index.php 也但願是登錄狀態，可是，這是2個不一樣的頁面，也就是2個不一樣的HTTP請求，這2個HTTP請求是無狀態的，也就是無關聯的，因此沒法單純的在index.php中讀取到它在login.php中已經登錄了！

 

 那咋搞呢？我不可能這2個頁面我都去登錄一遍吧。或者用笨方法這2個頁面都去查詢數據庫，若是有登錄狀態，就判斷是登錄的了。這種查詢數據庫的方案雖然可行，可是每次都要去查詢數據庫不是個事，會形成數據庫的壓力。 因此正是這種訴求，這個時候，一個新的客戶端存儲數據方式出現了：cookie。cookie是把少許的信息存儲在用戶本身的電腦上，它在一個域名下是一個全局的，只要設置它的存儲路徑在域名www.a.com下 ，那麼當用戶用瀏覽器訪問時，php就能夠從這個域名的任意頁面讀取cookie中的信息。因此就很好的解決了我在www.a.com/login.php頁面登錄了，我也能夠在www.a.com/index.php獲取到這個登錄信息了。

 

同時又不用反覆去查詢數據庫。 雖然這種方案很不錯，也很快速方便，可是因爲cookie 是存在用戶端，並且它自己存儲的尺寸大小也有限，最關鍵是用戶能夠是可見的，並能夠隨意的修改，很不安全。那如何又要安全，又能夠方便的全局讀取信息呢？因而，這個時候，一種新的存儲會話機制：session 誕生了。

 

 Session 就是在一次會話中解決2次HTTP的請求的關聯，讓它們產生聯繫，讓2兩個頁面都能讀取到找個這個全局的session信息。session信息存在於服務器端，因此也就很好的解決了安全問

 

 3 token

token是用戶身份的驗證方式，咱們一般叫它：令牌。最簡單的token組成:uid(用戶惟一的身份標識)、time(當前時間的時間戳)、sign(簽名，由token的前幾位+鹽以哈希算法壓縮成必定長的十六進制字符串，能夠防止惡意第三方拼接token請求服務器)。還能夠把不變的參數也放進token，避免屢次查庫。

 

應用場景：

 

A：當用戶首次登陸成功（註冊也是一種能夠適用的場景）以後, 服務器端就會生成一個 token 值，這個值，會在服務器保存token值(保存在數據庫中)，再將這個token值返回給客戶端.

 

B：客戶端拿到 token 值以後,進行本地保存。（SP存儲是你們可以比較支持和易於理解操做的存儲）

 

C：當客戶端再次發送網絡請求(通常不是登陸請求)的時候,就會將這個 token 值附帶到參數中發送給服務器.

 

D：服務器接收到客戶端的請求以後,會取出token值與保存在本地(數據庫)中的token值作對比

 

對比一：若是兩個 token 值相同， 說明用戶登陸成功過!當前用戶處於登陸狀態!

 

對比二：若是沒有這個 token 值, 則說明沒有登陸成功.

 

對比三：若是 token 值不一樣: 說明原來的登陸信息已經失效,讓用戶從新登陸.

 

Cookie和Session的區別：

 

一、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。

 

二、cookie不是很安全，別人能夠分析存放在本地的cookie並進行cookie欺騙,考慮到安全應當使用session。

 

三、session會在必定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能,考慮到減輕服務器性能方面，應當使用cookie。

 

四、單個cookie保存的數據不能超過4K，不少瀏覽器都限制一個站點最多保存20個cookie。

 

五、因此我的建議：

 

將登錄信息等重要信息存放爲session

 

其餘信息若是須要保留，能夠放在cookie中

 

Token 和 Session 的區別：

 

session和 token並不矛盾，做爲身份認證token安全性比session好，由於每一個請求都有簽名還能防止監聽以及重放攻擊，而session就必須靠鏈路層來保障通信安全了。如上所說，若是你須要實現有狀態的會話，仍然能夠增長session來在服務器端保存一些狀態。

 

App一般用restful api跟server打交道。Rest是stateless的，也就是app不須要像browser那樣用cookie來保存session,所以用session token來標示本身就夠了，session/state由api server的邏輯處理。若是你的後端不是stateless的rest api,那麼你可能須要在app裏保存session.能夠在app裏嵌入webkit,用一個隱藏的browser來管理cookie session.

 

Session是一種HTTP存儲機制，目的是爲無狀態的HTTP提供的持久機制。所謂Session認證只是簡單的把User信息存儲到Session裏，由於SID的不可預測性，暫且認爲是安全的。這是一種認證手段。而Token，若是指的是OAuth Token或相似的機制的話，提供的是 認證 和 受權 ，認證是針對用戶，受權是針對App。

 

其目的是讓 某App有權利訪問 某用戶 的信息。這裏的Token是惟一的。不能夠轉移到其它App上，也不能夠轉到其它 用戶 上。轉過來講Session。Session只提供一種簡單的認證，即有此SID，即認爲有此User的所有權利。是須要嚴格保密的，這個數據應該只保存在站方，不該該共享給其它網站或者第三方App。因此簡單來講，若是你的用戶數據可能須要和第三方共享，或者容許第三方調用API接口，用Token。若是永遠只是本身的網站，本身的App，用什麼就無所謂了。

 

token就是令牌，好比你受權（登陸）一個程序時，他就是個依據，判斷你是否已經受權該軟件；cookie就是寫在客戶端的一個txt文件，裏面包括你登陸信息之類的，這樣你下次在登陸某個網站，就會自動調用cookie自動登陸用戶名；session和cookie差很少，只是session是寫在服務器端的文件，也須要在客戶端寫入cookie文件，可是文件裏是你的瀏覽器編號.Session的狀態是存儲在服務器端，客戶端只有session id；而Token的狀態是存儲在客戶端。

在三端適配時候:因此在filter裏面先去cookie找用戶信息,若是沒有用戶信息,那麼就會去authentiration頭中去獲取用戶信息,若是用戶信息沒有,那麼就不會有隻有這樣才能夠維護用戶的登陸信息.

cookie和session均可以i保存用戶信息,token也是能夠的,存儲的是用戶的獨立信息惟一標識,具體的用戶的權限還有相關內容還得得去數據查詢,只是存儲得是惟一標識,固然也能夠存儲信息,信息存儲再用戶端是不安全得,存在服務端是安全得,

在分佈式得時候,會存在session不共享得問題,因此須要咱們去使用redis或者cas服務器來存儲