幾個月前，我們前端被通知要在請求頭上加幾個請求頭，都是加密的內容，目的是解決前後資料的安全性。之前一點不理解，一直覺得前端沒有祕密可言，安全的事情交給後臺就完事了。。。

然後最近看了一些書，發現自己有點年輕，傳輸的資料沒有加密就傳送給後臺，只要中間人拿到請求的引數token後，就可以為所欲為了。

故事背景：

事情是這樣的，鄙司是前後分離的，所以資料都是走的介面，就拿登入來說吧（其實我個人覺得登入時最難），通常前端傳入後臺兩個欄位 `user`和`password`當然都是明文的。

user:'admin',
passWord:'123456'

然後後臺會返回前端一個`token`，然後以後的每次請求我們都會在介面的head上面多加一個欄位`token`用來驗證使用者是否正在登陸，當然`token`也是有實效的，固定時間內檢測是否過期。

這裡面就會存在一個問題，中間人拿到其他人的tonke來偽造的話就會造成很大的問題，當時也沒有做其他的驗證方式。比如某某發表一篇言論'*****'又或者提現等等。。。問題特別嚴重。

那麼這種問題該如何解決呢？

首先想到的是https，用他來傳輸應該沒問題吧，大公司出品，必出精品！

1. 瀏覽器傳送請求(https://xxx.com)   到伺服器
2. 伺服器傳送數字證書(包含伺服器的公鑰)
3. 瀏覽器用預置的CA列表驗證證書，如果有問題就提示有風險，你別登陸了！！
4. 瀏覽器生成隨機的對稱祕鑰，用伺服器的公鑰加密
5. 伺服器用自己的祕鑰進行解密，等到對稱的祕鑰
6. 前後端都知道了祕鑰，用他來加密通訊

好像問題解決了，但是尷尬的問題還是出現了，之前寫的那麼多介面咋辦，而且我們當時也沒有寫介面文件的習慣，都是口口相傳（其實就是有一些臨時的bug修改增刪改介面引數），但是極少成多，這個問題就變得十分嚴重！！！

我們又想到一個辦法，既然知道https是怎麼處理的，那我們自己寫一套自己的規則不就行了。

介面還是原來的介面，前後端在處理登入介面的時候需要加密一下請求的引數，登入的時候必須保障安全。其次每個請求頭加一個前後公用的加密解密規則，（如：xx + 當前的時間戳 + 6位隨機位），還有當前的域名 ，時間 + 6位隨機數 加密。在加上當前的版本號。

1. 登入必須用加密的引數的請求
2. 前後端的通訊方式用加密方式，後臺只要儲存加密的結果就行了，然後返回tonken(使用者的密碼是加密不可逆的)
3. 驗證前端的請求頭，時間，6位隨機數，當前的域名，版本號，這些是必填的，後臺也是必須驗證的，如果出現時間+隨機數相同那麼斷開請求，重新登入
4. 後臺拿著前端給的加密結果返回tonken，後面的所以介面的請求頭必須要有上面的引數做驗證

後臺解密需要知道加密演算法，這樣拿到解密之後的請求引數在去返回資料，這樣最大限度的方式解決被盜用的風險。

舉個例子：後臺想要解密 一段加密的請求引數，需要獲取 時間戳+6隨機數 

 這樣登入的安全問題似乎是解決了，最起碼中間人不知道演算法的情況下是無法解析請求的引數的，即使拿到tonken也不行！

我嘗試逆向的解發現在不知道密碼的情況下，我個人的水平無法解開。

這樣問題就解決了，也不會對程式碼產生多大的影響，可以說是當下最好的解決方案了。