api 开发模式下验证码的问题反馈【个人觉得比较严重】
chenbidepro opened this issue · 3 comments
chenbidepro commented
目前我们移动端是完全采用前后端分离,后端提供API的方式来开发。
在使用短信时遇到以下问题,我们觉得是不合理的。
- 同一个手机号码和同一个token,在有效时间内获得的验证码是 一样的,就算故意输入错误验证失败后,再次获取验证码一样。再次验证也能正确返回。验证正确后也没有失效,再去获取仍然是一样的验证码。
还没有去研究源码,但是感觉这里应该是通过access_token作为key去保存在cache中的。
- 同一个手机号码不同的token,在60秒内可以获得两个验证码。原因同第一点,也是access_token作为key 去保存的。
toplan commented
你好,感谢你的反馈 😄
我有以下几点想同你交流:
同一个手机号码和同一个token,在有效时间内获得的验证码是 一样的
,关于这一点你是否是在config/laravel-sms.php
中配置了repeatIfValid
为true
呢?如果是的话,那确实是进入了重复使用有效验证码的逻辑,目前版本是有这个逻辑的。- 还是基于上面的条件,后面你说的验证正确/失败后验证码也没有失效,还是会获得相同的验证码,对吧?确实我也觉得存在逻辑上的不合理,目前来说在你的控制器中验证后,是可以通过
SmsManger::forgetState()
方法手动删除状态,我想是可以避免你说的问题的。 同一个手机号码不同的token,在60秒内可以获得两个验证码
,我没是很理解你的意思,我认为既然是不同的token了,那就可以暂时认定为不是同一个用户了对吧?那既然不是同一个用户,获得两个不同的验证码,这很正常吧?- 确实是access_token作为key去保存在cache中的。
基于上面,是我目前对你的问题的认识,如果有偏差,请指出哦,谢谢。
chenbidepro commented
几天忙着赶项目,忘记看消息了 : )
- 在API下 repeatIfValid 这个字段是无效的,同事演示给我确认过。
- 如果这样做,repeatIfValid 就失去意义了。
- 如果让有心人发现,很容易通过API接口,把短信给用掉了。个人觉得判断是不是同一个用户,应该根据手机号来确定。
toplan commented
嗯,你说得有道理,我认为可以根据场景来区分,自由选择使用什么来确定用户,比如在你们的场景里,完全可以用手机号作为access token (access token值的选择完全是自由的)