应用场景
以 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秒的有效期, 如果恶意去尝试的会直接过期了. 如果查手机号的话, 这么短的时间内也试不了几个手机号. 通过时效性来保障相对的安全性.
- ...