扫一扫添加我为好友
扫一扫添加我为好友
扫一扫添加我为好友
扫一扫添加我为好友
发布时间:2021-07-15来源:九天企信王作者:过竹雨
昨天看到一个地址,新用户免费收到阿里阅读的30天阅读APP会员。2021年了,该开始读书了。看到这个活动在笔记本里,我用笔记本浏览器进入活动页面,输入手机号,收到验证码,填写验证码,收这个会员。原本以为一切就这样顺利结束了,然而并不是填写验证就会提示“网络错误”。这不科学。作为一个程序员,我下意识的按了F12,打开了开发者工具,于是看到了下面这个错误。简单来说,就是跨域的问题。我想了一下,估计这个活动是针对移动终端的。我用PC终端访问,导致跨域。这个地方设计的不好。
然后用手机访问活动页面地址,正常打开,然后填写手机号码,然后提示获取过于频繁
刚从PC发了几次验证码。这个地方设计的时候考虑到了安全,这很好。
我只能等。从发展来看,我的手机号在固定时间段内只能发送固定次数的验证码。如果数量超过这个数量,就不会再发给我了。一个是安全考虑(频繁的接口调用),另一个可能是成本考虑(防止短信验证码被刷)。
过了一段时间,我去手机那里试着收藏,发现一切顺利,收藏成功。
如果你看到你这里的合作伙伴是新用户,有兴趣阅读,可以让这个会员体验一下(不是广告)。地址:www.sms9.net
这里应该就到此为止了,但是作为开发者,我觉得还是简单的梳理一下这个发短信的功能吧,因为这个功能虽然看起来简单,但是深入调查之后有很多地方需要注意和考虑。
在互联网时代,发送短信验证码已经成为很多产品必不可少的功能。还有很多场景,注册登录、银行转账、营销活动等。(场景真的很多,我就不多举了)。
发验证的时候,其实很多公司用的是第三方短信服务,需要收费,天下没有免费的午餐。然后出现黑色工具——短信轰炸机。
短信轰炸机是一款用写好的程序批量刷短信的软件。可以批量自动提交手机号,模拟IP来刷短信。
如果需要使用短信验证码产品,一定要制定限制规则,设计好。
主要原则:发送验证码需要由前端和后端共同设计,这样可以更完善,也可以更完善。
xx秒后再次发送,正常运行
一般点击验证后会在前端(客户端)进行xx秒的倒计时(这个倒计时可以根据具体产品的具体业务来确定,大部分是60秒)。在这个固定时间内,用户不能提交多个发送信息的请求。具体时限要考虑产品自身属性、运营难度、网络延迟、短信资费成本等。
(1)需要发送认证码时,让用户先输入认证码,输入的认证码通过后再请求获取短信认证码;否则,“获取身份验证”按钮不会被激活。
(2)请求验证后,前端(客户端)通常倒计时xx秒(这个倒计时可以根据具体产品的具体业务来确定)。在这个固定时间内,用户不能提交多个发送信息的请求。
在这一点上,图形验证码是不必要的。可能为了有更好的用户体验,一开始不需要输入图形验证码,需要经过一定的操作才需要输入图形验证码。请根据具体情况设计。
虽然这种方法被广泛使用,但不是很有用。技术稍微好一点的人可以绕过这个限制,直接发短信验证码。
如果前台倒计时60s,后台验证码的到期时间一定不是60,但通常会是5~10分钟。
同一手机号码在规定时间内不能超过x。
当注册或发送手机号码相同的短信验证码时,系统可以限制该手机号码。比如一个小时只能发送三个短信验证码,超过限制就会报错(比如系统忙,请稍后再试)。但是这种方法只能避免手动刷短信。对于用不同手机号批量刷短信的机器来说,这种方法很无奈。
限制相同的IP/Cookie信息的最大数量
使用Cookie或者IP,可以简单的识别同一个用户,然后限制同一个用户(比如最多只能在xx时间内发送xx条短信)。但是Cookie是可以清理的,IP是可以模拟的,IP在局域网中也会有相同的IP。所以在使用这种方法的时候,要根据具体情况来考虑。
这样在第三点的基础上,防止了恶意刷手机验证码短信。如果同一个ip多次请求手机验证码短信,因为短信需要钱,竞争对手很可能会恶意刷。我们对别人好,但内心要有防备。
监控短信服务,出现问题后做好保护工作
以上方法不一定能完全防止短信被刷。所以也要做好短信的预警机制,即当短信使用量达到一定量或者短信发送界面被过度调用时,向管理员发送预警信息,管理员可以立即对短信界面进行监控和保护。整理了一下相关数据,今天对上面的问题有了一点了解,就是移动端的验证码正常验证成功,PC端无法验证。可能是产品设计限制恶意刷短信,提出了跨域请求限制。也可能只是个bug。
一个看似简单的函数可以是简单的,复杂的,也可以是非常复杂的。作为技术人员,您应该了解业务、使用场景、用户数量等。并综合考虑。多方面的时代和兼容性也要考虑。
其实这个问题如果能仔细想出来,以后遇到也能充分考虑,开发者总说做增删查改。这个的功能设计的很好,涉及到添加、删除、检查、更改,甚至涉及到一个开发人员设计功能的能力。
做好每一个小功能,从小地方提升用户体验,是产品和开发的共同责任。
1.验证码在后台应该怎么处理,应该存储在哪里,内存,缓存还是数据库?
2.什么样的短信验证码用户体验好,内容好,验证码长度长?