一种基于API的网关控制方法与流程

一种基于api的网关控制方法
技术领域
[0001]
本发明涉及计算机领域，尤其涉及一种基于api的网关控制方法。


背景技术：

[0002]
当互联网渗透到生活的方方面面，各式线上服务(购物、娱乐、生活缴费、投资、教育等等)变得平常不过，服务提供方在新增服务时，会通过h5方式输出服务到自有或第三方app、公众号、生活号等平台上，或者通过api方式输出给具备软件开发能力的代理商(渠道商)或商户。api方式是指自有客户端与服务端的api交互场景，如业务交易下单、交易数据查询等，在进行此类操作前需要用户进行注册并登录。api方式也指具备软件开发能力的下游合作伙伴服务端与服务端的api交互。
[0003]
现有的apa交互需要业务系统的后台管理开发人员和http服务开发人员分别开发才能实现，而两者往往不是同一机构下的员工。业务系统的开发人员需要实现实现接口请求密钥、ip白名单等交互用的鉴权数据管理，http服务的开发人员需要实现接口访问鉴权、业务数据解密等非业务逻辑代码。这样的开发流程会使得工作重复，造成开发周期变长及人力成本浪费，而且业务逻辑代码和接口交互鉴权代码耦合在一起，违背软件工程设计中高内聚低耦合的要求，代码的后续维护存在一定的困难。


技术实现要素：

[0004]
本发明实施例提出一种基于api的网关控制方法，无需重复编码，减少api开发的时间和人力成本。
[0005]
本发明实施例提供一种基于api的网关控制方法，包括：
[0006]
根据预设的网关数据模型将各网关配置成jar包，并为各网关配置数据库连接信息和redis服务器信息；其中，所述网关数据模型内设置有网关配置表、网关method白名单表、网关ip白名单表和网关客户白名单表；
[0007]
获取业务系统发起的业务数据请求，其中所述业务数据请求包括本次请求对象和业务请求参数；
[0008]
根据所述请求对象，调用各网关的jar包，获取第一网关对应的第一网关配置表、第一网关method白名单表、第一网关ip白名单表和第一网关客户白名单表；
[0009]
根据所述第一网关配置表、所述第一网关method白名单表、所述第一网关ip白名单表和所述第一网关客户白名单表，对所述业务请求参数进行网关鉴权；
[0010]
如果所述业务请求参数的网关鉴权不通过，向所述业务系统反馈相应的不通过信息；如果所述业务请求参数的网关鉴权通过，则根据预设的转发规则，将在网关鉴权过程中获得的业务数据，转发给对应的业务服务端。
[0011]
进一步的，所述网关配置表用于记录各客户端的网关参数，所述网关参数包括url地址、合法性验证密钥、转发规则和网关状态；
[0012]
所述网关method白名单表用于记录允许授权的method参数；
[0013]
所述网关ip白名单表用于记录允许授权的ip；
[0014]
所述网关客户白名单表用于记录允许授权的客户id。
[0015]
进一步的，所述根据所述请求对象，调用各网关的jar包，获取第一网关对应的第一网关配置表、第一网关method白名单表、第一网关ip白名单表和第一网关客户白名单表，具体为：
[0016]
根据所述请求对象，确定需调用的网关为第一网关，并调用所述第一网关对应的第一jar包，获取第一网关配置表、第一网关method白名单表、第一网关ip白名单表和第一网关客户白名单表；
[0017]
将所述第一网关method白名单表、第一网关ip白名单表、第一网关客户白名单表、以及所述第一网关配置表中的第一url地址、第一合法性验证密钥、第一转发规则和第一网关状态以json格式存储到value中。
[0018]
进一步的，所述根据所述第一网关配置表、所述第一网关method白名单表、所述第一网关ip白名单表和所述第一网关客户白名单表，对所述业务请求参数进行网关鉴权，具体为：
[0019]
根据所述第一合法性验证密钥，对所述业务请求参数的合法性进行第一验证；若第一验证失败，则生成鉴权不通过信息；
[0020]
若第一验证通过，则对所述业务请求参数进行签名，并对签名后的参数进行第二验证；若第二验证失败，则生成鉴权不通过信息；
[0021]
若第二验证通过，则根据第一url地址，对业务请求参数中的url地址进行第三验证；若第三验证失败，则生成鉴权不通过信息；
[0022]
若第三验证通过，则根据所述第一网关状态，对所述业务请求参数进行第四验证；若第四验证失败，则生成鉴权不通过信息；
[0023]
若第四验证通过，则根据所述第一网关ip白名单表，对所述业务请求参数进行第五验证；若第五验证失败，则生成鉴权不通过信息；
[0024]
若第五验证通过，则根据所述第一网关method白名单表，对所述业务请求参数进行第六验证；若第六验证失败，则生成鉴权不通过信息；
[0025]
若第六验证通过，则在用户的登录鉴权通过后，解密所述业务请求参数中的biz_content参数，获得相应的业务数据；
[0026]
根据所述第一网关客户白名单表，对所述业务请求参数进行第七验证；若第七验证失败，则生成鉴权不通过信息；
[0027]
若第七验证通过，则确定所述业务请求参数通过本次网关鉴权。
[0028]
进一步的，所述如果所述业务请求参数的网关鉴权通过，则根据预设的转发规则，将在网关鉴权过程中获得的业务数据，转发给对应的业务服务端，具体为：
[0029]
根据所述第一转发规则，将解密所述业务请求参数中的biz_content参数后获得的业务数据，转发给对应的业务服务端。
[0030]
实施本发明实施例，具有如下有益效果：
[0031]
本发明实施例提供的一种基于api的网关控制方法，先根据网关数据模型将各网关配置成jar包，并为各网关配置数据库连接信息和redis服务器信息；在收到业务系统发起的业务数据请求时，根据请求对象调用各jar包，并获取第一网关对应的第一网关配置
表、第一网关method白名单表、第一网关ip白名单表和第一网关客户白名单表；然后根据获取的参数对业务请求参数进行网关鉴权，如果鉴权不通过，则反馈相应的不通过信息，如果鉴权通过，则根据转发规则，将网关鉴权过程中获得的业务数据转发给对应的业务服务端。相比于现有技术需要不同的开发人员进行api接口开发，本发明无需重复编码，减少api开发的时间和人力成本。
附图说明
[0032]
图1是本发明提供的基于api的网关控制方法的一种实施例的流程示意图；
[0033]
图2是本发明提供的网关数据模型的一种实施例的示意图。
具体实施方式
[0034]
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0035]
参见图1，是本发明提供的基于api的网关控制方法的一种实施例的流程示意图。该基于api的网关控制方法包括步骤101至步骤105，各步骤具体如下：
[0036]
步骤101：根据预设的网关数据模型将各网关配置成jar包，并为各网关配置数据库连接信息和redis服务器信息；其中，网关数据模型内设置有网关配置表、网关method白名单表、网关ip白名单表和网关客户白名单表。
[0037]
在本实施例中，本发明的网关控制方法可以转换成相应的软件，采用java开发语言、mysql数据库、redis缓存等，但不局限于java、mysql、redis等技术，也可以使用其他的数据库和缓存技术。
[0038]
在本实施例中，向根据网关数据模型将各网关配置成jar包，配置所需的数据库连接信息(支持db2、oracle、mysql、sql server等关系型数据库作为永久性存储)及redis服务器信息，无需额外开发工作即可在现有的后台管理系统中管理和维护网关。
[0039]
参见图2，图2是本发明提供的网关数据模型的一种实施例的示意图。网关数据模型内设置有网关配置表t_gateway、网关method白名单表t_gateway_method、网关ip白名单表t_gateway_ip和网关客户白名单表t_gateway_cust。
[0040]
网关配置表用于记录各客户端的网关参数，所述网关参数包括url地址、合法性验证密钥、转发规则和网关状态。同一app，安卓和ios各配置一条网关记录，微信公众号、小程序、生活号都是独立一个网关配置表。一条网关记录即为一个外放通道。下面结合图2详细说明网关配置表中比较重要的字段。
[0041]
字段partner_url为url地址，http请求地址在网关记录中具有唯一性，每个不同的自有客户端或api外放下游合作伙伴都有不同的url地址。本发明配置各自独立的url地址的好处是可提前在防火墙进行流量统计及监控，当通道请求量异常时，可临时禁用此通道的访问，而不至于影响整个业务。
[0042]
字段app_key为合法性验证密钥，在网关记录中具有唯一性，网关收到http请求时读取报文参数app_key来验证本次请求是否合法，同时也用于业务参数的解密。
[0043]
字段forwarding_rule为转发规则，某次请求通过网关检验后，网关根据此配置将请求转发到相应业务系统接口处理。
[0044]
字段cust_verify用于判断是否校验接口参数cust_id(y:校验，n：不校验)。网关根据此配置来决定是否校验接口中的业务参数cust_id是否合法。自有客户端通常配置n值，api外放下游通常配置y。
[0045]
字段state为网关状态，用于标记外放通道的状态，“已启用”的外放通道请求才能被网关接受，才能流转到下一个处理环节，可用于因某些原因需要临时停用通道，或与下游合作终止而长期停用通道。
[0046]
网关method白名单表t_gateway_method用于记录允许授权的method参数，网关会校验所收到的请求参数method是否存在于此表中，不存在就会拒绝访问。如果所有method请求都被允许的话，可以配置一条*值记录。
[0047]
网关ip白名单表t_gateway_ip用于记录允许授权的ip，网关ip白名单采用ipv4方式的配置方式(如10.20.1.1)；*号代表此段不做检查，*.*.*.*代表网关允许所有ip发起http请求。
[0048]
网关客户白名单表t_gateway_cust用于记录允许授权的客户id。业务系统通常都会有客户概念在其中，此表为一个可选配表，当网关表中cust_verify字段值为y时，表示需要网关校验接口cust_id参数，也就是说某个下游能为哪些客户发起交易接口。注：普通客户就只能为自己发起交易请求，通常就只会配置一个cust_id；集成商角色的客户就能为他所服务的多个客户发起交易请求，即需配置多个cust_id。
[0049]
如图2所示，图中还包括t_gateway_his网关历史表，用于记录网关的新增到修改全过程的所有操作日志。
[0050]
步骤102：获取业务系统发起的业务数据请求，其中业务数据请求包括本次请求对象和业务请求参数。
[0051]
在本实施例中，业务系统在通信时会发起相应的业务数据请求，该请求包括本次请求对象(具体是哪个网关)和业务请求参数。业务请求参数中的一部分数据是用于网关鉴权，另一部分是用于业务的后续处理。
[0052]
步骤103：根据请求对象，调用各网关的jar包，获取第一网关对应的第一网关配置表、第一网关method白名单表、第一网关ip白名单表和第一网关客户白名单表。
[0053]
在本实施例中，步骤103具体为：根据请求对象，确定需调用的网关为第一网关，并调用第一网关对应的第一jar包，获取第一网关配置表、第一网关method白名单表、第一网关ip白名单表和第一网关客户白名单表；将第一网关method白名单表、第一网关ip白名单表、第一网关客户白名单表、以及第一网关配置表中的第一url地址、第一合法性验证密钥、第一转发规则和第一网关状态以json格式存储到value中。
[0054]
在本实施例中，在确定本次请求的网关为第一网关后，key由http接口请求参数(未加密部分)app_key作为唯一主键，当网关收到请求，通过app_key以主键方式直接取到对应的网关数据进行合法性校验(如调取不到说明本次请求为非法)，并将网关所有需要校验的数据以json格式存储到value中，将接口方法列表(method)、商户列表(cust)、ip列表(ip)做为value值中的一部分，而非单独的hashkey方式存储，可以避免网关多次请求缓存服务器获取接口方法列表(method)、商户列表(cust)、ip列表(ip)等数据，降低网关响应耗
时。
[0055]
步骤104：根据第一网关配置表、第一网关method白名单表、第一网关ip白名单表和第一网关客户白名单表，对业务请求参数进行网关鉴权。
[0056]
在本实施例中，步骤104具体为：
[0057]
s1：根据第一合法性验证密钥，对业务请求参数的合法性进行第一验证；若第一验证失败，则生成鉴权不通过信息；若第一验证通过，则执行s2。
[0058]
在本实施例中，s1的第一验证为：根据第一合法性验证密钥app_key判断是否能够调用相应的网关数据，如果能调用则通过第一验证，如果不能调用则第一验证失败。第一验证失败生成的鉴权不通信息包含“app_key不合法”这一原因。
[0059]
s2：对业务请求参数进行签名，并对签名后的参数进行第二验证；若第二验证失败，则生成鉴权不通过信息；若第二验证通过，则执行s3。
[0060]
在本实施例中，第二验证为对业务请求参数进行签名，再与业务请求参数中的sign参数仅比对，如果一致，则通过第二验证，如果不一致，则第二验证失败。第二验证失败生成的鉴权不通信息包含“签名失败”这一原因。
[0061]
签名规则具体如下：
[0062]
1请求参数按照ascii码表的顺序进行排列；
[0063]
2所有参数名和参数值(sign参数不参与签名，加密后biz_content也需参与签名)按照上面的排序连接起来，格式是：
[0064]
<paramname1><paramvalue1><paramname2><paramvalue2>...
[0065]
3将密钥分别添加到请求参数串的头部和尾部:<appsecret><请求参数字符串><appsecret>；
[0066]
4对该字符串进行sha1运算，得到摘要二进制数组；
[0067]
5将二进制数组转换为十六进制字符串，获得签名，将该签名与sign参数进行比对。
[0068]
s3：根据第一url地址，对业务请求参数中的url地址进行第三验证；若第三验证失败，则生成鉴权不通过信息；若第三验证通过，则执行s4。
[0069]
在本实施例中，第三验证为判断业务请求参数中的url地址是否与第一url地址一致，如果一致，则通过第三验证，如果不一致，则第三验证失败。第三验证失败生成的鉴权不通信息包含“url地址不合法”这一原因。
[0070]
s4：根据第一网关状态，对业务请求参数进行第四验证；若第四验证失败，则生成鉴权不通过信息；若第四验证通过，则执行s5。
[0071]
在本实施例中，第四验证为判断第一网关状态是否为已启用状态；如果是，则通过第四验证，如果不是，则第四验证失败。第四验证失败生成的鉴权不通信息包含“通道已禁用”这一原因。
[0072]
s5：根据第一网关ip白名单表，对业务请求参数进行第五验证；若第五验证失败，则生成鉴权不通过信息；若第五验证通过，则执行s6。
[0073]
在本实施例中，第五验证为判断业务请求参数中的ip参数是否在第一网关ip白名单表上，如果是，则通过第五验证，如果不是，则第五验证失败。第五验证失败生成的鉴权不通信息包含“来源ip未被授权访问”这一原因。
[0074]
s6：根据第一网关method白名单表，对业务请求参数进行第六验证；若第六验证失败，则生成鉴权不通过信息；若第六验证通过，则执行s7。
[0075]
在本实施例中，第六验证为判断业务请求参数中的method参数是否在第一网关method白名单表上；如果是，则通过第六验证，如果不是，则第六验证失败。第六验证失败生成的鉴权不通信息包含“method请求未被授权访问”这一原因。
[0076]
s7：在用户的登录鉴权通过后，解密业务请求参数中的biz_content参数，获得相应的业务数据。
[0077]
在本实施例中，用户的登录鉴权具体为：业务请求参数中包括auth_token参数，根据auth_token参数调用用户基本数据，判断是否能够获取用户基本数据。如果是，则说明用户登录鉴权通过，如果否，则说明非法登录，反馈用户auth_token验证失败这一消息。
[0078]
在本实施例中，业务参数biz_content加密规则：字符集为utf8、密码为256bits[appsecret]、随机数为16bytes[appiv]、模式为gcm、填充为zeropadding、编码为base64。
[0079]
s8：根据第一网关客户白名单表，对业务请求参数进行第七验证；若第七验证失败，则生成鉴权不通过信息；若第七验证通过，则确定业务请求参数通过本次网关鉴权。
[0080]
在本实施例中，第七验证为判断业务请求参数中的cust_verify参数是否为y，如果是，则进一步判断cust_id是否在第一网关客户白名单表上；如果是，则通过第六验证，如果不是，则第六验证失败。第六验证失败生成的鉴权不通信息包含“不允许代xx(cust_id)发起业务请求”这一原因。如果一开始判定cust_verify参数不为y，则直接通过第六验证。
[0081]
在本实施例中，数据流向具体为外部系统每次发起请求(加密后的业务数据)
→
互联网
→
防火墙
→
nginx服务
→
网关服务(本发明技术方案)
→
业务系统服务(解密后的业务数据)。业务数据在到达网关前，采用aes对称加密，使用：com.alibaba.fastjson.json.tojsonstring(contentjsonpropertyfilter)将业务参数json转化为字符串后按上述规则进行aes加密，保证数据安全。
[0082]
步骤105：如果业务请求参数的网关鉴权不通过，向业务系统反馈相应的不通过信息；如果业务请求参数的网关鉴权通过，则根据预设的转发规则，将在网关鉴权过程中获得的业务数据，转发给对应的业务服务端。
[0083]
在本实施例中，步骤105具体为：根据第一转发规则，将解密业务请求参数中的biz_content参数后获得的业务数据，转发给对应的业务服务端。
[0084]
由上可见，本发明技术方案具有以下优点：
[0085]
1)业务参数加密能有效防止数据在传输环节(下游合作伙伴应用服务器至集成网关的http之间)泄露，保证数据安全。
[0086]
2)接口参数签名加防止请求数据被串改，保证业务系统收到数据与请求数据一致。
[0087]
3)通道url(partnerurl)的独立性配置可对各通道的流量进行日常监控，异常流量能快速识别出来自那个通道，从而对通道进行流量控制。
[0088]
4)通道状态可用于临时停用某个异常通道，而无需找运维人员在防火墙或ng操作，以便于运营人员能快速处理异常通道。
[0089]
5)通道method白名单配置可以有效控制某类客户端或下游合作伙伴只能访问他们需要的业务接口。
[0090]
6)通道ip白名单配置可以防止交互密钥信息丢失造成的伪造交易请求被业务系统受理而造成经济损失。
[0091]
7)通道客户白名单配置为可选项，通过网关custverify参数来决定网关是否需要验证请求接口业务参数客户id(cust_id)能否为此客户发起交易。
[0092]
8)通道转发规则(forwardingrule)可灵活配置某个method请求(业务接口类型)在网关完成验证后，由网关将请求转发给那个业务系统服务处理，避免硬编码，降低耦合度，提高内聚。
[0093]
9)业务系统服务仅引入网关jar包，即可实现http接口访问鉴权、数据解密等工作，而无需重复编码。业务系统开发、测试人员只需关注业务逻辑自身的实现，降低人力物力成本。
[0094]
10)自有客户端与api外放模式的接口文档，在网关强制约束下标准化、规范化。
[0095]
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(read-only memory，rom)或随机存储记忆体(random access memory，ram)等。
[0096]
以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也视为本发明的保护范围。