在為第三方系統提供接口的時候，肯定要考慮接口數據的安全問題，比如數據是否被篡改，數據是否已經過時，請求是否唯壹，數據是否可以重復提交等問題。其中數據是否被篡改相對重要。
請求攜帶參數 appid 和 sign ，只有擁有合法的身份appid和正確的簽名sign才能放行。這樣就解決了身份驗證和參數篡改問題，即使請求參數被劫持，由於獲取不到secret（ 僅作本地加密使用，不參與網絡傳輸 ），無法偽造合法的請求。
只使用appid和sign，雖然解決了請求參數被篡改的隱患，但是還存在著重復使用請求參數偽造二次請求的隱患。
nonce指 唯壹的隨機字符串 ，用來標識每個被簽名的請求。通過為每個請求提供壹個唯壹的標識符，服務器能夠防止請求被多次使用（記錄所有用過的nonce以阻止它們被二次使用）。
然而，對服務器來說永久存儲所有接收到的nonce的代價是非常大的。可以使用 timestamp來優化nonce的存儲 。
假設允許客戶端和服務端最多能存在10分鐘的時間差，同時追蹤記錄在服務端的nonce集合。當有新的請求進入時，首先檢查攜帶的timestamp是否在10分鐘內，如超出時間範圍，則拒絕，然後查詢攜帶的nonce，如存在（說明該請求是第二次請求），則拒絕。否則，記錄該nonce，並刪除nonce集合內時間戳大於10分鐘的nonce（可以使用redis的expire，新增nonce的同時設置它的超時失效時間為10分鐘）。
對服務端而言，攔截請求用AOP切面或者用攔截器都行，如果要對所有請求進行攔截，可以直接攔截器處理（攔截器在切面之前，過濾器之後，具體在springmvc的dispather分發之後）。
過濾器→攔截器→切面的順序：
其中，需要放在請求頭的字段： appid 、 timestamp 、 nonce 、 signature 。
對各種類型的請求參數，先做如下拼接處理：
如果存在多種數據形式，則按照path、query、form、body的順序進行再拼接，得到所有數據的拼接值。
上述拼接的值記作 Y。
X=”appid=xxxnonce=xxxtimestamp=xxx”
最終拼接值=XY。最後將最終拼接值按照壹個加密算法得到簽名。
雖然散列算法會有推薦使用 SHA-256、SHA-384、SHA-512，禁止使用 MD5。但其實簽名這裏用MD5加密沒多大問題，不推薦MD5主要是因為，網絡有大量的MD5解密庫。
實現可以分以下幾步：
自定義的緩存有body參數的HttpServletRequest：
過濾器中替換自定義的RequestServlet:
添加過濾器的配置以及註意順序：
由於Zuul自帶默認的過濾中，有已經對body處理過的（FormBodyWrapperFilter），所以在Zuul中處理簽名，只需添加壹個過濾器即可如下。
java接口簽名(Signature)實現方案
開放API接口簽名驗證，讓妳的接口從此不再裸奔