1.1、你的登錄模塊完善嗎
用戶登錄這個功能想必大家都不陌生甚至于說是輕車熟路了，但是你的登錄模塊真的很完善嗎？會不會依然潛藏著一些問題呢？
最近在做項目優化時不可避免的頻繁接觸登錄模塊(因為登錄時前提嘛)，但是仔細觀察之下就發現存在這樣或那樣的問題。于是乎得出一個結論：之前的登錄模塊是不完善的，考慮的因素和場景不夠細化。同時有了下面的一些思考。
二、用戶登錄背后的邏輯
2.1、傳統實現
前端放置一個用戶名和密碼的表單，用戶提交時后臺在數據庫中查詢匹配的用戶名及密碼信息，如果匹配就登錄成功，否則就登錄失敗！
2.2、潛在問題
這么簡單的登錄實現肯定是會潛在一系列問題的，比如：
① 缺失前端的判空處理
② 明文密碼，不安全
③ 重復提交
④ 惡意訪問
三、登錄實現的自我規范
項目開發中，登錄模塊的前后端需要著重注意一下幾點：
3.1、密碼安全
① 禁止請求中的明文密碼，需加密后進行請求
② 網站啟用https
3.2、數據規范
① 表單文本框、密碼框的最大最小長度
② 規范性檢測，比如：手機號，郵箱等的有效性檢測
③ 表單必填項為空時不允許進行提交，并給出提示
3.3、邏輯處理和準確響應
① 后端建議按照：參數校驗 -> 數據檢查 -> 屬性判斷 -> 場景處理 -> 準確返回?的流程進行
② 先進行參數的合法性驗證，不合法數據在開始就扼殺在萌芽之中，因為你的接口并不只有前端能調用的到，隨便一個調試工具都可以模擬請求
③ 在做數據檢查時要邏輯層次清晰，比如先檢查用戶是否存在，再檢測用戶的合法性和權限，最后準確返回信息（DTO）
④ 如果遇到異常，按照邏輯層次劃分準確響應信息回執，不能一股腦的返回一個類似：請求異常之類的
四、程序的安全性保證
這部分更多的是在后端的一些處理，正如上面所說的：你的接口不僅僅是自己在用！
4.1、重復登錄
不管是使用者網絡卡住了，還是有人惡意發送登錄請求，這些都可以作為重復登錄來進行處理。這部分涉及到前端和后端，都需要做這部分的攔截。詳情可看我之前的一篇文章：
自定義注解實現重復性提交攔截
4.2、強刷接口
如果考慮到不排除有人會強刷接口，及時你的服務器抗住了也是一個不小的負擔！所以我們上面的重復登錄驗證還要更細化一些。比如：
① 10分鐘內超過三次的重復（記錄在redis中超時10分鐘），則提示需要等一等
② 前端加入驗證，比如：滑塊驗證、12306的登錄點擊驗證等（圖片碼已經被玩爛了）
PS：后面我也會出一個Nuxt整合圖片滑塊驗證的文章（已經實現了，還沒輸出文章…）
③ IP檢測，能排除一部分的惡意刷接口，但是無法應對那些使用代理換著刷的！而且一個公司或組織的根IP是一樣的很容易導致誤封
4.3、暴力破解
在惡意請求的基礎上，不斷嘗試匹配用戶名、密碼、單號這些數據以期能做數據的暴力破解。所以在防止盜刷，重復提交的同時應該規范數據安全，比如：密碼必須英文大小寫和數據全部存在…
4.4、登錄驗證
我們上面說到超出3次就提示用戶等一下、前端滑塊驗證等措施。那除了這些還有更簡單有效的手段：手機短信或郵箱驗證在請求次數超出限制后生成一個驗證碼發送到手機短信或者郵箱，用戶必須匹配了code后才能正常請求。
聲明：本文由網站用戶竹子發表，超夢電商平臺僅提供信息存儲服務，版權歸原作者所有。若發現本站文章存在版權問題，如發現文章、圖片等侵權行為，請聯系我們刪除。
