发送和接收短消息必须借用通信运营商的信道,许多短信验证码接口平台通过与通信运营商联系并提供简单有效的API接口,为大多数软件开发人员提供更快,更优质的服务。
对于短信接口平台,我将它分为两种类型:
第一种是验证码由软件开发者(即短消息接口平台的用户)提供,短消息接口平台不保存和处理验证码,即验证码的验证过程。验证码需要由开发人员处理;
另外,验证码由短消息接口平台提供,同时提供验证验证码的另一界面,即验证码不需要开发者处理和验证,更方便,更方便。
当然,短消息接口平台很可能同时提供上述两个接口。至于具体的短信接口平台公司,这里不再赘述。
验证码存储
这里主要谈谈上述第一类短消息接口,即验证码本身是随机生成的,我们需要将其存储起来,以便随后判断验证码是否正确。
验证码的存储可分为以下两种类型:
第一种类型,验证码存储在服务器端会话中(实际上可以使用一个对象),不需要使用数据库资源,但一旦服务器异常重启,会话中的数据将被完全清除,也就是说,验证码将被使用一段时间。它将全部失败,另一个必须认真对待的问题是我们必须清除会话中过时的数据,否则它将继续占用内存并导致内存泄漏。
其次,验证码存储在数据库中,这将占用额外的数据库资源,但显然服务器端将更容易,并且许多数据库提供TTL(生存时间)功能,通过设置数据的有效期, database将自动删除过期的数据。当然,我们可以简单地存储验证码创建或过期的时间,并花时间判断验证码是否在有效期内。推荐:企业网站登录注册的短信验证码操作机制
实施例
使用哪个数据库?直接使用mongo,它支持TTL本身,项目的其他数据存储也将使用mongo,因此除了项目本身将使用redis进行缓存之外,不需要为验证代码执行redis数据库。
服务器端逻辑过程:
1.接受用户的手机号码并判断其合法性。
2.随机生成4位验证码。
3.调用短消息接口平台的API接口,并使用随机生成的验证码和用户的手机号码作为输入。
输入参数,接收该接口的输出,判断短信验证码是否成功发送。4.将验证码和手机号码保存在数据库中,并将TTL设置为验证码的有效时间。
5.验证过程中,输入手机号码和验证码,检查数据库中是否有相应的数据。
一般过程是这样的。
执行:
1.判断手机号码的合法性:复杂,查询三大运营商的合法个人号码。这太麻烦且实际上有意义。简单地愚弄它。从1开始的11位数可以通过规律来判断。
2,随机生成验证码:Math.random()拼接自己。
3,短信平台的界面调用:不同的平台界面,去看官方文档。
4,存储验证码和手机号码,设置TTL有效时间
5.验证码验证:同时查询是否有与手机号码和验证码匹配的数据。
本文暂时没有评论,来添加一个吧(●'◡'●)