最近做項目，碰著一個奇怪的請求，后臺說在調(diào)用接口之前需要驗證簽名和有效時間，當(dāng)場就懵逼了，要生成一個sign簽名，下面來說說怎么做

首先說說大致思路： sign 的生成:按照規(guī)則來是鍵值對的形式(key=value)，拼接的時候按照key=value&key=value(注意:key:后臺所需的參數(shù)名，value：前臺所獲取到的值)&time=系統(tǒng)所獲取的時間&salt = fangzhou(這個參數(shù)按照后臺要求)，而后進行 urlencode 編碼(Java中有方法)，下一步進行MD5加密，如果需要將加密后的值全部轉(zhuǎn)化為大寫(小寫)，Java中有方法直接調(diào)用即可；

接下來說說具體怎么實現(xiàn)：

1.請求數(shù)值的拼接(key=value&key=value):

String name = '宋小寶';String address = '東北';String panameter = 'name='+ name + '& address = '+address;

2.在請求數(shù)值的拼接字符串后面加上時間戳和特定值(根據(jù)后臺要求來)

//獲取系統(tǒng)時間戳Date dt= new Date();Long timeStamp= dt.getTime();String signText = panameter +'&time='+timeStamp + '&salt=fangzhou';

3.拼接完成后,對signText進行 urlencode 編碼

try { String urlencoderText = URLEncoder.encode(signText,'utf-8');} catch (UnsupportedEncodingException e) { e.printStackTrace();}

注:這里會拋出一個異常,直接 try 就可以了,這只是一個Java方法直接調(diào)用就完畢了

4.然后進行md5加密

//MD5加密String md5Text = md5(urlencoderText);

md5加密的方法了,網(wǎng)上有,直接c,v就ok了;

如果要對加密后的值,字母全部轉(zhuǎn)化為大寫(小寫)直接這樣:

//MD5加密String md5Text = md5(urlencoderText).trim().toUpperCase();

注:這是轉(zhuǎn)化為大寫的方法(小寫的方法:直接在字符串后面這樣加就可以了

.trim().toLowerCase();

這樣就可以了;但是你以為這樣就完了? 哥們兒,你想的太簡單了;下面才是最坑...的時候,怎么形容了,直接上代碼吧!

首先說明一點我用的xutils請求框架(具體怎么用我就不說了,相信大家都會用的-中國的程序猿是最棒的);

//設(shè)置請求地址params = new RequestParams(url);//添加請求參數(shù)params.addBodyParameter('name',name);params.addBodyParameter('address',address);//---添加時間戳---params.addBodyParameter('time',timeStamp+'');//加密的參數(shù)-signparams.addBodyParameter('sign',md5Text );

看見沒有，沒有進行轉(zhuǎn)碼的請求參數(shù)，照樣去添加，一個都不能少，反而還多了一個時間戳的參數(shù)，但是注意我上面加密了salt請求參數(shù)，這里沒有添加！！在最后面添加了轉(zhuǎn)碼加密后的請求參數(shù)-sign

而后就用正常的發(fā)請求的流程就可以啦,,,就是這樣--完美

總之一句話-先拼接-后轉(zhuǎn)碼-再加密-再發(fā)請求

補充知識：淺談URL參數(shù)的sign簽名認證

以下內(nèi)容是參考別人的博客內(nèi)容整理，如有不足之處，敬請指正。。。

大家先思考一個問題: 你在寫開放的API接口時是如何保證數(shù)據(jù)的安全性的？

先來看看有哪些安全性問題在開放的api接口中，我們通過http Post或者Get方式請求服務(wù)器的時候，會面臨著許多的安全性問題，例如：

1. 請求來源(身份)是否合法？

2. 請求參數(shù)被篡改？

3. 請求的唯一性(不可復(fù)制)

解決方案：為了保證數(shù)據(jù)在通信時的安全性，我們可以采用參數(shù)簽名的方式來進行相關(guān)驗證。

案列分析

我們通過給某 [移動端(app)] 寫 [后臺接口(api)] 的案例進行分析：

客戶端：以下簡稱app

后臺接口：以下簡稱api

我們通過app查詢產(chǎn)品列表這個操作來進行分析：

app中點擊查詢按鈕==》調(diào)用api進行查詢==》返回查詢結(jié)果==>顯示在app中

一、不進行驗證的方式

api查詢接口：

app調(diào)用：http://api.test.com/getproducts?參數(shù)1=value1.......

如上，這種方式簡單粗暴，通過調(diào)用getproducts方法即可獲取產(chǎn)品列表信息了，但是這樣的方式會存在很嚴(yán)重的安全性問題，沒有進行任何的驗證，大家都可以通過這個方法獲取到產(chǎn)品列表，導(dǎo)致產(chǎn)品信息泄露。

那么，如何驗證調(diào)用者身份呢？如何防止參數(shù)被篡改呢？

二、MD5參數(shù)簽名的方式

我們對api查詢產(chǎn)品接口進行優(yōu)化：

1.給app分配對應(yīng)的key、secret

2.Sign簽名，調(diào)用API 時需要對請求參數(shù)進行簽名驗證，簽名方式如下：

a. 按照請求參數(shù)名稱將所有請求參數(shù)按照字母先后順序排序得到：keyvaluekeyvalue...keyvalue 字符串如：將arong=1,mrong=2,crong=3 排序為：arong=1, crong=3,mrong=2 然后將參數(shù)名和參數(shù)值進行拼接得到參數(shù)字符串：arong1crong3mrong2。

b. 將secret加在參數(shù)字符串的頭部后進行MD5加密 ,加密后的字符串需大寫。即得到簽名Sign

新api接口代碼:

app調(diào)用：http://api.test.com/getproducts?key=app_key&sign=BCC7C71CF93F9CDBDB88671B701D8A35&參數(shù)1=value1&參數(shù)2=value2.......

注：secret 僅作加密使用, 為了保證數(shù)據(jù)安全請不要在請求參數(shù)中使用。

如上，優(yōu)化后的請求多了key和sign參數(shù)，這樣請求的時候就需要合法的key和正確簽名sign才可以獲取產(chǎn)品數(shù)據(jù)。這樣就解決了身份驗證和防止參數(shù)篡改問題，如果請求參數(shù)被人拿走，沒事，他們永遠也拿不到secret,因為secret是不傳遞的。再也無法偽造合法的請求。

但是...這樣就夠了嗎？細心的同學(xué)可能會發(fā)現(xiàn)，如果我獲取了你完整的鏈接，一直使用你的key和sign和一樣的參數(shù)不就可以正常獲取數(shù)據(jù)了...-_-!是的，僅僅是如上的優(yōu)化是不夠的。。。。。。

請求的唯一性：

為了防止別人重復(fù)使用請求參數(shù)問題，我們需要保證請求的唯一性，就是對應(yīng)請求只能使用一次，這樣就算別人拿走了請求的完整鏈接也是無效的。

唯一性的實現(xiàn)：在如上的請求參數(shù)中，我們加入時間戳：timestamp（yyyyMMddHHmmss），同樣，時間戳作為請求參數(shù)之一，也加入sign算法中進行加密。

新的api接口：

app調(diào)用：

http://api.test.com/getproducts?key=app_key&sign=BCC7C71CF93F9CDBDB88671B701D8A35&timestamp=201603261407&參數(shù)1=value1&參數(shù)2=value2.......

如上，我們通過timestamp時間戳用來驗證請求是否過期。這樣就算被人拿走完整的請求鏈接也是無效的。

Sign簽名安全性分析：

通過上面的案例，我們可以看出，安全的關(guān)鍵在于參與簽名的secret，整個過程中secret是不參與通信的，所以只要保證secret不泄露，請求就不會被偽造。

總結(jié)

上述的Sign簽名的方式能夠在一定程度上防止信息被篡改和偽造，保障通信的安全，這里使用的是MD5進行加密，當(dāng)然實際使用中大家可以根據(jù)實際需求進行自定義簽名算法，比如：RSA，SHA等加密算法。希望能給大家一個參考，也希望大家多多支持好吧啦網(wǎng)。