django項目之api驗證部分
目的:
為了客戶端與服務器端之間的訪問安全,不被第三者攔截,所以需要api驗證。
客戶端部分:
首先需要寫一段復雜的key,用key來作為安全秘鑰,同樣在服務器端也會有一個相同的key。
然後我們還需要一個時間戳。#時間戳可以相當於動態加密
之後將key和時間戳拼接,再用Md5方法加密。 #更加安全
之後將加密後結果再與時間戳拼接寫到請求頭中發給服務端。 #為了讓服務端解密所以需要將時間戳直接發送給服務端
以上就是我們在客戶端要做的內容。
代碼如下:
服務端
首先我們需要寫一個和客戶端相同的Key
然後寫一個視圖函數,
首先我們需要將request中的請求頭取出來,通過split取出秘鑰(加密的Key和時間戳),以及時間戳;
然後我們將取出的時間戳轉為Float格式,並且服務端自己在取一個float格式的時間戳;
首先,第一關驗證判斷,如果客戶端時間戳+(規定時間秒數) < 服務器當前時間戳,那麽則認為該客戶端內容過時了,失去了時效性。
然後,如果加上規定描述符合要求,大於當前時間,那麽繼續下一條驗證
我們將服務端的key與剛才的時間戳拼接,放到與客戶端相同的md5方法中驗證匹配,查看結果是否相同,
如果不相同,這說明該客戶端的md5被更改過。
如果上一條匹配成功了,沒有問題,那麽我們進行最後一條驗證,判斷該請求是否為二次請求
如果這條請求,之前已經訪問過服務器,即便是在規定時間內我們也判斷為不合法,因為有可能有人會利用這段時間通過相同的md5來做非法請求。
所以我們建立一個空字典,如果為第一次請求,字典裏沒有該條秘鑰md5,我們認為是第一次請求,允許訪問,並將該md5存入字典當中,當規定秒數之內再來訪問,
判斷字典中已經存在該md5,我們判斷為非法請求,拒絕訪問。
具體代碼如下圖:
最後為了使用方便,我們將該段代碼寫成裝飾器,靈活使用。
如下圖:
將這個api驗證裝飾器寫到服務器管理系統的server函數上面即可。 api這三關驗證還是有缺點就是,如果黑客比你網速快,從半路攔截了,客戶端就是第二次訪問了。 所以,為了保險起見,需要客戶端在發送之前將數據加密,即便黑客攔截,也無法使用數據。
django項目之api驗證部分