在二家公司負責後臺開發與APP介面開發。

那我們要如何對介面請求進行一個安全校驗或者攔截非法請求吶？

1、選擇攔截過濾器。

在請求的時候對請求方法進行一次攔截處理。比如非正常訪問的方法已經注入插入可執行語句引數驗證等在攔截中進行一次安全校驗保證

請求不是非法請求。

2、資料加密。我們知道目前大部分APP介面都是通過Http協議進行呼叫的容易被抓包攔截。

我們可以對客戶端和服務端都對資料傳輸的時候進行一個加密處理。常用的MD5 AES等。

譬如：上一個專案做法比較簡單 對使用者與帳號密碼進行加密作為一個authcode。每次請求必須攜帶。這個方法與下邊說的方法3組合運用

客戶端：

    1、設定一個key（和伺服器端相同）

    2、根據上述key對請求進行某種加密（加密必須是可逆的，以便伺服器端解密）

    3、傳送請求給伺服器

伺服器端：

    1、設定一個key

    2、根據上述的key對請求進行解密（校驗成功就是「信任」的客戶端發來的資料，否則拒絕響應）

    3、處理業務邏輯併產生結果

    4、將結果反饋給客戶端

3、簽名

 根據使用者名稱或者使用者id，結合使用者的ip或者裝置號，生成一個token。在請求後臺，後臺獲取http的head中的token，校驗是否合法（和資料庫或者Redis中記錄的是否一致，在登入或者初始化的時候，存入資料庫/redis）

在使用Base64方式的編碼後，Token字串還是有20多位，有的時候還是嫌它長了。由於GUID本身就有128bit，在要求有良好的可讀性的前提下，很難進一步改進了。那我們如何產生更短的字串呢？還有一種方式就是較少Token的長度，不用GUID，而採用一定長度的隨機數，例如64bit，再用Base64編碼表示：

    var rnd = new Random();
    var tokenData = userIp+userId;
    rnd.NextBytes(tokenData);
    var token = Convert.ToBase64String(tokenData).TrimEnd('=');

由於這裡只用了64bit，此時得到的字串為Onh0h95n7nw的形式，長度要短一半。這樣就方便攜帶多了。但是這種方式是沒有唯一性保證的。不過用來作為身份認證的方式還是可以的（如網盤的提取碼）。

4、使用第三方框架與技術整合支援比如spring的框架中的oauth模組。