資訊專欄INFORMATION COLUMN
摘要：總結一下數據保護的技術點參數傳輸使用密文，可以使用對稱加密非對稱加密或者兩者的結合，比如請求就是屬于兩者結合的方式。安全性一些常用的安全問題都要考慮到，并且在項目框架底層進行防范，例如攻擊注入問題單用戶或者單的訪問頻率控制來進行防攻擊。
App所有數據都來源于服務器，App和服務器交互普遍是采用http請求接口的方式，那么在搭建和維護一個后端Api項目時候需要注意哪些問題呢？
1. 數據保護數據保護做的好不好，有兩個原則來驗證：
第一，可以控制讓誰來讀取數據，
對于任何一個Api項目其實就是只允許產品App本身訪問，這就需要用密文傳輸請求數據，做到即使被人用抓包工具抓到請求數據也沒有辦法解析出參數的意義。
把安全做到更近一步，可以在加密之前引入timestamp參數，在服務端通過比較timestamp和當前時間戳可以做到對于抓取到的鏈接也不能重復調用。
密文的安全性取決于參數的加密方式，使用對稱加密、非對稱加密或者兩者結合取決于團隊自己的選擇，當然如果接口域名已經配了證書支持https，就不用自己寫代碼來做這些事情了。
如果密文傳輸已經做到絕對安全不可破解，那就安全了嗎？當然不是，你要相信安全永遠是相對的。試想一下如果App源碼被反編譯成功，那他就可以按照代碼邏輯去拼出正常的請求？另外一般業務除了有app之外也會有使用相同接口的h5版，任意一個開發者通過瀏覽器的調試模式很容易能分析出請求的Url以及相關參數。對于這兩種情況怎么辦呢？
第二，對于可以獲取數據的端，也可以控制其可以獲取哪些數據
既然客戶端不能做到完全可靠，那就讓服務端多承擔一些任務，在app啟動時或者用戶登錄時服務端先向每個客戶端分發一個有固定有效期的secret，并且在服務端數據庫庫中存儲客戶端唯一標示或者uid和secret的對應關系，之后每次客戶端調用都要用secret對于參數組合進行一次簽名，并且確保參數包含uid，服務端接收到請求后根據uid找出對應的secret，然后按照和客戶端相同的簽名方式得出簽名，進而和客戶端傳過來的簽名進行比較。
因為secret是服務端分發的，即使破解了源碼，再即使從本地解析出了保存的secret，那也只能獲取這個secret對應的數據，再加上secret本身會有更新機制，這就使得通過破解接口來抓取大量數據變得大大的困難。
但是對于向第三方開放的api接口情況就不太一樣，它不存在密文傳輸的問題，大體思路也是使用secret進行簽名認證，只是分發secret的方式不一樣，它是通過合作的方式，api提供商會給使用方分發一個key和一個secret，兩者可以當成一個鍵值對。調用方每次調用時用secret進行參數的簽名，參數包含key，服務端接收到請求，根據key參數取出secret，然后進行相同方式的簽名，并且和客戶端傳入的簽名進行對比來完成驗證。
總結一下數據保護的技術點：
參數傳輸使用密文，可以使用對稱加密、非對稱加密、或者兩者的結合，比如https請求就是屬于兩者結合的方式。
app端要盡量加大反編譯的難度，盡量保護源碼安全。
通過參數id=>secret的方式進行簽名來進行用戶身份認證，調用方保存自己的secret，服務端保存id和secret的對應關系，secret用于簽名，后續的每次請求都要帶著id參數。
在第三步的基礎上，加上timestamp參數來防止連接重復調用。
2. 安全性一些常用的安全問題都要考慮到，并且在api項目框架底層進行防范，例如xss攻擊、sql注入問題、單用戶或者單ip的訪問頻率控制來進行防cc攻擊。
3. 舊版本兼容互聯網產品版本迭代很快，對于同一個功能新舊版本在參數或者返回值上會有差別。對于這種問題會有不同觀點的解決方案，一種方案是在url中加入版本信息，比如http://api.demo.com/v1/test ， 每個版本對應一個Action，具體的業務邏輯不要寫在Action層，要封裝到下面的邏輯層，這樣Action只需要在主業務的基礎上根據需求進行擴展。另外一種觀點是，這樣代碼重復度太高，會有大量的action文件，一個功能只提供一個唯一的url，但是要帶上一個表示版本的參數，在代碼框架中只有一個action，對于新舊版本的細小差別可以使用參數默認值等兼容方式進行處理，對于比較大的改動就通過邏輯判斷語句進行不同處理即可。
另外比較重要的一點是，在設計之初要對業務進行足夠的抽象化，讓設計本身能盡量支持變化，比如以后此接口是否會增加某個分類屬性，返回結果的格式是否再多包裝一層就可以應對萬一后面版本要增加另一塊數據。
當然不可能同時維護所有舊的版本，要做到可以檢測每個版本的使用情況，而且可以根據版本使客戶端強制升級。對于功能的修改，同時維護舊版本是一件特別麻煩的事情，甚至有些情況不得不強制升級所有版本。
總結一下就是：
要能區分不同版本，通過url或者參數
設計時候盡量考慮之后擴展，足夠抽象化
支持根據版本進行強制升級
4. 盡可能把所有業務邏輯都放到服務端很容易理解，服務端不用發版，服務端沒有處理不了的問題，很簡單一個例子：用戶登錄功能，會有"密碼錯誤","還沒有注冊"等各種異常情況的提示。那具體的文案是在客戶端定義，還是從服務端直接返回給客戶端比較好呢，顯然是后者。因為以后提示語內容要做修改的話，放在服務端就可以很簡單進行處理，放在客戶端只能重新發版。
5. 返回字段可定制，可幫用戶節省流量A、B兩個功能都需要獲取用戶信息，兩者調用同一個接口，但是A只需要獲取用戶名和電話，就沒有必要把其它信息返回給A。
6. 格式統一，易讀uri統一化，不一定說非要用restful格式，但一定要有統一的規范。
響應結果格式也統一，建議在最外層節點至少包含：code，msg，result，response_time等字段，具體的業務功能數據封裝在result中。
nginx公眾號也會推送好文，主要聊聊后端技術，掃描或者搜索nginx即可添加。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/11355.html
摘要：是文檔的一種表示結構。這些任務大部分都是基于它。這個實踐的重點是把你在前端練級攻略第部分中學到的一些東西和結合起來。一旦你進入框架部分，你將更好地理解并使用它們。到目前為止，你一直在使用進行操作。它是在前端系統像今天這樣復雜之前編寫的。 本文是 前端練級攻略 第二部分，第一部分請看下面： 前端練級攻略(第一部分) 在第二部分，我們將重點學習 JavaScript 作為一種獨立的語言，如...
摘要：組件監聽自定義事件。組件觸發自定義事件。生命周期鉤子函數，后組件的所有的事件監聽器會被移除。技術點總結組件設計的思想包括單數據流事件中心，核心是組件通信。完善給彈出日期面板和關閉日期面板增加組件自定義事件即調用觸發和事件。預覽 組件庫官網 github地址 如果喜歡各位小哥哥小姐姐給個小星星鼓勵一下哈， 請勿在生產環境中使用，供學習&交流~~ showImg(https://user...
摘要：導語本期采訪對象黃允松，青云創始人及。作為一個純粹的工具理性主義者，黃允松致力于打造優良的工具，大幅降低的復雜性，讓一切變得更加平滑和簡單，這是他讓世界變得美好起來的方式。 showImg(http://segmentfault.com/img/bVbYfe);文：Gracia 攝影：周振邦(本文為原創內容，部分或全文轉載均需經過作者授權，并保留完整的作者信息和技術人攻略介紹。) ...
摘要：第一部分介紹了如何使用和開發接口。由于系統變得越來越復雜，人們提出了稱為預處理器和后處理器的工具來管理復雜性。當您第一次得知有預處理器和后處理器時，你很有可能在任何地方已經使用它們。我之前建議的文章，，也涵蓋了預處理器相關的知識。 我記得我剛開始學習前端開發的時候。我看到了很多文章及資料，被學習的資料壓得喘不過氣來，甚至不知道從哪里開始。 本指南列出前端學習路線，并提供了平時收藏的一些...
閱讀 2345·2021-11-11 16:54
閱讀 2596·2021-09-26 09:47
閱讀 3978·2021-09-08 09:36
閱讀 2727·2021-07-25 21:37
閱讀 927·2019-08-30 15:54
閱讀 2540·2019-08-30 14:22
閱讀 3245·2019-08-30 13:57
閱讀 2558·2019-08-29 17:17
