不要急，源**分享在最底部，先問大家乙個問題，你在寫開放的api介面時是如何保證資料的安全性的？先來看看有哪些安全性問題在開放的api介面中，我們通過http post或者get方式請求伺服器的時候，會面臨著許多的安全性問題，例如：
請求**(身份)是否合法？
請求引數被篡改？
請求的唯一性(不可複製)
為了保證資料在通訊時的安全性，我們可以採用引數簽名的方式來進行相關驗證。
案列分析
後台介面：以下簡稱api
上**啦 -_-！
一、不進行驗證的方式
api查詢介面：
如上，這種方式簡單粗暴，通過呼叫getproducts方法即可獲取產品列表資訊了，但是 這樣的方式會存在很嚴重的安全性問題，沒有進行任何的驗證，大家都可以通過這個方法獲取到產品列表，導致產品資訊洩露。
那麼，如何驗證呼叫者身份呢？如何防止引數被篡改呢？
二、md5引數簽名的方式
我們對api查詢產品介面進行優化：
2.sign簽名，呼叫api 時需要對請求引數進行簽名驗證，簽名方式如下：
a. 按照請求引數名稱將所有請求引數按照字母先後順序排序得到：keyvaluekeyvalue...keyvalue 字串如：將arong=1,mrong=2,crong=3 排序為：arong=1, crong=3,mrong=2 然後將引數名和引數值進行拼接得到引數字串：arong1crong3mrong2。
b. 將secret加在引數字串的頭部後進行md5加密 ,加密後的字串需大寫。即得到簽名sign
新api介面**:
=bcc7c71cf93f9cdbdb88671b701d8a35&引數1=value1&引數2=value2.......
注：secret 僅作加密使用, 為了保證資料安全請不要在請求引數中使用。
如上，優化後的請求多了key和sign引數，這樣請求的時候就需要合法的key和正確簽名sign才可以獲取產品資料。這樣就解決了身份驗證和防止引數篡改問題，如果請求引數被人拿走，沒事，他們永遠也拿不到secret,因為secret是不傳遞的。再也無法偽造合法的請求。
但是...這樣就夠了嗎？細心的同學可能會發現，如果我獲取了你完整的鏈結，一直使用你的key和sign和一樣的引數不就可以正常獲取資料了...-_-!是的，僅僅是如上的優化是不夠的
請求的唯一性：
為了防止別人重複使用請求引數問題，我們需要保證請求的唯一性，就是對應請求只能使用一次，這樣就算別人拿走了請求的完整鏈結也是無效的。
唯一性的實現：在如上的請求引數中，我們加入時間戳 ：timestamp（yyyymmddhhmmss），同樣，時間戳作為請求引數之一，也加入sign演算法中進行加密。
新的api介面：
=bcc7c71cf93f9cdbdb88671b701d8a35×tamp=201603261407&引數1=value1&引數2=value2.......
如上，我們通過timestamp時間戳用來驗證請求是否過期。這樣就算被人拿走完整的請求鏈結也是無效的。
sign簽名安全性分析：
通過上面的案例，我們可以看出，安全的關鍵在於參與簽名的secret，整個過程中secret是不參與通訊的，所以只要保證secret不洩露，請求就不會被偽造。
總結 源**：
開放api介面簽名驗證
在寫開放的api介面時如何保證資料的安全性？先來看看有哪些安全性問題在開放的api介面中，我們通過http post或者get方式請求伺服器的時候，會面臨著許多的安全性問題，例如 請求 身份 是否合法？請求引數被篡改？請求的唯一性 不可複製 為了保證資料在通訊時的安全性，我們可以採用引數簽名的方式來...
開放api介面簽名驗證
不要急，源 分享在最底部，先問大家乙個問題，你在寫開放的api介面時是如何保證資料的安全性的？先來看看有哪些安全性問題在開放的api介面中，我們通過http post或者get方式請求伺服器的時候，會面臨著許多的安全性問題，例如 請求 身份 是否合法？請求引數被篡改？請求的唯一性 不可複製 為了保證...
開放api介面簽名驗證
在寫開放的api介面時是如何保證資料的安全性的？先來看看有哪些安全性問題在開放的api介面中，我們通過http post或者get方式請求伺服器的時候，會面臨著許多的安全性問題，例如 請求 身份 是否合法？請求引數被篡改？請求的唯一性 不可複製 為了保證資料在通訊時的安全性，我們可以採用引數簽名的方...