基于配置式金融交易类短信验证码公共组件的实现方法转让专利

申请号 : CN202110751650.X

文献号 : CN113191762B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 彭鹏

申请人 : 江苏苏宁银行股份有限公司

摘要 :

本发明公开了一种基于配置式金融交易类短信验证码公共组件的实现方法。该方法包括确定具体业务与短信验证码模板配置的绑定关系并存储;后端暴露短信验证码发送、校验等HTTP接口服务形成后端组件,后端组件暴露短信验证码发送、校验服务供前端组件调用;通过npm发布前端组件到资源库形成前端组件,其它项目直接通过npm安装,前端组件经引入和激活后即可在页面中使用。本发明解决了系统的功能冗余问题,提高了系统的可扩展性与隔离性,容易维护和升级;可在前端通过简单的配置来使用短信验证码组件,根据传入参数的不同,也区分了不通业务活动的短信验证码的差异;保证了业务活动的绝对安全性。

权利要求 :

1.基于配置式金融交易类短信验证码公共组件的实现方法,其特征在于,包括以下步骤:

步骤1,确定具体业务与短信验证码模板配置的绑定关系并存储;

步骤2,后端暴露短信验证码发送、校验等HTTP接口服务形成后端组件,所述后端组件暴露短信验证码发送、校验服务供前端组件调用;

步骤3,通过npm发布前端组件到资源库形成前端组件,其它项目直接通过npm安装,所述前端组件经引入和激活后在页面中使用;

所述步骤1具体包括:

步骤1.1,采用唯一的应用代码来标识每一业务系统;

步骤1.2,对每个具体的业务定义一个业务代码来标识该具体业务;

步骤1.3,定义一个活动类型来标识某个具体业务的活动类型;

步骤1.4,通过以上应用代码+业务代码+活动类型来确定具体业务;

步骤1.5,将短信验证码模板划分为短信模板编号和短信模板参数列表两个部分,其中,短信模板编号是唯一的,短信模板参数列表用于填充短信模板,以生成最终的发送短信内容;

步骤1.6,将步骤1.4中的具体业务与步骤1.5中的短信验证码模板绑定并存储;

所述步骤2具体包括:

步骤2.1,前端组件调用后端组件的短信验证码发送接口,并触发短信验证码发送HTTP请求,所述短信验证码发送HTTP请求以手机号码、应用代码、业务代码、活动类型、短信模板参数列表以及产品名称和/或交易金额作为发送请求参数,后端组件接收到该请求后,根据应用代码、业务代码、活动类型来唯一确定一条与其绑定的短信模板编号,然后根据短信模板编号的值去数据库中查询库中配置的短信模板参数列表,以校验前端组件传来的短信模板参数列表中的参数子项是否齐全,如齐全,则后端组件调用短信平台SDK发送短信验证码,发送短信验证码成功之后,生成一个短信流水号,并将短信流水号和全部请求参数对应存储至数据库中;

步骤2.2,前端组件调用后端组件的短信验证码验证接口,并触发短信验证码验证HTTP请求,所述短信验证码验证HTTP请求以短信流水号作为验证请求参数,后端组件收到该请求后,根据短信流水号从数据库缓存中查询出对应的全部参数,然后收集手机号、验证码、短信模板参数列表以及产品名称和/或交易金额,并调用短信平台SDK验证客户输入的验证码,短信验证码验证成功之后,返回一个Token令牌给前端组件,前端组件在短信验证码验证成功之后继续带着Token令牌参数调用具体业务活动接口。

2.根据权利要求1所述的基于配置式金融交易类短信验证码公共组件的实现方法,其特征在于,所述短信平台包括阿里云短信平台。

3.根据权利要求1所述的基于配置式金融交易类短信验证码公共组件的实现方法,其特征在于,所述数据库包括Redis数据库,其以所述短信流水号为key,以所有请求参数组成的Hash表为value存入。

说明书 :

基于配置式金融交易类短信验证码公共组件的实现方法

技术领域

[0001] 本发明涉及鉴别用户身份技术领域,具体涉及一种基于配置式金融交易类短信验证码公共组件的实现方法。

背景技术

[0002] 近年来,随着我行业务规模的不断发展、壮大,越来越多的业务支撑系统孕育而生,而作为银行业、金融业系统中,作为最为常见的鉴别用户身份手段的短信验证码在各个
应用系统中均能看见其身影。
[0003] 现有各个应用系统中接入短信验证码都是重复造轮子的方式,例如接入阿里云短信验证码平台,其步骤是:1、引入阿里云短信平台的SDK(一个短信发送的客户端JAR包);2、
按照接入文档书写与业务有关的短信发送逻辑代码;3、按照接入文档书写与业务有关的短
信验证逻辑代码。每个应用系统接入短信验证码功能都得重复着1、2、3三步,使得系统产生
相当程度的功能冗余。
[0004] 其次,各个系统都有自己的短信验证码功能逻辑,不便于统一维护其代码,例如阿里云短信平台的SDK(软件开发工具包)升级了,每个系统都得一个个跟着升级,升级之后还
得测试,费时费力。
[0005] 银行业、金融业面向客户的应用系统中使用到短信验证码的场景比较固定,基本可以分为:交易类、签约类、认证登录类等,正是由于其有类可循的特点,使得对业务短信验
证码的整合组件化成为可能。

发明内容

[0006] 本发明的目的是针对现有技术存在的不足,提供一种基于配置式金融交易类短信验证码公共组件的实现方法。
[0007] 为实现上述目的,本发明提供了一种基于配置式金融交易类短信验证码公共组件的实现方法,包括以下步骤:
[0008] 步骤1,确定具体业务与短信验证码模板配置的绑定关系并存储;
[0009] 步骤2,后端暴露短信验证码发送、校验等HTTP接口服务形成后端组件,所述后端组件暴露短信验证码发送、校验服务供前端组件调用;
[0010] 步骤3,通过npm发布前端组件到资源库形成前端组件,其它项目直接通过npm安装,所述前端组件经引入和激活后即可在页面中使用。
[0011] 进一步的,所述步骤1具体包括:
[0012] 步骤1.1,采用唯一的应用代码来标识该业务系统;
[0013] 步骤1.2,对每个具体的业务定义一个业务代码来标识该具体业务;
[0014] 步骤1.3,定义一个活动类型来标识某个具体业务的活动类型;
[0015] 步骤1.4,通过以上应用代码+业务代码+活动类型来确定具体业务;
[0016] 步骤1.5,将短信验证码模板划分为短信模板编号和短信模板参数列表两个部分,其中,短信模板编号是唯一的,短信模板参数列表用于填充短信模板,以生成最终的发送短
信内容;
[0017] 步骤1.6,将步骤1.4中的具体业务与步骤1.5中的短信验证码模板绑定并存储。
[0018] 进一步的,所述步骤2具体包括:
[0019] 步骤2.1,前端组件调用后端组件的短信验证码发送接口,并触发短信验证码发送HTTP请求,所述短信验证码发送HTTP请求以手机号码、应用代码、业务代码、活动类型、短信
模板参数列表以及产品名称和/或交易金额作为发送请求参数,后端组件接收到该请求后,
根据应用代码、业务代码、活动类型来唯一确定一条与其绑定的短信模板编号,然后根据短
信模板编号的值去数据库中查询库中配置的短信模板参数列表,以校验前端组件传来的短
信模板参数列表中的参数子项是否齐全,如齐全,则后端组件调用短信平台SDK发送短信验
证码,发送短信验证码成功之后,生成一个短信流水号,并将短信流水号和全部请求参数对
应存储至数据库中;
[0020] 步骤2.2,前端组件调用后端组件的短信验证码验证接口,并触发短信验证码验证HTTP请求,所述短信验证码验证HTTP请求以短信流水号作为验证请求参数,后端组件收到
该请求后,根据短信流水号从数据库缓存中查询出对应的全部参数,然后收集手机号、验证
码、短信模板参数列表以及产品名称和/或交易金额,并调用短信平台SDK验证客户输入的
验证码,短信验证码验证成功之后,返回一个Token令牌给前端组件,前端组件在短信验证
码验证成功之后继续带着Token令牌参数调用具体业务活动接口。
[0021] 进一步的,所述短信平台包括阿里云短信平台。
[0022] 进一步的,所述数据库包括Redis数据库,其以所述短信流水号为key,以所有请求参数组成的Hash表为value存入。
[0023] 有益效果:1.将传统短信验证码接入逻辑代码从各个无关的应用系统中剥离出来形成一个独立的公共组件服务,解决了系统的功能冗余问题,同时组件隔离了短信验证码
功能与具体应用系统,提高了系统的可扩展性与隔离性。独立的公共组件也使得短信验证
码功能代码容易维护和升级,例如在传统短信验证码功能逻辑中,如果短信平台的SDK升级
了,那么各个应用系统也得跟着升级,此时组件化的优势就显得很脱出:所以只要升级组件
一处即可。
[0024] 2.在如银行等特定的领域内,涉及到短信验证码环节就那么屈指可数的几个业务场景,通过具体业务与短信验证码模板配置进行绑定使短信验证码功能组件化成为可能,
这样,就可以在前端通过简单的配置来使用短信验证码组件,同时根据传入参数的不同,也
区分了不通业务活动的短信验证码的差异。
[0025] 3.通过基于一次性Token令牌的机制,在业务活动的短信验证码环节做完之后携带短信验证码组件返回的Token令牌参数请求真正的业务活动,保证了业务活动的绝对安
全性。

附图说明

[0026] 图1是本发明实施例的基于配置式金融交易类短信验证码公共组件的工作流程示意图。

具体实施方式

[0027] 下面结合附图和具体实施例,进一步阐明本发明,本实施例在以本发明技术方案为前提下进行实施,应理解这些实施例仅用于说明本发明而不用于限制本发明的范围。
[0028] 本发明实施例提供了基于配置式金融交易类短信验证码公共组件的实现方法,包括以下步骤:
[0029] 步骤1,确定具体业务与短信验证码模板配置的绑定关系并存储。由于具体的业务活动(例如客户办理定期存款的存入业务)肯定是发生在某个业务系统上的,可通过以下步
骤实现:
[0030] 步骤1.1,采用唯一的应用代码(appCode)来标识该业务系统。
[0031] 步骤1.2,对每个具体的业务定义一个业务代码(bizCode)来标识该具体业务。
[0032] 步骤1.3,定义一个活动类型(actType)来标识某个具体业务的活动类型。
[0033] 步骤1.4,通过以上应用代码(appCode)+业务代码(bizCode)+活动类型(actType)来确定具体业务。
[0034] 例如:
[0035] {
[0036]      appCode: CFSP, //CFSP代表智能存款系统
[0037] bizCode: DQCK, //DQCK代表定期存款业务
[0038] actType: 1     //1‑代表存入,2‑代表支取
[0039] }
[0040] 代表一个完整的业务活动:某客户正在办理定期存款的存入业务,该业务的在线办理实际是通过智能存款系统来完成的。
[0041] 步骤1.5,将短信验证码模板划分为短信模板编号(smsTemplateCode)和短信模板参数列表(smsTemplateParams)两个部分,其中,短信模板编号是唯一的,短信模板参数列
表用于填充短信模板,以生成最终的发送短信内容。
[0042] 举个例子,假如有“定期存款客户提交存入”短信验证码模板:
[0043] “您正在办理定期存款存入业务,验证码:{smsCode},请勿泄露验证码,详情咨询客服电话xxxx”
[0044] 那么该条短信验证码模板就具有一个唯一的smsTemplateCode来代表它,模板中的参数smsCode就是smsTemplateParams的组成部分。
[0045] 步骤1.6,将步骤1.4中的具体业务与步骤1.5中的短信验证码模板绑定并存储。存储位置可以是MySQL等数据库。
[0046] 即通过应用代码(appCode)+业务代码(bizCode)+活动类型(actType)+ 短信模板参数列表(smsTemplateCode)来唯一确定一个业务短信。
[0047] 步骤2,后端暴露短信验证码发送、校验等HTTP接口服务形成后端组件,所述后端组件暴露短信验证码发送、校验服务供前端组件调用。具体的业务服务则无需关心短信验
证码的发送、验证等逻辑。具体包括以下步骤:
[0048] 步骤2.1,前端组件调用后端组件的短信验证码发送接口,并触发短信验证码发送HTTP请求,所述短信验证码发送HTTP请求以手机号码、应用代码(appCode)、业务代码
(bizCode)、活动类型(actType)、短信模板参数列表(smsTemplateCode)以及产品名称
(productName)和/或交易金额(amt)作为发送请求参数,后端组件接收到该请求后,根据应
用代码、业务代码、活动类型来唯一确定一条与其绑定的短信模板编号
(smsTemplateCode),然后根据短信模板编号(smsTemplateCode)的值去数据库中查询库中
配置的短信模板参数列表(smsTemplateParams),以校验前端组件传来的短信模板参数列
表(smsTemplateParams)中的参数子项是否齐全,如齐全,则后端组件调用短信平台SDK发
送短信验证码,发送短信验证码成功之后,生成一个短信流水号(smsSerialNo),并将短信
流水号(smsSerialNo)和全部请求参数对应存储至数据库中。
[0049] 具体的,上述短信平台可以是阿里云短信平台,上述数据库包括Redis数据库,其以短信流水号(smsSerialNo)为key,并以所有请求参数组成的Hash表为value存入Redis数
据库的缓存中。这样,在下一步短信验证码的验证环节仅需传递smsSerialNo、smsCode两个
参数即可。
[0050] 步骤2.2,前端组件调用后端组件的短信验证码验证接口,并触发短信验证码验证HTTP请求,短信验证码验证HTTP请求以短信流水号(smsSerialNo)作为验证请求参数,后端
组件收到该请求后,根据短信流水号(smsSerialNo)从数据库缓存中查询出与该短信流水
号(smsSerialNo)对应的全部参数,然后收集必要的参数(mobile、smsCode、
smsTemplateCode,以及产品名称和/或交易金额等),并调用短信平台SDK验证客户输入的
验证码,短信验证码验证成功之后,返回一个Token令牌给前端组件,前端组件在短信验证
码验证成功之后继续带着Token令牌参数调用具体业务活动接口。例如,调用定期存款的存
入接口。需要说明的是,上述必要的参数中,obile、smsCode、smsTemplateCode为短信验证
码模板所需要的必要参数,产品名称和/或交易金额为必要业务参数,每个短信模板所需的
必要业务参数不固定,有的可能只有productName或amt,有的两者都有。
[0051] Token令牌的作用,Token令牌是一次性令牌,其作用是客户通过基于短信验证码的身份认证之后,在真正执行业务活动的前置校验,只有在Token有效的情况下才会真正执
行业务活动,否则返回错误。这样做的目的是提高安全性,因为通过一定的技术手段,在浏
览器端黑客完全可以绕过短信验证这个环节直接进入业务活动
[0052] 步骤3,通过npm (JavaScript世界的包管理工具)发布前端组件到资源库形成前端组件,其它项目直接通过npm安装,前端组件经引入并激活后即可在页面中使用。具体如
下:
[0053] //1、在页面中引入前端组件
[0054] import {vcsms} from ‘vcsms‑ui’; //引入组件
[0055] import 'vcsms‑ui/lib/index.css'; //引入组件样式
[0056] Vue.use(vcsms); //激活组件
[0057] //2、在页面中使用前端组件
[0058]
[0059] 具体参见图1,本发明的短信验证码公共组件包括前端组件和后端组件两个部分,在工作时,应用系统前端页面接入短信验证码的前端组件,前端组件触发短信验证码发送
HTTP请求至后端组件,后端组件根据业务参数查询业务活动与短信模板的绑定关系,后端
组件还将前面获取的所有数据暂存Redis中,以被验证时使用,前端组件触发短信验证码验
证HTTP请求至后端组件,后端组件短信验证码验证成功之后向前端组件返回Token令牌,应
用服务拿到Token令牌执行真正的业务活动。
[0060] 以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,其它未具体描述的部分,属于现有技术或公知常识。在不脱离本发明原理的前提
下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。