**：
api介面由於需要供第三方服務呼叫，所以必須暴露到外網，並提供了具體請求位址和請求引數
為了防止被第別有用心之人獲取到真實請求引數後再次發起請求獲取資訊，需要採取很多安全機制
主要防禦措施可以歸納為兩點：
防止重放攻擊必須要保證請求僅一次有效
需要通過在請求體中攜帶當前請求的唯一標識，並且進行簽名防止被篡改。
所以防止重放攻擊需要建立在防止簽名被串改的基礎之上。
採用https協議可以將傳輸的明文進行加密，但是黑客仍然可以截獲傳輸的資料報，進一步偽造請求進行重放攻擊。如果黑客使用特殊手段讓請求方裝置使用了偽造的證書進行通訊，那麼https加密的內容也將會被解密。
在api介面中我們除了使用https協議進行通訊外，還需要有自己的一套加解密機制，對請求引數進行保護，防止被篡改。
過程如下：
客戶端使用約定好的秘鑰對傳輸引數進行加密，得到簽名值signature，並且將簽名值也放入請求引數中，傳送請求給服務端
服務端接收客戶端的請求，然後使用約定好的秘鑰對請求的引數（除了signature以外）再次進行簽名，得到簽名值autograph。
服務端對比signature和autograph的值，如果對比一致，認定為合法請求。如果對比不一致，說明引數被篡改，認定為非法請求。
因為黑客不知道簽名的秘鑰，所以即使擷取到請求資料，對請求引數進行篡改，但是卻無法對引數進行簽名，無法得到修改後引數的簽名值signature。
簽名的秘鑰我們可以使用很多方案，可以採用對稱加密或者非對稱加密。
每次http請求，都需要加上timestamp引數，然後把timestamp和其他引數一起進行數字簽名。因為一次正常的http請求，從發出到達伺服器一般都不會超過60s，所以伺服器收到http請求之後，首先判斷時間戳引數與當前時間相比較，是否超過了60s，如果超過了則認為是非法的請求。
一般情況下，黑客從抓包重放請求耗時遠遠超過了60s，所以此時請求中的timestamp引數已經失效了。
如果黑客修改timestamp引數為當前的時間戳，則signature引數對應的數字簽名就會失效，因為黑客不知道簽名秘鑰，沒有辦法生成新的數字簽名。
但這種方式的漏洞也是顯而易見的，如果在60s之後進行重放攻擊，那就沒辦法了，所以這種方式不能保證請求僅一次有效。
nonce的意思是僅一次有效的隨機字串，要求每次請求時，該引數要保證不同，所以該引數一般與時間戳有關，我們這裡為了方便起見，直接使用時間戳的16進製制，實際使用時可以加上客戶端的ip位址，mac位址等資訊做個雜湊之後，作為nonce引數。
我們將每次請求的nonce引數儲存到乙個「集合」中，可以json格式儲存到資料庫或快取中。
每次處理http請求時，首先判斷該請求的nonce引數是否在該「集合」中，如果存在則認為是非法請求。
nonce引數在首次請求時，已經被儲存到了伺服器上的「集合」中，再次傳送請求會被識別並拒絕。
nonce引數作為數字簽名的一部分，是無法篡改的，因為黑客不清楚token，所以不能生成新的sign。
這種方式也有很大的問題，那就是儲存nonce引數的「集合」會越來越大，驗證nonce是否存在「集合」中的耗時會越來越長。我們不能讓nonce「集合」無限大，所以需要定期清理該「集合」，但是一旦該「集合」被清理，我們就無法驗證被清理了的nonce引數了。也就是說，假設該「集合」平均1天清理一次的話，我們抓取到的該url，雖然當時無法進行重放攻擊，但是我們還是可以每隔一天進行一次重放攻擊的。而且儲存24小時內，所有請求的「nonce」引數，也是一筆不小的開銷。
nonce的一次性可以解決timestamp引數60s的問題，timestamp可以解決nonce引數「集合」越來越大的問題。
防止重放攻擊一般和防止請求引數被串改一起做，請求的headers資料如下圖所示。
我們在timestamp方案的基礎上，加上nonce引數，因為timstamp引數對於超過60s的請求，都認為非法請求，所以我們只需要儲存60s的nonce引數的「集合」即可。
最終實現**（閘道器層驗證）：
public class apiauth extends zuulfilter
@override
public int filterorder()
@override
public boolean shouldfilter()
@override
public object run()
//請求時間和現在時間對比驗證，發起請求時間和伺服器時間不能超過timelimit秒
if (stringutils.timediffseconds(new date(), timestamp) > timelimit)
//驗證使用者資訊
userinfo userinfo = userinfoutil.getinfobytoken(token);
if (userinfo == null)
//驗證相同noce的請求是否已經存在，存在表示為重複請求
if (noceutil.exsit(userinfo, nonce)) else
//伺服器生成簽名與header中簽名對比
string serversign = signutil.getsign(userinfo, token, timestamp, nonce, request);
if (!serversign.equals(sign))
ctx.setsendzuulresponse(true);
return null;
}}
API介面設計 防引數篡改 防二次請求
api介面由於需要供第三方服務呼叫，所以必須暴露到外網，並提供了具體請求位址和請求引數 為了防止被第別有用心之人獲取到真實請求引數後再次發起請求獲取資訊，需要採取很多安全機制 主要防禦措施可以歸納為兩點 防止重放攻擊必須要保證請求僅一次有效 需要通過在請求體中攜帶當前請求的唯一標識，並且進行簽名防止...
介面引數防篡改處理
向外網開發的介面，由於外網環境的複雜，容易被人獲取到請求位址，以及真是的請求引數，就能夠使用該引數再次請求，造成重放攻擊 或者黑客直接篡改請求引數。為了防止請求引數被篡改，需要對引數進行加密。這裡採用的是每次請求根據月的的金鑰生成簽名sign，在請求到達後台伺服器時對請求引數再次進行校驗生成簽名，比...
angular4 防二次重複點選
監聽click事件,預設三秒鐘內的點選事件觸發第一次的點選事件,也可以通過throttletime自定義時間 只觸發第一次 throttleclick 5 s throttleclick default import from angular core import from rxjs subjec...