一个短信验证码功能引发的总结思考阿飞云漫步

昨天看到一个地址，新用户免费领取X登读书APP的14天会员，2020年了，要开始读书了。看到这个活动是在笔记本上，于是用笔记本浏览器访问活动页面，输入手机号，收到验证码，填写验证码，领取这个会员。本来以为一切就是这样顺利的结束了，然而并不是，填写验证就提示“网络错误”。这不科学啊，作为程序员，我下意识的按了一下F12，打开了开发者工具，于是看到了下面的错误，如图：

将错误单独截图出来：

简单一点就是出现了跨域的问题。我想了一下，那估计这个活动是针对移动端的，我用PC端访问导致出现跨域。这个地方设计不好。

于是用手机去访问活动页地址，正常打开，然后填写手机号，然后提示：

我刚才PC发了几次验证码，这个地方设计还是考虑到安全性了，不错。

到这里本该就结束了，但是作为一个开发人员，我觉得要简单整理一下这个发短息的功能，因为这个功能虽然看似简单，里面深究起来也有很多地方需要注意以及考虑的。

那在发送验证的时候，其实很多公司用的都是第三方的短信服务，这个短信的服务是需要收费的，天下没有免费的午餐。那么就出现刷短信的黑工具——短信轰炸机。

短信轰炸机就是一个利用写好的程序来大批量刷短信的软件，它能够通过自动批量提交手机号、模拟IP等方式去刷短信。

如果需要用到短信验证码的产品的时候，一定要制定限制规则，做好设计。

主要原则：发送验证码是前端和后台是需要共同设计的，这样相对才能更加完善或者更加完美。主要思路：

xx秒后才能再次发送

具体时效限制要考虑产品本身属性，操作难易度，网络延迟，短信资费成本等。

这一点，图形验证码不一定是必须的。可能为了有更好的用户体验，一开始不需要输入图形验证码，在操作达到一定量之后，才需要输入图形验证码。具体情况请根据具体场景来进行设计。

对使用同一个手机号码进行注册或者其他发送短信验证码的操作的时候，系统可以对这个手机号码进行限制，例如，24小时只能发送5条短信验证码，超出限制则进行报错（如：系统繁忙，请稍后再试）。然而，这也只能够避免人工手动刷短信而已，对于批量使用不同手机号码来刷短信的机器，这种方法也是无可奈何的。

限制相同的IP/Cookie信息最大数量

这样在第三点的基础上防止恶意刷手机验证码短信,如果同一个ip多次请求获取手机验证码短信，因为短信需要钱，竞争对手很可能恶意刷去。（我们对他人心怀善意，但是内心要有防备之心）

监控短信服务，做好出问题之后的防护

以上的方法并不一定能够完全杜绝短信被刷，因此，我们也应该做好短信的预警机制，即当短信的使用量达到一定量之后，向管理员发送预警信息，管理员可以立刻对短信的接口情况进行监控和防护。

一个看似简单的功能，要简单做可以很简单，要复杂也可以很复杂，作为一个技术人员，了解业务，了解使用场景，了解用户量等，全面考虑，多端的时代，兼容性等也要考虑。

其实这个问题如果可以仔细想清楚的话，如果以后遇到就能够全面考虑，并且开发人员总是说自己做增删查改，这个的功能设计好，里面涉及了增删查改，更涉及了一个开发对功能的设计能力。

做好每一个小的功能，从小的地方提升用户体验，是产品和开发共同的责任。

最后在说两点，看到的朋友思考下：1、后台应该如何处理验证码，保存在什么地方，内存，缓存，还是数据库？2、怎么样的短信验证码用户体验好，内容和验证码长度？