所謂介面，就是類似的請求，然後伺服器端直接根據user_id來做相應的會員操作，這是及其危險的介面處理，等於把當前的會員系統全暴露出來了,只要對方改一下user_id既可操作所有會員對應的介面。
首先,先說說在做該介面加密前，我一共經歷的四個方案：
方案一方案二
資料庫會員表的password是帶上了隨機密竄並經過雙重加密的md5值;在使用者登入的時候,我返回會員相應的uid和password,password雖然是明文的,別人知道也不能登入,畢竟是經過加密的,然後每次請求介面的時候user_id=333&token=aa37e10c7137ac849eab8a2d5020568f,通過主鍵uid可以很快的找到當前uid對應的token,然後再來比對;
但是這樣想法是too yang too ******的,抓包的人雖然不能通過密文密碼來登入該會員,然而一旦知道了這個token,除非使用者更改密碼,否則也可以一直通過這個token來操作該會員的相關介面;
方案三通過對稱加密演算法，該加密演算法對uid+**公鑰進行時效加密，在一定時效內可用。在會員登入成功時，伺服器端對該id加密後返回給客戶端，客戶端每次請求介面的時候帶上該引數，伺服器端通過解密認證；
但是這樣做，也是不安全的。因為，防外不防內，聽說這次的攜程宕機就是因為內部離職人員的惡意操作。內部不懷好意的人員如果知道相應的演算法規則後，就算沒有資料庫許可權，也可以通過介面來操作相關會員；
方案四會員登入的時候請求登入介面，然後伺服器端返回給客戶端乙個token，該token生成的規則是 **公鑰 + 當前uid + 當前時間戳 + 一段隨機數雙重加密，根據需求決定是把該token放進cache等一段時間自動失效，還是放進資料庫（如果要放進資料庫的話，單獨拎出一張表來，順便記錄使用者的登入，登出時間），在使用者登出登入的時候改變一下，確保該token只能在使用者人為登出登入之間有用。
為保安全，應保證讓使用者在一段時間內自動退出；此方案配合linux和資料庫的許可權管理可以防外又防內；
其他介面開發的注意事項
資料格式最好使用json格式資料，因為json有較好的跨平台性。在生成json的時候，要注意json的兩種格式：物件（字典） 與 陣列；mobile端開發語言中沒有類似php中的foreach不能遍歷物件，只能遍歷陣列，他們對物件的操作一般都是通過鍵名去取鍵值。
不管是成功，還是失敗。介面必須提供明確的資料狀態資訊，並且不能返回null，如果返回null的話，在ios端會崩掉。
介面api開發中安全性問題
內容 所謂介面，就是類似的請求，然後伺服器端直接根據user id來做相應的會員操作，這是及其危險的介面處理，等於把當前的會員系統全暴露出來了,只要對方改一下user id既可操作所有會員對應的介面。首先,先說說在做該介面加密前，我一共經歷的四個方案 方案一 方案二 資料庫會員表的password是...
安全性問題
更改預設密碼 大量關鍵資訊 金融的 市場的 私人的 難以置信地在 inter 上失竊，不僅因為不夠嚴密的安全體系結構，還因為不負責任地留下了資料庫和系統的預設安裝密碼。如果您不希望成為上述的一員，一定要更改 rdbms windows nt 計算機和其他資源中眾所周知的使用者預設登入密碼。檢查入口處...
api介面加密 API介面開發安全性想了解一下不
如今各種api介面層出不窮，乙個api的好與不好有很多方面可以考量，其中 安全性 是乙個api介面最基本也是最重要的乙個特點。尤其是對於充值繳費類的api介面來說，如話費充值api介面 流量充值api介面 遊戲q幣充值 水電煤繳費介面等，安全與否直接影響到個人或企業的財產，所以做好api介面的安全性...