商業App，在客戶端與服務端做通訊時，通訊內容都要進行嚴格加密，以防止第三方的一些攻擊與請求偽造。尤其涉及支付等需要安全性比較高的業務的時候。

下面是記錄我參與的app，XX音樂的加密方式。以防細節遺忘。

先說一下大背景：

工程用的請求類是ASIHttpRequest，為了做加密層，我把ASI又封裝了一層，繼承于ASI,以供加密技術的實現。數據加密整體是在request ?init的時候做的，加密完，再調super 的 init。

調完super 的 init 構造好request后，要在request得請求頭里打入一些標簽，以供客戶端和服務端交互使用。具體下面說。

加密方式為RC4，為了防止反編譯（有安卓版本，安卓端反編譯比較嚴重），直接用c實現的，然后打包.a庫文件放在工程里。

1.加密方式

以一條標準請求url為例：

http://m.zhangsan.cn/sod?action=6&parameter={userID=400802759}

1>get請求

其中，前半部分不做加密，為訪問服務器的基本地址，后半部分用于數據傳遞的部分，要做加密，我們用的為RC4.

2>post請求

post請求，后面的數據部分，會放在post請求體里。

其實這里要加密的數據在請求init的時候就會開始做加密處理，加密好之后，調[superinitWithURL:newURL] ，這里的super，其實就是ASIHttpRequest，至于是拼到基本地址后面，還是放到post里，要看當前客戶端和服務端的交互方式來決定。

2.請求頭里的標簽

加密后的數據，要往請求頭里打入一些標簽，以供服務端識別。我們有的標簽包括：

X-AC:用戶authcode，登陸用戶會分配一個acthcode，這個其實是用于區分當前請求發送的客戶端是否是登陸用戶。如果是游客訪問，頭里不會有這個字段。

X-CID:是當前設備的唯一標示符，生成方式為openUDID

X-PRODUCT:ios/Android以及版本號

X-SEC:加密方式，我們的分為P,C 和 P，P,C代表為私鑰加密，P代表為公鑰加密，需要服務器對應的解密方式來解密。

3.錯誤處理機制

這里的錯誤有幾個場景。

解密失敗、XCID對應的解密key不存在或者無效、不支持的加密算法、數據錯誤。大概就這些，分別對應不同的處理方式。但我們的處理方式都很通用，就是如果遇到錯誤，先用公鑰進行加密完成請求，然后重新請求私鑰，并保存，之后的請求用新的私鑰進行加密。

這里還有一個錯誤上限機制，同一個請求最多允許被連發三次，如果一個請求連續三次被解密失敗，則會認為請求失敗，并給出相應的提示給用戶。

譬如請求用私鑰第一次失敗了，然后用公鑰加密繼續發又失敗了，下一次的時候用新請求回來得私鑰發，還是失敗，然后又用公鑰繼續發，如果還失敗，那么這個請求就不發了，直接認為請求失敗，并提示相關提示給用戶。

4.流程

進入app-》記錄存放秘鑰的目錄-》記錄版本號，x-ac，x-cid以供請求頭用-》發請求獲取私鑰并保存（加密方式用公鑰）

之后就進入正常的加密請求。

5.解密

解密相對簡單，請求返回的json串是整體加了密的，只要用正確的解鑰去解密，然后獲得明文，解析就ok了。

總結

以上是生活随笔為你收集整理的ios客户端请求数据加密方式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。