應用場景
以 OSChina 賬號注冊 為例...講錯了請留言批評指正...
邏輯場景
- 用戶操作: 用戶輸入手機號, 然后點擊獲取驗證碼.
- 前端邏輯: ajax 發起請求, 參數帶上手機號.
- 后端邏輯: 獲取請求參數, 生成6位數驗證碼, 給指定手機號發送短信, 並緩存一個30秒過期的鍵值, mobilephone=checkcode, 比如 135xxx=123456
用 redis-cli 操作的話命令如下:
// 設置一個緩存 key=手機號 value=驗證碼, 30秒后過期自動刪除
127.0.0.1:6379> set 135xxx 123456
OK
127.0.0.1:6379> expire 135xxx 30
(interger) 1
- 用戶操作: 用戶收到短信驗證碼后，輸入驗證碼，點擊注冊.
- 前端邏輯: ajax 請求接口, 參數帶上發送手機號 & 短信驗證碼.
- 后端邏輯: 拿着請求參數中的手機號做為 redis key 去找值
用 redis-cli 操作的話命令如下:
127.0.0.1:6379> get 135xxx
"123456"
如果沒過期的話會輸出對應的驗證碼 "123456", 程序里做判斷比對.
如果等待30s過期的話, redis-cli 操作輸出如下:
127.0.0.1:6379> get 135xxx
(nil)
會輸出(nil), 代表無, 這個緩存鍵及值直接被 redis 自動刪除了. 這個時候頁面可以提示用戶 "驗證碼過期請重新獲取驗證碼" 之類的.
注意事項
- key 要唯一, value 允許重復, 這里充分運用了 redis set 自帶去重屬性, mobilephone:=checkcode(最新的驗證碼)
- 你一不小心輸錯成了別人手機號, 那個人也賬號在注冊，並且你們2的驗證碼一不小心是一樣的 - 所以為了安全考慮不要單純只拿手機號和驗證碼作為注冊和登錄的依據，非常不安全，現在很多app就是這樣干的，為了讓你盡快注冊放棄了很大安全性。想想上面的注冊登錄換成支付場景, 所以驗證碼通常是30-60秒的有效期, 如果惡意去嘗試的會直接過期了. 如果查手機號的話, 這么短的時間內也試不了幾個手機號. 通過時效性來保障相對的安全性.
- ...