介面的安全性主要圍繞token、timestamp和sign三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看：
token授權機制：使用者使用使用者名稱密碼登入後伺服器給客戶端返回乙個token（通常是uuid），並將token-userid以鍵值對的形式存放在快取伺服器中。服務端接收到請求後進行token驗證，如果token不存在，說明請求無效。
時間戳超時機制：使用者每次請求都帶上當前時間的時間戳timestamp，服務端接收到timestamp後跟當前時間進行比對，如果時間差大於一定時間（比如5分鐘），則認為該請求失效，這個時間要保證足夠完成本次請求的同時盡量短，可以減少快取伺服器的壓力（見簽名機制）。
簽名機制：將token和時間戳加上其他請求引數就行md5或sha-1演算法（可根據情況加點鹽）加密，加密後的資料為本次請求的簽名sign，並將該簽名存放到快取伺服器中，超時時間設定為跟時間戳的超時時間一致（這就是為什麼要盡量短，二者時間一致可以保證無論在timestamp規定時間內還是外本url都只能訪問一次）。服務端接收到請求後以同樣的演算法得到簽名，並跟當前的簽名進行比對，如果不一樣，說明引數被更改過，直接返回錯誤標識。同乙個簽名只能使用一次，如果發現快取伺服器中已經存在了本次簽名，則拒絕服務。
整個流程如下：
1、客戶端通過使用者名稱密碼登入伺服器並獲取token
2、客戶端生成時間戳timestamp，並將timestamp作為其中乙個引數
3、客戶端將所有的引數，包括token和timestamp按照自己的演算法進行排序加密得到簽名sign
4、將token、timestamp和sign作為請求時必須攜帶的引數加在每個請求的url後邊（http://url/request?token=123×tamp=123&sign=123123123）
5、服務端寫乙個過濾器對token、timestamp和sign進行驗證，只有三個引數都正確且在規定時間內，本次請求才有效
如果黑客劫持了請求，並對請求中的引數進行了修改，簽名就無法通過；
如果黑客使用已經劫持的url進行dos攻擊，伺服器則會因為快取伺服器中已經存在簽名而拒絕服務，所以dos攻擊也是不可能的；
如果黑客隔一段時間進行一次dos攻擊（假如這個時間大於簽名在快取伺服器中的快取時長），則會因為時間戳超時而無法完成請求，這就是為什麼簽名的快取時長要跟時間戳的超時時長一樣。
如果簽名演算法和使用者名稱密碼都暴露了，那齊天大聖來了估計也不好使吧。。。。
API介面安全性設計
介面的安全性主要圍繞token timestamp和sign三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看 token授權機制 使用者使用使用者名稱密碼登入後伺服器給客戶端返回乙個token 通常是uuid 並將token userid以鍵值對的形式存放在快取伺服器中。服務端接收...
API介面安全性設計
介面的安全性主要圍繞token timestamp和sign三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看 token授權機制 使用者使用使用者名稱密碼登入後伺服器給客戶端返回乙個token 通常是uuid 並將token userid以鍵值對的形式存放在快取伺服器中。服務端接收...
API介面安全性設計
介面的安全性主要圍繞token timestamp和sign三個機制展開設計，保證介面的資料不會被篡改和重複呼叫，下面具體來看 token授權機制 使用者使用使用者名稱密碼登入後伺服器給客戶端返回乙個token 通常是uuid 並將token userid以鍵值對的形式存放在快取伺服器中。服務端接收...