业务服务的提供方法和装置、存储介质、电子装置
技术领域
本申请涉及互联网领域,具体而言,涉及一种业务服务的提供方法和装置、存储介质、电子装置。
背景技术
许多企业平台可以对外部平台(如打车软件、网购软件、外卖软件等商户平台)提供实时的服务(如支付服务、借贷服务、提现服务等服务)。
在提供服务时操作较繁琐,针对不同的商户,根据商户需求,每个商户的所需服务需要单独配置,如提供单独的接口,需要逐个为其配置商户访问接口的权限。
针对上述的问题,目前尚未提出有效的解决方案。
发明内容
本申请实施例提供了一种业务服务的提供方法和装置、存储介质、电子装置,以至少解决相关技术中对外提供服务的操作较繁琐的技术问题。
根据本申请实施例的一个方面,提供了一种业务服务的提供方法,包括:通过目标接口获取业务设备发送的目标业务请求,其中,目标接口为第一平台的网关上的接口,目标接口用于接收请求第一平台提供业务服务的业务请求,目标业务请求用于为第二平台请求第一平台提供业务服务,业务设备为在第二平台中使用的设备;利用由业务请求确定的信息对第二平台执行鉴权操作,其中,鉴权操作用于对第二平台的身份进行验证;在对第二平台的鉴权操作通过的情况下,向第二平台提供与第二平台匹配的目标业务服务。
根据本申请实施例的另一方面,还提供了一种业务服务的提供装置,包括:获取单元,用于通过目标接口获取业务设备发送的目标业务请求,其中,目标接口为第一平台的网关上的接口,目标接口用于接收请求第一平台提供业务服务的业务请求,目标业务请求用于为第二平台请求第一平台提供业务服务,业务设备为在第二平台中使用的设备;鉴权单元,用于利用由业务请求确定的信息对第二平台执行鉴权操作,其中,鉴权操作用于对第二平台的身份进行验证;服务单元,用于在对第二平台的鉴权操作通过的情况下,向第二平台提供与第二平台匹配的目标业务服务。
根据本申请实施例的另一方面,还提供了一种存储介质,该存储介质包括存储的程序,程序运行时执行上述的方法。
根据本申请实施例的另一方面,还提供了一种电子装置,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,处理器通过计算机程序执行上述的方法。
在本申请实施例中,对于每个向第一平台申请业务服务的第二平台,可以预先在网关或者第一平台上保存第二平台的鉴权相关的信息,在第二平台需要使用业务服务时统一通过网关的目标接口申请,而不用根据商户需求提供单独的访问接口和访问接口的权限,可以解决相关技术中对外提供服务的操作较繁琐的技术问题,进而达到降低对外提供服务的操作复杂度的技术效果。
附图说明
此处所说明的附图用来提供对本申请的进一步理解,构成本申请的一部分,本申请的示意性实施例及其说明用于解释本申请,并不构成对本申请的不当限定。在附图中:
图1是根据本申请实施例的业务服务的提供方法的硬件环境的示意图;
图2是根据本申请实施例的一种可选的业务服务的提供方法的流程图;
图3是根据本申请实施例的一种可选的业务服务的提供方法的流程图;
图4是根据本申请实施例的一种可选的业务服务的提供装置的示意图;以及,
图5是根据本申请实施例的一种终端的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本申请方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分的实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
需要说明的是,本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先,在对本申请实施例进行描述的过程中出现的部分名词或者术语适用于如下解释:
HTTPS(全称:Hyper Text Transfer Protocol over SecureSocket Layer),是以安全为目标的HTTP通道,在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性。
RPC是远程过程调用(Remote Procedure Call)的缩写形式,有一些类似于三层构架的C/S系统,第三方的客户程序通过接口调用系统内部的标准或自定义函数,获得函数返回的数据进行处理。
RSA加密算法是一种非对称加密算法,RSA公开密钥密码体制。所谓的公开密钥密码体制就是使用不同的加密密钥与解密密钥,是一种“由已知加密密钥推导出解密密钥在计算上是不可行的”密码体制。
密码学中的高级加密标准(Advanced Encryption Standard,AES),又称Rijndael加密法,是一种常采用的加密标准。
根据本申请实施例的一方面,提供了一种业务服务的提供方法的方法实施例。
可选地,在本实施例中,上述业务服务的提供方法可以应用于如图1所示的由第一平台101、第二平台103和网关105所构成的硬件环境中。如图1所示,网关105通过网络与第一平台101和第二平台103进行连接,可用于为第一平台101提供鉴权服务,可在网关105上或独立于网关105设置数据库107,用于为网关105提供数据存储服务,上述网络包括但不限于:广域网、城域网或局域网。
本申请实施例的业务服务的提供方法可以由网关105来执行,也可以由网关105与第一平台101、第二平台103共同执行。
图2是根据本申请实施例的一种可选的业务服务的提供方法的流程图,如图2所示,该方法可以包括以下步骤:
步骤S202,通过目标接口获取业务设备发送的目标业务请求,目标接口为第一平台的网关上的接口,目标接口用于接收请求第一平台提供业务服务的业务请求,目标业务请求用于为第二平台请求第一平台提供业务服务,业务设备为在第二平台中使用的设备。
上述第一平台为对外输出服务的平台,如输出金融类服务(如结账服务、借贷服务、打车服务、外卖服务等);上述第二平台为使用第一平台输出的服务的平台,如某网购平台,其使用了第一平台输出的结账服务;上述目标接口为第一平台的网关上统一接收各个第二平台发送的业务请求的接口,业务设备可以为第二平台上的服务器、用户终端等设备。
步骤S204,利用由业务请求确定的信息对第二平台执行鉴权操作,鉴权操作用于对第二平台的身份进行验证。
步骤S206,在对第二平台的鉴权操作通过的情况下,向第二平台提供与第二平台匹配的目标业务服务。
上述与第二平台匹配的目标业务服务可以是根据第二平台确定的,如每个第二平台所能使用的业务服务是预先配置好的,也就是说,只要知道具体是哪一个第二平台,那么就能查找到其使用的业务服务;上述与第二平台匹配的目标业务服务还可以是根据目标业务请求确定的,例如在目标业务请求中携带所需的目标业务服务的标识,可预先配置好第二平台所能使用的业务服务(可以为多个业务服务,如保存第二平台与这多个业务服务的多个标识之间的对应关系),在发起目标业务请求时,获取目标业务请求携带的标识,在该标识是上述多个标识中的部分标识的情况下,可向第二平台提供该标识对应的业务服务。
相关技术中每个商户的所需服务需要单独配置,提供单独的接口、加解密方式不统一、无法控制黑名单或白名单,每个内部的RPC服务都需包装转换成HTTPS协议接口,每个接口对外的域名都需要独立申请,赋能商户的过程处理效率低、浪费资源。通过本申请的上述步骤,对于每个向第一平台申请业务服务的第二平台,可以预先在网关或者第一平台上保存第二平台的鉴权相关的信息,在第二平台需要使用业务服务时统一通过网关的目标接口申请,而不用根据商户需求提供单独的访问接口和配置访问接口的权限,可以解决相关技术中对外提供服务的操作较繁琐的技术问题,进而达到降低对外提供服务的操作复杂度的技术效果。
采用本申请的技术方案,可统一对外输出网关的目标接口(如HTTPS接口),提供统一包装服务、安全服务、控制服务。下面结合图2所示的步骤进一步详述本申请的技术方案:
在步骤S202提供的技术方案中,对于每个第二平台(如商户),可通过后台主动配置好其所需要的服务,也可受商户请求配置其所需的服务,并将这些服务与该商户(如商户的标识ID)对应起来,如商户启动其应用的某个第一平台的赋能(即提供的服务)时,可以直接使用这些服务;通过统一的网关的目标接口(如HTTPS接口)提供服务,在发起服务请求时,网关通过目标接口获取业务设备发送的目标业务请求。
可选地,对于为商户提供的服务,可以提供升级维护、暂停、停止、恢复等服务。
在步骤S204提供的技术方案中,利用由业务请求确定的信息对第二平台执行鉴权操作,如某商户通过目标接口接入时,通过非对称加解密实现鉴权,进而提供相应的服务。
可选地,利用由业务请求确定的信息对第二平台执行鉴权操作包括步骤S2042-步骤S2044:
步骤S2042,根据业务请求获取业务设备的设备地址和/或秘钥信息,秘钥信息用于对第一平台与第二平台之间传输的信息进行非对称加解密。
可选地,根据业务请求获取业务设备的设备地址包括:获取业务请求中携带的设备地址为业务设备的设备地址,该设备地址可以为设备的硬件MAC地址,也可以为网络IP地址。
步骤S2044使用业务设备的设备地址和/或秘钥信息对第二平台执行鉴权操作。
在上述实施例中,若只使用设备地址进行鉴权,即使用业务设备的设备地址对第二平台执行鉴权操作,可以按照如下所示步骤1-步骤2实现:
步骤1,在第二平台配置有白名单且业务设备的设备地址存在于白名单内的情况下,确定对业务设备的鉴权操作通过;在第二平台配置有白名单且业务设备的设备地址不存在于白名单内的情况下,确定对业务设备的鉴权操作未通过,其中,白名单用于保存允许发送信息的设备的地址;
步骤2,在第二平台配置有黑名单且业务设备的设备地址不存在于黑名单内的情况下,确定对业务设备的鉴权操作通过;在第二平台配置有黑名单且业务设备的设备地址存在于黑名单内的情况下,确定对业务设备的鉴权操作未通过,其中,黑名单用于保存不允许发送信息的设备的地址。
可选地,以设备地址为IP地址为例,在黑名单和白名单的校验中,校验的顺序依次可以是:若当前商户已配置访问网关的白名单IP,则进行白名单校验,即白名单内的IP可访问,不在白名单内的IP直接拒绝,若当前商户没有配置访问网关的白名单IP,则跳过白名单校验;若当前商户已配置访问网关的黑名单IP,则进行黑名单校验,即不在黑名单内的IP可访问,在黑名单内的IP直接拒绝,若当前商户没有配置访问网关的黑名单IP,则跳过黑名单校验。
上述实施例中,若只使用秘钥信息进行鉴权,即使用秘钥信息对第二平台执行鉴权操作,可以按照如下所示步骤1-步骤6实现:
步骤1,确定是否存在与目标业务请求中的平台标识(如商户ID、商户号等)对应的第二平台的平台公钥,秘钥信息包括第二平台的平台公钥。该步骤即公钥校验,校验商户平台的公钥,校验的逻辑根据商户号校验该商户号在网关平台是否配置有公钥信息。
步骤2,在确定存在与第二平台的平台标识对应的平台公钥的情况下,确定是否存在与目标业务请求中的临时令牌对应的第一平台的平台私钥,秘钥信息包括第一平台的平台私钥。
步骤3,在确定存在与临时令牌对应的第一平台的平台私钥的情况下,利用第一平台的平台私钥对目标业务请求中的加密报文进行解密。
步骤4,在利用第一平台的平台私钥对目标业务请求中的加密报文解密成功的情况下,利用第二平台的平台公钥对目标业务请求中第二平台的签名信息进行验证。
步骤5,在利用第二平台的平台公钥对第二平台的签名信息的验证通过的情况下,确定对业务设备的鉴权操作通过。
步骤6,在确定不存在与第二平台的平台标识对应的平台公钥或在确定不存在与临时令牌对应的第一平台的平台私钥或利用第一平台的平台私钥对目标业务请求中的加密报文解密失败或在利用第二平台的平台公钥对第二平台的签名信息的验证不通过的情况下,确定对业务设备的鉴权操作未通过。
上述步骤1-6的过程即验签,根据商户发送的请求中的报文密文(或称加密报文),根据第一平台的私钥进行解密,得到的请求报文的明文,解密过程可以是根据第一平台的私钥及请求报文中的Key信息,通过RSA解密得到16位长度的加密随机字符串,再通过AES算法根据该16位长度的加密随机字符串和请求报文中的Body信息(HTTPS报文中的一个组成部分),解密得到请求报文中Body中的明文信息。然后根据第一平台指定的签名规则,组装签名体,根据商户公钥进行验签。
需要说明的是,上述秘钥都是以秘钥对的形式存在,同一秘钥对中的公钥是公开的,可以被其它平台知晓,而私钥是私有的,仅平台自己知晓。
在上述实施例中,若同时使用设备地址和秘钥信息进行鉴权,可以按照先执行利用设备地址鉴权的步骤,在通过的情况下,再执行利用秘钥信息进行鉴权,二者任意之一鉴权未通过则视为未通过。
上述实施例中,若只使用秘钥信息进行鉴权,即使用秘钥信息对第二平台执行鉴权操作,可以按照如上所示步骤1-步骤6实现。
在步骤S206提供的技术方案中,向第二平台提供与第二平台匹配的目标业务服务,如照对目标业务请求中的加密报文进行解密得到的信息确定目标业务服务;向第二平台提供加密后的目标业务服务的数据(如交易数据)。
作为一种可选的实施例,本申请的技术方案可以分为如下几个部分:
网关平台内部实现逻辑:网关平台配置的商户,按其所需服务,分配相应的接口,且商户内可访问的每个接口是唯一的,网关平台支持将HTTP、HTTPS、JSF三种协议类型的接口统一为HTTPS协议,商户可根据为其分配的商户号、接口类型、公钥、token进行指定赋能服务的使用。
网关平台调用流程(商户调用第二平台):商户(即第二平台)按照第一平台的平台侧提供的网关请求报文的接口规则,组装包括:商户号、接口类型、外部用户id、金融openId、token、签名、加密报文体、版本等信息,发送HTTPS的post请求(即业务请求)至网关平台,网关平台对接收到的报文做请求IP黑白名单校验、公钥校验、验签、解密报文体、按照接口类型路由商户请求至第二平台的平台侧具体的服务,网关平台收到第二平台的平台侧具体服务的返回信息按照约定规则做加密、签名操作,将报文返回给商户。
网关平台调用流程(第二平台的平台回调商户):第二平台的平台侧服务调用配置至网关平台的某个商户的服务,网关平台根据第二平台的平台侧服务的请求报文信息,包括:商户号、接口类型、报文明文等信息,做报文加密、报文签名、路由商户服务等操作,将加密后的请求报文发送至商户侧服务,待商户侧按照约束规则返回加密且签名请求结果后,网关平台对商户侧的请求结果按照约束规则进行解密、验签后,将商户侧的服务明文结果返回给第二平台侧的服务。
网关平台处理流程:外部商户请求第二平台的平台服务的流程:根据请求报文获取第二平台侧的私钥;根据请求报文获取商户侧公钥;根据第二平台的平台侧私钥和商户侧公钥,对报文体进行解密和验签,得到请求服务的明文报文;根据请求报文,路由商户请求的服务;根据明文报文,路由给商户请求的服务,封装请求第二平台的平台服务的报文;根据路由给商户的服务,封装请求第二平台的平台服务的报文,根据协议类型(JSF/Http)不同,执行具体的请求操作;校验请求第二平台的平台服务的返回结果;对第二平台的平台服务的返回结果进行加密、签名;返回结果记录日志;将加密签名后的第二平台的平台侧服务的返回值报文,返回给商户侧。
服务路由的流程:根据网关商户号、接口类型,路由商户请求的第二平台的平台侧服务;验签及解密报文的代码:根据商户请求报文中的签名、第二平台的平台私钥,获取签名Key;根据请求报文Body、签名Key,获取请求报文中Body的明文;根据Body的明文和请求报文,获取待校验数据;校验请求报文的签名是否正确;返回Body的明文信息;黑白名单校验的代码:从商户请求的报文中获取请求IP;校验是否在白名单中;校验是否在黑名单中;第二平台的平台侧回调商户的代码:根据第二平台的平台侧的请求报文获取商户的公钥信息;根据第二平台的平台侧的请求报文获取第二平台的平台侧的私钥信息;根据第二平台的平台侧报文体、商户公钥、第二平台的平台侧私钥构建请求商户的报文体;根据第二平台的平台侧请求报文路由的服务,向商户发送请求;校验商户侧的返回值;对商户侧的返回值进行解密、验签;将商户侧返回值的明文返回给第二平台的平台侧服务;加密及签名的代码(适用对象:第二平台的平台回调商户时的请求报文、商户请求第二平台时的返回报文):随机生成AES密钥;AES加密数据;使用RSA算法将商户自己随机生成的AESkey加密;数据签名;返回加密、签名以后的报文体。
本申请的技术方案适用于多种类型的场景、如借贷、支付、取现等,例如,以适用的业务案例“借贷业务A”为例,该业务为平台A(即第一平台)与平台B(即第二平台)合作的借贷联营产品,双方用户账户关联、共享借贷额度,且支持在寺库场景额度超限。用户可在第二平台的APP中完成激活、交易、查账和还款的闭环操作,其中查账还款时跳转至第一平台的账单页面实现,用户可在第一平台的完成激活流程,激活后可在第二平台上进行消费。下面结合图3所示的步骤进一步详述本申请的技术方案。
步骤S302,第二平台的商户(即生态应用)向网关发起请求。
步骤S304,根据请求参数中的商户号,获取关联的商户侧公钥。
步骤S306,若不存在关联的商户侧公钥,则返回访问失败的提示信息。
步骤S308,若存在则获取生态侧请求参数中的令牌token,获取关联的平台侧私钥。
步骤S310,若不存在关联的平台侧私钥,则返回访问失败的提示信息。
步骤S312,若存在则根据平台侧私钥、商户侧公钥进行签名验证和解密。
步骤S314,若签名验证或者解密失败,则返回访问失败的提示信息。
步骤S316,若签名验证和解密成功,则根据商户号、接口类型查找对应的商户服务。
步骤S318,若未查找到对应的商户服务,则返回提示信息,提示商户服务未注册。
步骤S320,若查找到对应的商户服务,则调用商户服务接收商户服务的返回结果。
步骤S322,将商户服务的返回结果发送给商户侧,若商户侧没有响应则说明商户侧的业务接口异常。
步骤S324,若商户侧进行了响应,则对商户侧的业务接口发送的返回结果进行解密、签名验证。
步骤S326,若解密、签名验证通过,网关则根据其返回结果向商家侧返回相应的信息。
采用本申请的技术方案,将商户所需服务统一协议,统一安全鉴权机制,统一访问控制机制,丰富角色的管理系统功能,提高管理效率,提高产品的赋能效率。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请并不受所描述的动作顺序的限制,因为依据本申请,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本申请所必须的。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本申请各个实施例所述的方法。
根据本申请实施例的另一个方面,还提供了一种用于实施上述业务服务的提供方法的业务服务的提供装置。图4是根据本申请实施例的一种可选的业务服务的提供装置的示意图,如图4所示,该装置可以包括:
获取单元401,用于通过目标接口获取业务设备发送的目标业务请求,其中,所述目标接口为第一平台的网关上的接口,所述目标接口用于接收请求所述第一平台提供业务服务的业务请求,所述目标业务请求用于为第二平台请求所述第一平台提供业务服务,所述业务设备为在所述第二平台中使用的设备;
鉴权单元403,用于利用由所述业务请求确定的信息对所述第二平台执行鉴权操作,其中,所述鉴权操作用于对所述第二平台的身份进行验证;
服务单元405,用于在对所述第二平台的鉴权操作通过的情况下,向所述第二平台提供与所述第二平台匹配的目标业务服务。
需要说明的是,该实施例中的获取单元401可以用于执行本申请实施例中的步骤S202,该实施例中的鉴权单元403可以用于执行本申请实施例中的步骤S204,该实施例中的服务单元405可以用于执行本申请实施例中的步骤S206。
此处需要说明的是,上述模块与对应的步骤所实现的示例和应用场景相同,但不限于上述实施例所公开的内容。需要说明的是,上述模块作为装置的一部分可以运行在如图1所示的硬件环境中,可以通过软件实现,也可以通过硬件实现。
相关技术中每个商户的所需服务需要单独配置,提供单独的接口、加解密方式不统一、无法控制黑名单或白名单,每个内部的RPC服务都需包装转换成HTTPS协议接口,每个接口对外的域名都需要独立申请,赋能商户的过程处理效率低、浪费资源。通过本申请的上述步骤,对于每个向第一平台申请业务服务的第二平台,可以预先在网关或者第一平台上保存第二平台的鉴权相关的信息,在第二平台需要使用业务服务时统一通过网关的目标接口申请,而不用根据商户需求提供单独的访问接口和访问接口的权限,可以解决相关技术中对外提供服务的操作较繁琐的技术问题,进而达到降低对外提供服务的操作复杂度的技术效果。
可选地,所述鉴权单元包括:获取模块,用于根据所述业务请求获取所述业务设备的设备地址和/或秘钥信息,其中,所述秘钥信息用于对所述第一平台与所述第二平台之间传输的信息进行非对称加解密;鉴权模块,用于使用所述业务设备的设备地址和/或所述秘钥信息对所述第二平台执行所述鉴权操作。
可选地,鉴权模块还可用于:在所述第二平台配置有白名单且所述业务设备的设备地址存在于所述白名单内的情况下,确定对所述业务设备的鉴权操作通过;在所述第二平台配置有所述白名单且所述业务设备的设备地址不存在于所述白名单内的情况下,确定对所述业务设备的鉴权操作未通过,其中,所述白名单用于保存允许发送信息的设备的地址;在所述第二平台配置有黑名单且所述业务设备的设备地址不存在于所述黑名单内的情况下,确定对所述业务设备的鉴权操作通过;在所述第二平台配置有所述黑名单且所述业务设备的设备地址存在于所述黑名单内的情况下,确定对所述业务设备的鉴权操作未通过,其中,所述黑名单用于保存不允许发送信息的设备的地址。
可选地,鉴权模块还可用于:确定是否存在与所述目标业务请求中的平台标识对应的所述第二平台的平台公钥,其中,所述秘钥信息包括所述第二平台的平台公钥;在确定存在与所述第二平台的平台标识对应的平台公钥的情况下,确定是否存在与所述目标业务请求中的临时令牌对应的所述第一平台的平台私钥,其中,所述秘钥信息包括所述第一平台的平台私钥;在确定存在与所述临时令牌对应的所述第一平台的平台私钥的情况下,利用所述第一平台的平台私钥对所述目标业务请求中的加密报文进行解密;在利用所述第一平台的平台私钥对所述目标业务请求中的加密报文解密成功的情况下,利用所述第二平台的平台公钥对所述目标业务请求中所述第二平台的签名信息进行验证;在利用所述第二平台的平台公钥对所述第二平台的签名信息的验证通过的情况下,确定对所述业务设备的鉴权操作通过;在确定不存在与所述第二平台的平台标识对应的平台公钥或在确定不存在与所述临时令牌对应的所述第一平台的平台私钥或利用所述第一平台的平台私钥对所述目标业务请求中的加密报文解密失败或在利用所述第二平台的平台公钥对所述第二平台的签名信息的验证不通过的情况下,确定对所述业务设备的鉴权操作未通过。
可选地,获取模块还可用于获取所述业务请求中携带的设备地址为所述业务设备的设备地址。
可选地,服务单元还可用于按照对所述目标业务请求中的加密报文进行解密得到的信息确定所述目标业务服务;向所述第二平台提供加密后的所述目标业务服务的数据。
此处需要说明的是,上述模块与对应的步骤所实现的示例和应用场景相同,但不限于上述实施例所公开的内容。需要说明的是,上述模块作为装置的一部分可以运行在如图1所示的硬件环境中,可以通过软件实现,也可以通过硬件实现,其中,硬件环境包括网络环境。
根据本申请实施例的另一个方面,还提供了一种用于实施上述业务服务的提供方法的服务器或终端。
图5是根据本申请实施例的一种终端的结构框图,如图5所示,该终端可以包括:一个或多个(图5中仅示出一个)处理器501、存储器503、以及传输装置505,如图5所示,该终端还可以包括输入输出设备507。
其中,存储器503可用于存储软件程序以及模块,如本申请实施例中的业务服务的提供方法和装置对应的程序指令/模块,处理器501通过运行存储在存储器503内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的业务服务的提供方法。存储器503可包括高速随机存储器,还可以包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,存储器503可进一步包括相对于处理器501远程设置的存储器,这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
上述的传输装置505用于经由一个网络接收或者发送数据,还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中,传输装置505包括一个网络适配器(Network Interface Controller,NIC),其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中,传输装置505为射频(Radio Frequency,RF)模块,其用于通过无线方式与互联网进行通讯。
其中,具体地,存储器503用于存储应用程序。
处理器501可以通过传输装置505调用存储器503存储的应用程序,以执行下述步骤:
通过目标接口获取业务设备发送的目标业务请求,其中,目标接口为第一平台的网关上的接口,目标接口用于接收请求第一平台提供业务服务的业务请求,目标业务请求用于为第二平台请求第一平台提供业务服务,业务设备为在第二平台中使用的设备;
利用由业务请求确定的信息对第二平台执行鉴权操作,其中,鉴权操作用于对第二平台的身份进行验证;
在对第二平台的鉴权操作通过的情况下,向第二平台提供与第二平台匹配的目标业务服务。
可选地,本实施例中的具体示例可以参考上述实施例中所描述的示例,本实施例在此不再赘述。
本领域普通技术人员可以理解,图5所示的结构仅为示意,终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices,MID)、PAD等终端设备。图5其并不对上述电子装置的结构造成限定。例如,终端还可包括比图5中所示更多或者更少的组件(如网络接口、显示装置等),或者具有与图5所示不同的配置。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成,该程序可以存储于一计算机可读存储介质中,存储介质可以包括:闪存盘、只读存储器(Read-Only Memory,ROM)、随机存取器(RandomAccess Memory,RAM)、磁盘或光盘等。
本申请的实施例还提供了一种存储介质。可选地,在本实施例中,上述存储介质可以用于执行业务服务的提供方法的程序代码。
可选地,在本实施例中,上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。
可选地,在本实施例中,存储介质被设置为存储用于执行以下步骤的程序代码:
通过目标接口获取业务设备发送的目标业务请求,其中,目标接口为第一平台的网关上的接口,目标接口用于接收请求第一平台提供业务服务的业务请求,目标业务请求用于为第二平台请求第一平台提供业务服务,业务设备为在第二平台中使用的设备;
利用由业务请求确定的信息对第二平台执行鉴权操作,其中,鉴权操作用于对第二平台的身份进行验证;
在对第二平台的鉴权操作通过的情况下,向第二平台提供与第二平台匹配的目标业务服务。
可选地,本实施例中的具体示例可以参考上述实施例中所描述的示例,本实施例在此不再赘述。
可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
上述本申请实施例序号仅仅为了描述,不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在上述计算机可读取的存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在存储介质中,包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。
在本申请的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的客户端,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
以上所述仅是本申请的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。