没有碰着过短信被刷问题的产品经理,或许对付这个问题并不是很重视。
在此,先大略先容一下刷短信的黑工具——短信轰炸机。
短信轰炸机便是一个利用写好的程序来大批量刷短信的软件,它能够通过自动批量提比武机号、仿照IP等办法去刷短信。

因此,我们在设计须要用到短信验证码的产品的时候,一定要制订限定规则,避免短信被刷光。

防刷的常见做法,估计大家都不会陌生,PC时期,大部分平台都是通过图形验证码的形式来减少平台被机器所刷的风险,最范例的例子莫过于12306的“奇葩验证码”了。
然而,在移动互联网时期,用户的体验非常主要,有时候利用图形验证码的同时会对用户的体验有一定的影响。
那么,除了图形验证码的办法之外,还有哪些方法能够办理短信被刷的问题呢?以下供应几种办法可供参考:

php防刷PHP短信验证码防刷机制 HTML

1、韶光限定:60秒后才能再次发送

从发送验证码开始,前端(客户端)会进行一个60秒的倒数,在这一分钟之内,用户是无法提交多次发送信息的要求的。
这种方法虽然利用得比较普遍,但是却不是非常有用,技能轻微好点的人完备可以绕过这个限定,直接发送短信验证码。

2、手机号限定:同一个手机号,24小时之内不能够超过5条

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

3、短信验证码限定:30分钟之内发送同一个验证码

网上还有一种方法说:30分钟之内,所有的要求,所发送的短信验证码都是同一个验证码。
第一次要求短信接口,然后缓存短信验证码结果,30分钟之内再次要求,则直接返回缓存的内容。
对付这种办法,不是很清楚短信接口商会不会对发送缓存信息收取用度,如果有兴趣可以理解理解。

4、前后端校验:提交Token参数校验

这种办法比较少人说到,个人以为可以这种方法值得一试。
前端(客户端)在要求发送短信的时候,同时向做事端提交一个Token参数,做事端对这个Token参数进行校验,校验通过之后,再向要求发送短信的接口向用户手机发送短信。

5、唯一性限定:微信产品,限定同一个微信ID用户的要求数量

如果是微信的产品的话,可以通过微信ID来进行识别,然后对同一个微信ID的用户限定,24小时之内最多只能够发送一定量的短信。

6、产品流程限定:分步骤进行

例如注册的短信验证码利用场景,我们将注册的步骤分成2步,用户在输入手机号码并设置了密码之后,下一步才进入验证码的验证步骤。

7、图形验证码限定:图形验证通过后再要求接口

用户输入图形验证码并通过之后,再要求短信接口获取验证码。
为了有更好的用户体验,也可以设计成:一开始不须要输入图形验证码,在操作达到一定量之后,才须要输入图形验证码。
详细情形请根据详细场景来进行设计。

8、IP及Cookie限定:限定相同的IP/Cookie信息最大数量

利用Cookie或者IP,能够大略识别同一个用户,然后对相同的用户进行限定(如:24小时内最多只能够发送20条短信)。
然而,Cookie能够清理、IP能够仿照,而且IP还会涌现局域网相同IP的情形,因此,在利用此方法的时候,该当根据详细情形来思考。

9、短信预警机制,做好出问题之后的防护

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

以上所说到的办法,或许不是很完美,但是可以通过多个办法结合着来作利用,通过多个规则来降落短信被刷的风险。

如果您有更加好的办法,欢迎一起分享

举两个例子,怎么样写好代码

最经典的算法,献给正在口试道路上的你

如果你现在在口试PHP的道路上,看看口试根本题吧