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