数据验证方法、数据处理方法及装置与流程

文档序号:30990857发布日期:2022-08-03 02:17阅读:278来源:国知局
数据验证方法、数据处理方法及装置与流程

1.本公开涉及数据传输技术领域,具体而言,涉及一种数据验证方法、数据处理方法及装置。


背景技术:

2.目前,为了轻松实现不同设备间的数据与应用的共享,公有云服务的使用越来越常见。在软件开发包与公有云进行接口调用时,为了保证数据传输时的安全性,公有云服务一般需要先对当前用户身份进行鉴权处理,确保用户有数据处理权限,同时为了加强鉴权内容不被篡改,还要引入签名机制进行检验。
3.然而相关技术中,一般是在用户鉴权通过之后用户端再发送验签数据,在这个过程中,验签数据可能会出现非法劫持的情况,进而受到篡改,影响数据的安全性。


技术实现要素:

4.本公开实施例至少提供一种数据验证方法、数据处理方法及装置。
5.第一方面,本公开实施例提供了一种数据验证方法,包括:
6.接收用户端发送的令牌信息和加密后的请求数据包,其中,所述令牌信息中包含签名信息和签名验证信息,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息,所述签名验证信息包含处理后的用户标识;所述签名信息基于所述用户端的软件开发包sdk生成;
7.基于所述签名验证信息、所述加密后的请求数据包对所述签名信息进行验签处理,以及基于所述用户标识进行鉴权处理。
8.通过这种方法,同时可以基于令牌信息进行验签和鉴权,安全性比较高,避免鉴权通过后数据包被劫持;同时,签名验证信息通过sdk生成,安全性较高。
9.一种可能的实施方式中,所述签名信息中还包括时间戳和所述用户端生成的随机数;
10.所述签名验证信息中还包括明文传输的所述时间戳和所述随机数;
11.其中,所述时间戳用于对所述令牌信息的有效性进行验证,所述随机数用于对所述用户端的唯一性进行验证。
12.通过这种方法,可以对数据的有效性和用户端的唯一性进行验证,提高了数据传输的安全性。
13.一种可能的实施方式中,所述签名信息为基于所述用户端的私钥生成;
14.所述基于所述签名验证信息、所述加密后的请求数据包对所述签名信息进行验签处理,包括:
15.基于所述私钥对应的公钥,对所述签名信息进行解密,确定解密后的用户标识和解密后的所述请求数据包的摘要信息;
16.对所述加密后的请求数据包进行解密,得到未加密的请求数据包;
17.基于所述未加密的请求数据包生成验证摘要信息,以及对所述签名验证信息中所包含的处理后的用户标识进行反处理,得到验证用户标识;
18.基于解密后的用户标识、所述验证用户标识、解密后的所述数据包的摘要信息以及所述验证摘要信息,对所述签名信息进行验签处理。
19.基于解密后的用户标识和验证用户标识,可以对数据来源进行验证,确保数据的发送方为用户端本身而非中间代理;基于解密后的数据包的摘要信息和验证摘要信息,可以对数据包的完整性进行验证,以确定数据包在传输过程中未被篡改。
20.一种可能的实施方式中,所述基于所述用户标识进行鉴权处理,包括:
21.确定所述请求数据包对应的请求类型;
22.基于所述用户标识,确定所述用户标识对应的用户对于所述请求类型的处理权限。
23.利用这种方式,可以对用户的处理权限进行验证,提高数据的安全性,避免非法用户对于数据的非法篡改。
24.一种可能的实施方式中,所述方法还包括:
25.在所述验签处理和所述鉴权处理通过之后,对所述请求数据包进行处理,并将所述处理结果发送至所述用户端。
26.第二方面,本公开实施例提供了一种数据处理方法,包括:
27.响应目标触发操作,生成与所述目标触发操作对应的请求数据包;
28.将所述请求数据包的摘要信息传输至用户端的软件开发包sdk,以通过用户端的软件开发包sdk,调用动态库中的签名生成方法,生成对应的签名信息,其中,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息;
29.对所述用户标识进行处理,并生成包含处理后的用户标识的签名验证信息;
30.基于所述签名验证信息和所述签名信息生成令牌信息,并对所述请求数据包进行加密处理;
31.将所述令牌信息和加密处理后的所述请求数据包发送至服务器,以进行验签处理和鉴权处理。
32.利用这种方法生成的令牌信息中,既包含了用于进行鉴权的用户标识,又可以进行验签处理,由此提高了数据的安全性。
33.一种可能的实施方式中,所述动态库中的签名生成方法被调用之后,通过以下方法生成所述签名信息:
34.从加密的授权文件中读取签名关键信息和鉴权关键信息,其中,所述签名关键信息包括生成签名信息时的私钥,所述鉴权关键信息包括用户标识;
35.获取所述请求数据包的摘要信息;
36.基于所述私钥对所述请求数据包的摘要信息和所述用户标识进行加密,得到所述签名信息。
37.这种方法中,签名信息的生成过程由动态库生成,降低了签名生成方法被破解的风险,提高了数据的安全性。
38.一种可能的实施方式中,所述用户端的软件开发包sdk为经过混淆处理后的sdk。
39.通过对sdk进行混淆处理,可以降低签名生成方法被破解的风险,提高了数据的安
全性。
40.第三方面,本公开实施例提供一种数据验证装置,包括:
41.接收模块,用于接收用户端发送的令牌信息和加密后的请求数据包,其中,所述令牌信息中包含签名信息和签名验证信息,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息,所述签名验证信息包含处理后的用户标识;所述签名信息基于所述用户端的软件开发包sdk生成;
42.验证模块,用于基于所述签名验证信息、所述加密后的请求数据包对所述签名信息进行验签处理,以及基于所述用户标识进行鉴权处理。
43.一种可能的实施方式中,所述签名信息中还包括时间戳和所述用户端生成的随机数;
44.所述签名验证信息中还包括明文传输的所述时间戳和所述随机数;
45.其中,所述时间戳用于对所述令牌信息的有效性进行验证,所述随机数用于对所述用户端的唯一性进行验证。
46.一种可能的实施方式中,所述签名信息为基于所述用户端的私钥生成;
47.所述验证模块,在基于所述签名验证信息、所述加密后的请求数据包对所述签名信息进行验签处理时,用于:
48.基于所述私钥对应的公钥,对所述签名信息进行解密,确定解密后的用户标识和解密后的所述请求数据包的摘要信息;
49.对所述加密后的请求数据包进行解密,得到未加密的请求数据包;
50.基于所述未加密的请求数据包生成验证摘要信息,以及对所述签名验证信息中所包含的处理后的用户标识进行反处理,得到验证用户标识;
51.基于解密后的用户标识、所述验证用户标识、解密后的所述数据包的摘要信息以及所述验证摘要信息,对所述签名信息进行验签处理。
52.一种可能的实施方式中,所述验证模块,在基于所述用户标识进行鉴权处理时,用于:
53.确定所述请求数据包对应的请求类型;
54.基于所述用户标识,确定所述用户标识对应的用户对于所述请求类型的处理权限。
55.一种可能的实施方式中,所述装置还包括发送模块,用于:
56.在所述验签处理和所述鉴权处理通过之后,对所述请求数据包进行处理,并将所述处理结果发送至所述用户端。
57.第四方面,本公开实施例提供一种数据处理装置,包括:
58.第一生成模块,用于响应目标触发操作,生成与所述目标触发操作对应的请求数据包;
59.签名模块,用于将所述请求数据包的摘要信息传输至用户端的软件开发包sdk,以通过用户端的软件开发包sdk,调用动态库中的签名生成方法,生成对应的签名信息,其中,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息;
60.第二生成模块,用于对所述用户标识进行处理,并生成包含处理后的用户标识的签名验证信息;
61.第三生成模块,用于基于所述签名验证信息和所述签名信息生成令牌信息,并对所述请求数据包进行加密处理;
62.发送模块,用于将所述令牌信息和加密处理后的所述请求数据包发送至服务器,以进行验签处理和鉴权处理。
63.一种可能的实施方式中,在动态库中的签名生成方法被调用之后,所述签名模块,通过以下方法生成所述签名信息:
64.从加密的授权文件中读取签名关键信息和鉴权关键信息,其中,所述签名关键信息包括生成签名信息时的私钥,所述鉴权关键信息包括用户标识;
65.获取所述请求数据包的摘要信息;
66.基于所述私钥对所述请求数据包的摘要信息和所述用户标识进行加密,得到所述签名信息。
67.一种可能的实施方式中,所述用户端的软件开发包sdk为经过混淆处理后的sdk。
68.第五方面,本公开实施例还提供一种计算机设备,包括:处理器、存储器和总线,所述存储器存储有所述处理器可执行的机器可读指令,当计算机设备运行时,所述处理器与所述存储器之间通过总线通信,所述机器可读指令被所述处理器执行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤,或执行上述第二方面,或第二方面中任一种可能的实施方式中的步骤。
69.第六方面,本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述第一方面,或第一方面中任一种可能的实施方式中的步骤,或执行上述第二方面,或第二方面中任一种可能的实施方式中的步骤。
70.关于上述数据验证、数据处理装置,计算机设备及计算机可读存储介质的效果描述参见上述数据验证、数据处理方法的说明,这里不再赘述。
71.为使本公开的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
72.为了更清楚地说明本公开实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,此处的附图被并入说明书中并构成本说明书中的一部分,这些附图示出了符合本公开的实施例,并与说明书一起用于说明本公开的技术方案。应当理解,以下附图仅示出了本公开的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
73.图1示出了本公开实施例所提供的一种数据验证方法的流程图;
74.图2示出了本公开实施例所提供的数据验证方法中,验签处理过程的流程图;
75.图3示出了本公开实施例所提供的另一种数据处理方法的流程图;
76.图4示出了本公开实施例所提供的数据处理方法中,数据流向的表示图;
77.图5示出了本公开实施例所提供的数据验证装置的架构示意图;
78.图6示出了本公开实施例所提供的数据处理装置的架构示意图;
79.图7示出了本公开实施例所提供的一种计算机设备700的结构示意图;
80.图8示出了本公开实施例所提供的一种计算机设备800的结构示意图。
具体实施方式
81.为使本公开实施例的目的、技术方案和优点更加清楚,下面将结合本公开实施例中附图,对本公开实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本公开一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本公开实施例的组件可以以各种不同的配置来布置和设计。因此,以下对在附图中提供的本公开的实施例的详细描述并非旨在限制要求保护的本公开的范围,而是仅仅表示本公开的选定实施例。基于本公开的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本公开保护的范围。
82.经研究发现,相关技术中,一方面,数据的鉴权与验签是分开进行的,容易出现在鉴权通过后,一些非法用户劫持相应请求数据包的情况,非法用户可以对劫持的请求数据包进行篡改或者通过伪造的请求数据包,以盗用公有云服务中的数据;另一方面,签名生成方法的一般存储在用户端的应用层,易于被破解,增加数据泄露的风险。
83.基于上述研究,本公开提供了一种数据验证方法、数据处理方法及装置,可以将签名生成方法存储在动态库中,在生成签名信息时,可以基于用户端中的软件开发包sdk调用的动态库生成,不易破解,安全性更高;且用户端在向服务器传输数据时,令牌信息包含了签名信息,而签名信息包含了用户标识,因此通过这样的方式可以基于令牌信息同时进行验签和鉴权处理,提高了数据传输的安全性。
84.针对以上方案所存在的缺陷,均是发明人在经过实践并仔细研究后得出的结果,因此,上述问题的发现过程以及下文中本公开针对上述问题所提出的解决方案,都应该是发明人在本公开过程中对本公开做出的贡献。
85.应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。
86.为便于对本实施例进行理解,首先对本公开实施例所公开的一种数据验证方法进行详细介绍,本公开实施例所提供的数据验证方法的执行主体一般为服务器。
87.参见图1所示,为本公开实施例提供的数据验证方法的流程图,所述方法包括步骤101~步骤102,其中:
88.步骤101、接收用户端发送的令牌信息和加密后的请求数据包。其中,所述令牌信息中包含签名信息和签名验证信息,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息,所述签名验证信息包含处理后的用户标识;所述签名信息基于所述用户端的软件开发包sdk生成。
89.步骤102、基于所述签名验证信息、所述加密后的请求数据包对所述签名信息进行验签处理,以及基于所述用户标识进行鉴权处理。
90.以下是针对上述步骤的详细说明:
91.一种可能的实施方式中,所述用户端发送的令牌信息和加密后的请求数据包都是携带在用户请求中的,所述用户端发送的令牌信息和加密后的请求数据包,可以是用户在用户端提交操作请求之后,用户端响应所述操作请求,生成的所述令牌信息和加密后的请求数据包。其中,所述操作请求可以是人脸识别、物品识别等。
92.所述请求数据包可以是基于用户端的请求生成的数据包,所述请求数据包中包含用户的请求数据;所述请求数据包的摘要信息可以是指所述请求数据包中的数据标识。
93.所述令牌信息token中包含签名信息以及签名验证信息,具体的,所述签名信息的生成过程和所述签名验证信息的生成过程具体介绍如下所示:
94.一、签名信息。
95.所述签名信息可以是基于用户端的开发软件包sdk生成的,具体的,签名生成方法用于生成签名信息,所述签名生成方法可以存储于动态库中,所述动态库可以是加密的动态库。在生成签名信息时,可以通过用户端的sdk调用动态库中的签名生成方法,以生成签名信息。
96.所述签名信息中包括签名后的用户标识和所述请求数据包的摘要信息,一种可选的实施方式中,所述签名信息中还可以包括时间戳和所述用户端生成的随机数。
97.其中,所述时间戳可以是用户端在接收到提交操作请求时基于当前的系统时间生成的,用于对所述令牌信息的有效性进行验证;所述随机数可以是在用户端生成的,用于对所述用户端的唯一性进行验证。
98.示例性的,在生成所述签名信息时,可以采用非对称加密的方式。具体的,可以先从服务器下发给用户端的软件协议license中读取加密的私钥,以及用户标识,然后基于私钥对用户标识、请求数据包的摘要信息、时间戳和随机数进行加密处理,得到所述签名信息。
99.这里,所述请求数据包的摘要信息可以是在用户端的应用层生成的,所述应用层在生成所述请求数据包的摘要信息之后,可以传输至sdk,sdk在调用动态库中的签名生成方法时,可以将请求数据包的摘要信息传输至动态库,然后签名生成方法可以获取所述请求数据包的摘要信息,以生成签名信息。
100.二、签名验证信息。
101.这里,所述签名验证信息用于对签名信息进行验证。所述签名验证信息包括处理后的用户标识、明文传输的时间戳和随机数。这里,由于签名验证信息在传输过程中不会经过任何处理,因此,为保证用户标识的安全性,签名验证信息中包含的用户标识为处理后的用户标识。
102.在sdk调用签名生成方法生成签名信息时,可以同步生成所述签名验证信息。
103.三、加密后的请求数据包。
104.这里,所述请求数据包的加密方法包括但不仅限于对称加密、分对称加密等。
105.进一步的,为了提高数据的安全,所述sdk可以是经过混淆处理的sdk。
106.通过这种方法,将签名生成方法存储在加密的动态库中,在生成签名信息时,再通过sdk调用加密的动态库中的签名生成方法,由此提高了签名生成方法的安全性,避免签名生成方法被破解;进一步的,由于签名生成方法安全性较高,因此仅能通过用户端生成,降低了非法代理的风险。
107.服务器在接收到令牌信息和加密后的请求数据包之后,可以同时进行鉴权处理和验签处理,具体如下:
108.验签处理:
109.一种可能的实施方式中,在基于所述签名验证信息、所述加密后的请求数据包对
所述签名信息进行验签处理时,示例性的,可以如图2所示,包括以下几个步骤:
110.步骤201、基于所述私钥对应的公钥,对所述签名信息进行解密,确定解密后的用户标识和解密后的所述请求数据包的摘要信息。
111.进一步的,在对签名信息进行解密之后,还可以包括解密后的时间戳和随机数。
112.步骤202、对所述加密后的请求数据包进行解密,得到未加密的请求数据包。
113.这里,在对所述加密后的请求数据包进行解密时,可以采取与所述请求数据包加密时对应的解密方法,例如若所述请求数据包在进行加密时采用的是对称加密,则在对所述加密后的请求数据包进行解密时,可以采用对称解密的方法进行解密。具体的加密解密方法可以是服务器与用户端预先约定好的。
114.步骤203、基于所述未加密的请求数据包生成验证摘要信息,以及对所述签名验证信息中所包含的处理后的用户标识进行反处理,得到验证用户标识。
115.步骤204、基于解密后的用户标识、所述验证用户标识、解密后的所述数据包的摘要信息以及所述验证摘要信息,对所述签名信息进行验签处理。
116.一种可能的实施方式中,所述对签名信息进行验签处理可以包括对有效性进行验证、对用户唯一性进行验证、对数据完整性进行验证的。
117.具体的,可以基于所述时间戳对所述令牌信息的有效性进行验证。例如,在对签名信息进行解密后,可以将解密后的时间戳与所述令牌信息中明文传输的时间戳进行比对,若二者一致,则说明所述令牌信息的有效性验证通过。
118.若所述解密后的时间戳与所述明文传输的时间戳不一致,则可以向用户端发送提示信息,以提示所述令牌信息无效。
119.利用这种方式,可以降低一些用户在数据传输的过程中,篡改请求数据包后伪造令牌信息,盗取信息的成功率。
120.一种可能的实施方式中,可以基于随机数对所述用户端的唯一性进行验证。具体的,在对所述签名信息进行解密后,可以将解密后的随机数与明文传输的随机数进行比对,若比对结果一致,则确定所述用户端的唯一性验证通过。
121.另一种可能的实施方式中,在基于随机数对所述用户端的唯一性进行验证时,若比对结果不一致,则可以向用户端发送提示信息,以提示所述用户端为非法用户。
122.在这种方式中,因为随机数是基于用户每次请求随机生成的数据,具有唯一性,所以可以有效避免一些非法用户利用自己伪造的请求数据包,盗取信息。
123.一种可能的实施方式中,在基于解密后的用户标识、所述验证用户标识、解密后的所述数据包的摘要信息以及所述验证摘要信息,对所述签名信息进行验签处理时,可以通过比对所述解密后的用户标识和所述验证用户标识,以及比对所述解密后的所述数据包的摘要信息和所述验证摘要信息是否一致,如果两项数据均一致,则确定验签通过。
124.另一种可能的实施方式中,若两项数据并未完全一致,则确定验签失败。
125.鉴权处理:
126.所述鉴权处理可以理解为对用户权限进行验证。一种可能的实施方式中,在基于所述用户标识进行鉴权处理时,可以先确定所述请求数据包对应的请求类型,再基于所述用户标识,确定所述用户标识对应的用户对于所述请求类型的处理权限。
127.示例性的,用户在所述用户端提交了“图像识别”的请求,所述请求数据包的请求
类型则为“图像识别”,基于所述用户标识对应查找当前用户是否具备“图像识别”请求的处理权限,若所述用户具备“图像识别”请求的处理权限,则确定通过权限验证;若所述用户不具备“图像识别”请求的处理权限,则确定权限验证失败。
128.这里,所述鉴权处理和所述验签处理可以是同时进行的,或者也可以是在验签通过之后再进行鉴权处理。所述鉴权处理所用的用户标识可以是所述签名信息解密后的用户标识,也可以是所述验证用户标识。
129.在一种可能的实施方式中,在所述验签处理和所述鉴权处理通过之后,对所述请求数据包进行处理,并将所述处理结果发送至所述用户端。
130.本公开实施例还提供了一种数据处理方法,参见图3所述,为本公开实施例提供了一种数据处理方法,该方法应用于终端设备,包含步骤301~步骤305,其中:
131.步骤301、响应目标触发操作,生成与所述目标触发操作对应的请求数据包。
132.一种可能的实施方式中,在生成与所述目标触发操作对应的请求数据包同时,还可以提取当前系统时间生成时间戳,以及基于随机数生成逻辑生成用以进行用户端验证的随机数。
133.步骤302、将所述请求数据包的摘要信息传输至用户端的软件开发包sdk,以通过用户端的软件开发包sdk,调用动态库中的签名生成方法,生成对应的签名信息。
134.其中,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息。
135.为了更好的防止一些非法用户通过对截取到的所述签名信息进行反编译处理,推理出其具体的生成逻辑,所以所述用户端的软件开发包sdk是经过混淆处理后的sdk。
136.示例性的,所述sdk中各部分逻辑的关键信息进行隐藏,再添加一些与所述逻辑不相关的信息时,可以体现为未处理前的原始数据如下:“merno=001,user=zhangming,pwd=abc123,check=6387”,进行处理后的数据变为“merno=001,user=******,pwd=******,check=******,time=******,address=******”。
137.当然,可能还会存在某些用户能够成功破解所述sdk中的核心逻辑,所以为了保证数据传输过程中更高的安全性,所述签名信息是通过所述软件开发包sdk调用的动态库中的签名生成方式生成的。
138.在一种可能的实施方式中,所述动态库中的签名生成方法被调用之后,生成对应的签名信息时,可以先从加密的授权文件license中读取签名关键信息(即上述私钥)和鉴权关键信息(即用户标识),再获取所述请求数据包的摘要信息,最后基于所述签名关键信息对所述请求数据包的摘要信息和所述用户标识进行加密,得到所述签名信息。具体的数据流向如图4所示。
139.步骤303、对所述用户标识进行处理,并生成包含处理后的用户标识的签名验证信息。
140.为了防止不良用户冒用当前用户身份进行信息盗取,所以需要对所述用户标识进行处理,示例性的,可以对所述用户标识中的关键信息进行提取并生成相应的识别信息,再基于所述相应的识别信息生成所述处理后的用户标识。
141.步骤304、基于所述签名验证信息和所述签名信息生成令牌信息,并对所述请求数据包进行加密处理。
142.示例性的,基于所述签名验证信息和所述签名信息生成令牌信息时,可以依次获
取所述签名验证信息和所述签名信息之后,将所述签名信息和所述签名验证信息进行拼接生成所述令牌信息。
143.这里,所述令牌信息为动态令牌,每次发送请求时所包含的令牌信息是不同的。
144.步骤305、将所述令牌信息和加密处理后的所述请求数据包发送至服务器,以进行验签处理和鉴权处理。
145.一种可能的实施方式中,在将所述令牌信息和加密处理后的所述请求数据包发送至服务器的同时,还要向所述服务器明文传输所述时间戳和所述随机数。
146.综上,上述方法中,所述签名信息中主要包括:
147.a1、请求数据包的摘要信息;a2、用户标识;a3、时间戳;a4、随机数。
148.所述签名验证信息中主要包括:
149.b1、处理后的用户标识;b2、明文传输的时间戳;b3、明文传输的随机数。
150.在进行验签处理的过程中,所用到的信息主要包括:
151.a1、请求数据包的摘要信息,c1、基于请求数据包重新生成的验证摘要信息;主要用于验证数据完整性;
152.a2、用户标识,c2、基于处理后的用户标识(b1)生成的验证用户标识;主要用于验证用户真实性;
153.a3、时间戳,b2、基于明文传输的时间戳;主要用于验证token的有效性;
154.a4、随机数,b3、明文传输的随机数;主要用于验证用户的唯一性。
155.在进行鉴权过程中,所用到的信息主要包括:
156.c2、基于处理后的用户标识(b1)生成的验证用户标识,或者a2、用户标识。
157.本领域技术人员可以理解,在具体实施方式的上述方法中,各步骤的撰写顺序并不意味着严格的执行顺序而对实施过程构成任何限定,各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
158.基于同一发明构思,本公开实施例中还提供了与数据验证、数据处理方法对应的数据验证、数据处理装置,由于本公开实施例中的装置解决问题的原理与本公开实施例上述数据验证、数据处理方法相似,因此装置的实施可以参见方法的实施,重复之处不再赘述。
159.参照图5所示,为本公开实施例提供的一种数据验证装置的架构示意图,所述装置包括:接收模块501、验证模块502、发送模块503;其中,
160.接收模块501,用于接收用户端发送的令牌信息和加密后的请求数据包,其中,所述令牌信息中包含签名信息和签名验证信息,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息,所述签名验证信息包含处理后的用户标识;所述签名信息基于所述用户端的软件开发包sdk生成;
161.验证模块502,用于基于所述签名验证信息、所述加密后的请求数据包对所述签名信息进行验签处理,以及基于所述用户标识进行鉴权处理。
162.一种可能的实施方式中,所述签名信息中还包括时间戳和所述用户端生成的随机数;
163.所述签名验证信息中还包括明文传输的所述时间戳和所述随机数;
164.其中,所述时间戳用于对所述令牌信息的有效性进行验证,所述随机数用于对所
述用户端的唯一性进行验证。
165.一种可能的实施方式中,所述签名信息为基于所述用户端的私钥生成;
166.所述验证模块502,在基于所述签名验证信息、所述加密后的请求数据包对所述签名信息进行验签处理时,用于:
167.基于所述私钥对应的公钥,对所述签名信息进行解密,确定解密后的用户标识和解密后的所述请求数据包的摘要信息;
168.对所述加密后的请求数据包进行解密,得到未加密的请求数据包;
169.基于所述未加密的请求数据包生成验证摘要信息,以及对所述签名验证信息中所包含的处理后的用户标识进行反处理,得到验证用户标识;
170.基于解密后的用户标识、所述验证用户标识、解密后的所述数据包的摘要信息以及所述验证摘要信息,对所述签名信息进行验签处理。
171.一种可能的实施方式中,所述验证模块502,在基于所述用户标识进行鉴权处理时,用于:
172.确定所述请求数据包对应的请求类型;
173.基于所述用户标识,确定所述用户标识对应的用户对于所述请求类型的处理权限。
174.一种可能的实施方式中,所述装置还包括发送模块503,用于:
175.在所述验签处理和所述鉴权处理通过之后,对所述请求数据包进行处理,并将所述处理结果发送至所述用户端。
176.参照图6所示,为本公开实施例提供的一种数据处理装置的架构示意图,所述装置包括:第一生成模块601、签名模块602、第二生成模块603、第三生成模块604、发送模块605;其中,
177.第一生成模块601,用于响应目标触发操作,生成与所述目标触发操作对应的请求数据包;
178.签名模块602,用于将所述请求数据包的摘要信息传输至用户端的软件开发包sdk,以通过用户端的软件开发包sdk,调用动态库中的签名生成方法,生成对应的签名信息,其中,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息;
179.第二生成模块603,用于对所述用户标识进行处理,并生成包含处理后的用户标识的签名验证信息;
180.第三生成模块604,用于基于所述签名验证信息和所述签名信息生成令牌信息,并对所述请求数据包进行加密处理;
181.发送模块605,用于将所述令牌信息和加密处理后的所述请求数据包发送至服务器,以进行验签处理和鉴权处理。
182.一种可能的实施方式中,在动态库中的签名生成方法被调用之后,所述签名模块602,用于通过以下方法生成所述签名信息:
183.从加密的授权文件中读取签名关键信息和鉴权关键信息,其中,所述签名关键信息包括生成签名信息时的私钥,所述鉴权关键信息包括用户标识;
184.获取所述请求数据包的摘要信息;
185.基于所述私钥对所述请求数据包的摘要信息和所述用户标识进行加密,得到所述
签名信息。
186.一种可能的实施方式中,所述用户端的软件开发包sdk为经过混淆处理后的sdk。
187.关于装置中的各模块的处理流程、以及各模块之间的交互流程的描述可以参照上述方法实施例中的相关说明,这里不再详述。
188.基于同一技术构思,本公开实施例提供了一种计算机设备。参照图7所示,为本公开实施例提供的计算机设备700的结构示意图,包括处理器701、存储器702、和总线703。其中,存储器702用于存储执行指令,包括内存7021和外部存储器7022;这里的内存7021也称内存储器,用于暂时存放处理器701中的运算数据,以及与硬盘等外部存储器7022交换的数据,处理器701通过内存7021与外部存储器7022进行数据交换,当计算机设备700运行时,处理器701与存储器702之间通过总线703通信,使得处理器701在执行以下指令:
189.接收用户端发送的令牌信息和加密后的请求数据包,其中,所述令牌信息中包含签名信息和签名验证信息,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息,所述签名验证信息包含处理后的用户标识;所述签名信息基于所述用户端的软件开发包sdk生成;
190.基于所述签名验证信息、所述加密后的请求数据包对所述签名信息进行验签处理,以及基于所述用户标识进行鉴权处理。
191.基于同一技术构思,本公开实施例还提供了另一种计算机设备。参照图8所示,为本公开实施例提供的计算机设备800的结构示意图,包括处理器801、存储器802、和总线803。其中,存储器802用于存储执行指令,包括内存8021和外部存储器8022;这里的内存8021也称内存储器,用于暂时存放处理器801中的运算数据,以及与硬盘等外部存储器8022交换的数据,处理器801通过内存8021与外部存储器8022进行数据交换,当计算机设备800运行时,处理器801与存储器802之间通过总线803通信,使得处理器801在执行以下指令:
192.响应目标触发操作,生成与所述目标触发操作对应的请求数据包;
193.将所述请求数据包的摘要信息传输至用户端的软件开发包sdk,以通过用户端的软件开发包sdk,调用动态库中的签名生成方法,生成对应的签名信息,其中,所述签名信息中包含签名后的用户标识和所述请求数据包的摘要信息;
194.对所述用户标识进行处理,并生成包含处理后的用户标识的签名验证信息;
195.基于所述签名验证信息和所述签名信息生成令牌信息,并对所述请求数据包进行加密处理;
196.将所述令牌信息和加密处理后的所述请求数据包发送至服务器,以进行验签处理和鉴权处理。
197.本公开实施例还提供一种计算机可读存储介质,该计算机可读存储介质上存储有计算机程序,该计算机程序被处理器运行时执行上述方法实施例中所述的数据验证、数据处理方法的步骤。其中,该存储介质可以是易失性或非易失的计算机可读取存储介质。
198.本公开实施例还提供一种计算机程序产品,该计算机产品承载有程序代码,所述程序代码包括的指令可用于执行上述方法实施例中所述的数据验证、数据处理方法的步骤,具体可参见上述方法实施例,在此不再赘述。
199.其中,上述计算机程序产品可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中,所述计算机程序产品具体体现为计算机存储介质,在另一个可选实施例中,
计算机程序产品具体体现为软件产品,例如软件开发包(software development kit,sdk)等等。
200.所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统和装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。在本公开所提供的几个实施例中,应该理解到,所揭露的系统、装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
201.所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
202.另外,在本公开各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
203.所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本公开的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本公开各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(read-only memory,rom)、随机存取存储器(random access memory,ram)、磁碟或者光盘等各种可以存储程序代码的介质。
204.最后应说明的是:以上所述实施例,仅为本公开的具体实施方式,用以说明本公开的技术方案,而非对其限制,本公开的保护范围并不局限于此,尽管参照前述实施例对本公开进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本公开揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本公开实施例技术方案的精神和范围,都应涵盖在本公开的保护范围之内。因此,本公开的保护范围应所述以权利要求的保护范围为准。
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1