token原理

token原理
1.和session有很大關系哦。

jsp生成表單時，在表單中插入一個隱藏<input>字段，該字段就是保存在頁面端的token字符串，同時把該字符串存入session中。等到用戶提交表單時，會一並提交該隱藏的token字符串
。在服務器端，查看下是否在session中含有與該token字符串相等的字符串。如果有，那么表明是第一次提交該表單，然后刪除存放於session端的token字符串，再做正常業務邏輯流程
；如果沒有，那么表示該表單被重復提交，做非正常流程處理，可以警告提示也可以什么也不做。

2.token
你可以把他當做一個令牌，當第一次訪問時設置一個令牌保存,一般我們保存在session中，當啟動令牌時，那么就去檢測令牌是否一致，然后銷毀令牌或者重置令牌，這樣第二次再用次
令牌訪問時，就會不一致了，直接提示重復提交了

3.token是服務器給的，第一次登陸用戶名和密碼的時候，使用用戶名去換取token，這樣就類似於token：某人 一個鍵值對了。
4.一般token都有時長限制，token過期就重新登錄
之后每次請求就直接使用token來請求數據 不需要每次都加用戶名和密碼去請求數據。

5,。兩者在原理上都是通過session
token來實現的。當客戶端請求頁面時，服務器會生成一個隨機數Token，並且將Token放置到session當中，然后將Token發給客戶端（一般通過構造hidden表單）。下次客戶端提交請求時
，Token會隨着表單一起提交到服務器端。

6.究竟能起什么作用？驗證身份？防止重復提交？可偽造嗎？

6.最近正好打算寫一個類似Token表單驗證的東西
個人覺得如果單是表單驗證的話似乎用Session比Cookie要好一些
但如果是跨子域名的話好像session傳不過去

7.我們現在APP功能需要實現登陸一次，下次再打開應用的時候就不需要再去登陸了。
搜了下資料，常用的說是用token做比較好，具體怎么實現呢？大家有沒有參考文檔？
PS:我是服務端
前端是android和IOS
或者有其他辦法保持登陸狀態更好。
8.web端和服務器端進行http連接時，會使用cookie來進行狀態的保存，讓本來無狀態的http變得“有狀態”，你可以參考一下。
8.本地存儲可以實現你的需求
9.APP每次登陸服務端將分配一個token給APP端，APP端所做的就是緩存token在本地。每次網絡請求都將帶上這個token，服務器每次收到網絡請求驗證token就行了。。。如果要讓APP更
換token。驗證不通過就行了 。
10.在很多app中，都需要用戶的登錄操作。登錄，就需要用到用戶名和密碼。為了安全起見，暴露明文密碼的次數越少越好。怎么能最大程度避免泄露用戶的密碼呢？在登錄后，app后端
怎么去驗證和維持用戶的登錄狀態呢？在本文中，給出了一套用戶登錄的解決方案，以供大家參考。

11.在app后端，怎么避免每次驗證用戶身份都需要傳輸用戶名和密碼呢？

13.一個生活的模型就是：

　　假設服務器是個房間，里面有個房間管理員，房間上的門有把鎖，這把鎖有兩種打開方式:

　　1. 輸入了這把鎖上注冊的用戶名和密碼，就能打開

　　2. 用房間管理員提供的鑰匙打開

　　a.當第一次使用用戶名和密碼打開了這把鎖后，進入房間，找到房間管理員，讓他提供一把鑰匙。

　　b.那以后每次需要進入這個房間，就用這把鑰匙就行了，不用擔心旁邊有人偷看到自己的用戶名和密碼.

　　c.決定有一段時間不進入這個房間，又怕鑰匙被偷，就進入房間里，把鑰匙還給管理員，讓管理員把鑰匙毀滅

　　a就是登錄的操作，ｂ就是驗證身份的操作，ｃ就是退出登錄的操作.

理論版的描述如下：

　　(1) 服務器接收到app發送的用戶名和密碼后，驗證用戶名和密碼是否正確。

　　如果錯誤則返回錯誤信息。

　　如果驗證正確，生成一個隨機的不重復的token字符串（例如"daf32da456hfdh"），在redis或memcache中維護一個映視表，建立token字符串和用戶信息的對應關系表，例如，把token字符串"daf32da456hfdh"和用戶id"5"對應起來。

　　(2) 服務器把token字符串返回給app，app把這個token字符串保存起來，作為登錄的驗證。

　　(3) 當需要驗證用戶身份的操作時，必須要把token字符串傳給服務器驗證身份。

　　例如，api "test.com/user/update"是更新用戶的信息，必須要驗證用戶的身份.當調用api "test.com/user/update"時，把token字符串"daf32da456hfdh"放在url上，變成"test.com/user/update?token=daf32da456hfdh" .

　　當服務器接收到這個api請求，知道要驗證用戶身份的，於是，就把參數中token的值"daf32da456hfdh"取出來，在(1)中建立的token字符串和用戶信息的對應關系表查找，如果發現沒這個token值的，則返回驗證失敗的信息。如果發現有這個token值，則獲取這個用戶的信息,進行相關的更新操作。

(4) 當用戶退出登錄時，需要通過調用api，讓服務器把這個用戶對於的token字符串刪除.

　　例如，api "test.com/user/logout"是退出登錄的api,也要驗證用戶身份， 則調用"test.com/user/logout?token=daf32da456hfdh" 。當服務器接到退出登錄的api請求時，在(1)中建立的token字符串和用戶信息的對應關系表查找token字符串，把token和用戶信息都刪除即可。

　　注意：這個方案並不是十分安全，這個身份驗證是依賴於token字符串。如果用戶泄漏了自己的url, 那很大程度上token也被別人泄漏了，就相當於鑰匙被人復制了一份。在下篇的通訊安全中，會描述一個防止token在通訊中泄漏的方案。

20.在前一篇文章<15.app后端怎么設計用戶登錄方案>中，服務器中驗證用戶名和密碼都正確后,生成一個隨機的不重復的token字符串（例如"daf32da456hfdh"），在redis或memcache中維護一個映視表，建立token字符串和用戶信息的對應關系表，例如，把token字符串"daf32da456hfdh"和用戶id"5"對應起來，服務器把token字符串返回給app用作身份驗證。

　　這個身份驗證是依賴於token字符串。如果用戶泄露了自己的url, 那很大程度上token也被別人泄漏了。

　　怎么防止token被泄露？不讓token在網絡上傳輸就行。

app和后端的通訊過程中，api請求有可能被別人截取或不小心泄露。那么，怎么保證api請求的安全呢？在這篇文章中，介紹一種常見的保證api請求安全的做法--url簽名。

1. url簽名詳解

　　在前一篇文章<15.app后端怎么設計用戶登錄方案>中，服務器中驗證用戶名和密碼都正確后,生成一個隨機的不重復的token字符串（例如"daf32da456hfdh"），在redis或memcache中維護一個映視表，建立token字符串和用戶信息的對應關系表，例如，把token字符串"daf32da456hfdh"和用戶id"5"對應起來，服務器把token字符串返回給app用作身份驗證。

　　這個身份驗證是依賴於token字符串。如果用戶泄露了自己的url, 那很大程度上token也被別人泄漏了。

　　怎么防止token被泄露？不讓token在網絡上傳輸就行。

　　注意，這個url簽名的方法是和前面＜15.app后端怎么設計用戶登錄方案＞緊密聯系在一起的，沒看過前面一篇文章請先看。

　　(1) 服務器中驗證用戶名和密碼都正確后，把token字符串和用戶id都返回給客戶端，例如token字符串"daf32da456hfdh"和用戶id"5"。

　　(2)假設api請求為"test.com/user/info", 通過token字符串"daf32da456hfdh"生成md5簽名后: md5("test.com/user/info&token=daf32da456hfdh”)= C99DC0C22437AC275C08CE4A9708B25A

　　於是，api請求加上簽名和用戶標識后就是　＂test.com/user/info?userId=5&sign= C99DC0C22437AC275C08CE4A9708B25A＂

　　(3)服務器接收到這個url后，用(2)的算法生成簽名和sign參數對比，如果發現相等的話，就表示這個url是有有效,那就繼續執行這個api調用。

　　用上面的這個方法，就能避免token在api調用時泄露。

　　上面的方法還有一個問題，因為這個api請求＂test.com/user/info?userId=5&sign= C99DC0C22437AC275C08CE4A9708B25A＂上沒有過期時間，假設別人拿到這個api的請求，就能反復調用了。

　　改進方法是在傳遞的參數中增加時間戳，當發現這個時間戳離現在的時間已經很久了，就判斷這個url已經失效了。

　　但用時間戳怎么保證app的時間和服務器的時間同步？在app每次啟動時和服務器同步時間，然后在app內建一個時鍾，時間戳在這個app的內部時鍾獲取，防止用戶修改了手機的時間導致時間不一致。

　　於是有了下面的改進方法：

　　(1)假設api請求為"test.com/user/info", 用token字符串"daf32da456hfdh"和時間戳生成md5簽名后: md5("test.com/user/info?userId=5&token=daf32da456hfdh&timestamp=1425860757”)= C116161A6F430343B6CECF08562F1371

　　於是，api請求加上簽名和用戶標識后就是　＂test.com/user/info?userId=5&timestamp=1425860757&sign= C116161A6F430343B6CECF08562F1371＂

　　(2)服務器接收到這個api請求，如果發現收到這個url請求的時間和time=1425860757相隔很久，就判斷出這個url是被別人截取來反復調用了。如果時間合法，那就用(1)的算法再判斷sign是否一致

2. url簽名的不足之處

　　url簽名有兩個缺點：

　　1.當用戶第一次登錄后token是明文返回，有被截取的風險

　　2. url簽名只能保護token值卻沒法保護其他敏感數據,例如，當用戶更新自己的個人信息時，所有的信息在傳輸過程中應該是被加密的

　　怎么解決這兩個問題？使用下篇介紹的對稱加密的算法就可以了。