一种基于混合模式移动应用的接口请求管理方法及装置与流程

1.本发明涉及互联网技术领域，更具体地说，涉及一种基于混合模式移动应用的接口请求管理方法及装置。


背景技术：

2.hybrid app为混合模式移动应用，是指介于h5 app(html5 app，网页应用)与native app(原生应用)这两者之间的app(application，应用)。混合模式移动应用虽然看上去是一个原生应用，但里面有至少一个ui webview(用户界面网络视图组件)，可以访问网页应用或者原生页面。网页应用在发起请求时，由于网页应用的代码可被外部获取及进行反混淆，因此网页应用的接口加签规则容易暴露，安全性较差，而原生应用具有封闭式特点，相对安全。目前混合模式移动应用在发起请求时，存在如下两种方式：
3.1、全部的接口请求均由app端(原生端)发起，h5端(网页端)通过调用app端提供的方法向接口发起请。该方式虽然安全，但是，由于h5端和app端耦合严重，只能在app内进行调试，大大增加了开发以及维护的成本。
4.2、全部由h5端自己向接口发起请求。该方式耦合度低，开发以及维护成本低，但是对于一些涉及资金类的业务，安全性就得不到保障。
5.因此，如何降低h5端和app端的耦合程度，提高数据传输的安全性，是本领域技术人员需要解决的问题。


技术实现要素：

6.本发明的目的在于提供一种基于混合模式移动应用的接口请求管理方法及装置，以在降低h5端和app端耦合程度的基础上，提高数据传输的安全性。
7.为实现上述目的，本发明提供的一种基于混合模式移动应用的接口请求管理方法，所述混合模式移动应用具有网页端及原生端；所述接口请求管理方法包括：
8.网页端在发送接口请求前，确定目标接口的接口类型；所述接口类型为服务器端根据各接口的安全需求设置的；
9.若所述接口类型为网页验签接口，则通过网页验签方式生成第一签名，并结合所述第一签名向所述服务器端的目标端口发送接口请求；
10.若所述接口类型为原生验签接口，则通过所述原生端的原生验签方式生成第二签名，并结合所述第二签名向所述服务器端的目标端口发送接口请求。
11.其中，本方案还包括：
12.若所述接口类型为不验签接口，则直接向所述目标端口发送不携带签名的接口请求。
13.其中，所述通过网页验签方式生成第一签名包括：
14.根据所述网页端的请求头属性信息及接口参数信息生成第一字符串；
15.将所述第一字符串与所述网页端的密钥组合，并加密后生成第一签名。
16.其中，所述通过所述原生端的原生验签方式生成第二签名，包括：
17.根据所述原生端的请求头属性信息及接口参数信息生成第二字符串；
18.将所述第二字符串与所述原生端的密钥组合，并加密后生成第二签名。
19.其中，所述网页端在发送接口请求之前，还包括：
20.所述服务器端确定各个接口的安全需求；
21.根据各个接口的安全需求确定对应的接口类型；其中，与低安全需求的接口对应的接口类型为不验签接口，与中安全需求的接口对应的接口类型为网页验签接口，与高安全需求的接口对应的接口类型为原生验签接口。
22.其中，本方案还包括：
23.所述服务器端接收接口请求；
24.判断与所述接口请求对应的接口类型是否为不验签接口；若是，则直接响应所述接口请求；若否，则对所述接口请求中的header数据进行验证；
25.若验证失败，则请求失败；若验证成功，则判断与所述接口请求对应的接口类型为网页验签接口还是原生验签接口；
26.若为网页验签接口，则通过网页验签方式对所述接口请求中携带的签名进行验证；若验证成功，则响应所述接口请求；若验证失败，则请求失败；
27.若为原生验签接口，则通过原生验签方式对所述接口请求中携带的签名进行验证；若验证成功，则响应所述接口请求；若验证失败，则请求失败。
28.为实现上述目的，本发明进一步提供一种基于混合模式移动应用的接口请求管理装置，所述混合模式移动应用具有网页端及原生端；所述接口请求管理装置包括：
29.第一确定模块，用于在网页端发送接口请求前，确定目标接口的接口类型；所述接口类型为服务器端根据各接口的安全需求设置的；
30.第一生成模块，用于在所述接口类型为网页验签接口时，通过网页验签方式生成第一签名；
31.第一发送模块，用于结合所述第一签名向所述服务器端的目标端口发送接口请求；
32.第二生成模块，用于在所述接口类型为原生验签接口时，通过所述原生端的原生验签方式生成第二签名；
33.第二发送模块，用于结合所述第二签名向所述服务器端的目标端口发送接口请求。
34.其中，本装置还包括：
35.第三发送模块，用于在所述接口类型为不验签接口时，直接向所述目标端口发送不携带签名的接口请求。
36.其中，所述第一生成模块包括：
37.第一字符串生成单元，用于根据所述网页端的请求头属性信息及接口参数信息生成第一字符串；
38.第一签名生成单元，用于将所述第一字符串与所述网页端的密钥组合，并加密后生成第一签名。
39.其中，所述第二生成模块，包括：
40.第二字符串生成单元，用于根据所述原生端的请求头属性信息及接口参数信息生成第二字符串；
41.第二签名生成单元，用于将所述第二字符串与所述原生端的密钥组合，并加密后生成第二签名。
42.通过以上方案可知，本发明实施例提供了一种基于混合模式移动应用的接口请求管理方法及装置；在本方案中，服务器端会根据各接口的安全需求设置各接口的接口类型；因此网页端在发送接口请求前，首先需要确定目标接口的接口类型；若接口类型为网页验签接口，则通过网页验签方式生成第一签名，并结合第一签名向服务器端的目标端口发送接口请求；若接口类型为原生验签接口，则通过原生端的原生验签方式生成第二签名，并结合第二签名向服务器端的目标端口发送接口请求。也即：本方案可根据接口安全需求设置接口类型，网页端会根据接口类型的不同选择不同的验签方式来发送接口请求，通过该方式，即可降低网页端及原生端的耦合程度，又可提高数据传输的安全性。
附图说明
43.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
44.图1为本发明实施例公开的一种基于混合模式移动应用的接口请求管理方法流程示意图；
45.图2为本发明实施例公开的一种基于服务器端的接口请求处理流程示意图；
46.图3为本发明实施例公开的一种基于混合模式移动应用的接口请求管理装置结构示意图；
47.图4为本发明实施例公开的一种电子设备结构示意图。
具体实施方式
48.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
49.本发明实施例公开了一种基于混合模式移动应用的接口请求管理方法及装置，以在降低h5端和app端耦合程度的基础上，提高数据传输的安全性。
50.参见图1，本发明实施例提供的一种基于混合模式移动应用的接口请求管理方法流程示意图，该混合模式移动应用具有网页端及原生端；接口请求管理方法包括：
51.s101、网页端在发送接口请求前，确定目标接口的接口类型；该接口类型为服务器端根据各接口的安全需求设置的；
52.若接口类型为网页验签接口，则执行s102；若接口类型为原生验签接口，则执行s103；若接口类型为不验签接口，则执行s104；
53.具体来说，本实施例中的混合模式移动应用即为hybrid app，是运行在客户端中
的应用，该混合模式移动应用中的网页端即为h5端或者web端，在本实施例中以h5端为例进行说明，本实施例中的原生端为app端。并且，hybrid app中的app端仍然走app验签，并不发生变化，走app验签即为：通过原生验签方式生成签名后向服务器端的端口发送接口请求。
54.在本实施例中，服务器端需要预先确定各个接口的接口类型，该过程具体可以为：服务器端确定各个接口的安全需求，根据各个接口的安全需求确定对应的接口类型；其中，与低安全需求的接口对应的接口类型为不验签接口，与中安全需求的接口对应的接口类型为网页验签接口，与高安全需求的接口对应的接口类型为原生验签接口。也即，本实施例根据接口的安全性需求分为以下三类：a:unlimitannotation api(不验签接口)；b：insecurityannotation api(h5网页验签接口)；c：securityannotation api(app原生验签接口)。因此，在本实施例中，网页端在向目标接口发送接口请求前，首先需要确定目标接口的接口类型，如果该接口未定义类型，则默认为app验签接口。
55.s102、通过网页验签方式生成第一签名，并结合第一签名向服务器端的目标端口发送接口请求；
56.s103、通过原生端的原生验签方式生成第二签名，并结合第二签名向服务器端的目标端口发送接口请求；
57.s104、直接向目标端口发送不携带签名的接口请求。
58.在本实施例中，若接口类型为网页验签接口，则h5端需要走h5验签，生成第一签名后发起请求，而对接口安全需求校高的小部分接口，则h5端需要走app验签的方式，该过程具体为：h5端通过与app端通信的方式拿到验签后的第二签名，再发起接口请求。若接口类型为不验签接口，则直接发送请求；在本实施例中，该接口请求可以为post/get请求。
59.在本实施例中，通过网页验签方式生成第一签名包括：根据网页端的请求头属性信息及接口参数信息生成第一字符串；将第一字符串与网页端的密钥组合，并加密后生成第一签名。相应的，通过原生端的原生验签方式生成第二签名，包括：根据原生端的请求头属性信息及接口参数信息生成第二字符串；将第二字符串与原生端的密钥组合，并加密后生成第二签名。可见，本方案通过网页验签方式及原生验签方式生成签名的过程，只有使用的数据不同，其处理逻辑大致相同，该过程具体包括如下步骤：
60.步骤1：不同平台(h5/app)定义各自的必传或选传请求头属性；如：plat for；
61.步骤2：将步骤1定义的请求头属性组合成“参数＝参数值”的格式，并且把这些参数用&字符连接起来，生成字符串header；
62.步骤3：将接口参数同样按照步骤2的规则生成字符串param；
63.步骤4：每个平台定义各自的密钥key；该key为服务器端设置的；
64.步骤5：每个平台以header、param、key组合并md5加密后生成签名sign。
65.进一步，在本实施例中，将接口请求发送至服务器端后，服务器端需要根据接口类型对接口请求中的header数据及签名进行验证，只有验证成功后才能响应接口请求，处理相关业务。参见图2，为本发明实施例提供的一种基于服务器端的接口请求处理流程示意图，包括如下步骤：
66.s201、服务器端接收接口请求；
67.s202、判断与接口请求对应的接口类型是否为不验签接口；
68.若是，则响应该接口请求；若否，则执行s203；
69.s203、对接口请求中的header数据进行验证；
70.若验证失败，则请求失败；若验证成功，则执行s204；
71.s204、判断与该接口请求对应的接口类型为网页验签接口还是原生验签接口；若接口类型为网页验签接口，则执行s205；若接口类型为原生验签接口，则执行s206；
72.s205、通过网页验签方式对接口请求中携带的签名进行验证；若验证成功，则响应该接口请求；若验证失败，则请求失败；
73.s206、通过原生验签方式对接口请求中携带的签名进行验证；若验证成功，则响应该接口请求；若验证失败，则请求失败。
74.也就是说，客户端中的混合模式移动应用发起post/get请求后，服务器端首先判断接口是否为unlimitannotation注解，如果是unlimitannotation注解，则直接响应接口请求，处理业务。如果不是unlimitannotation注解，则获取请求的header数据，不同平台验证不同header数据的必填值组合；若验证不通过，则接口请求失败；若验证通过，则获取接口参数，如key值等，并判断是否有insecurityannotation注解，如果有insecurityannotation注解，则走h5验签对请求中的签名进行验证，如果没有insecurityannotation注解，则走app验签对请求中的签名进行验证。判断是否对签名验证通过，如果验证不通过，则接口请求失败，如果验证通过，处理登录态，执行业务。并且，本实施例在执行上述过程时，可以生成相关日志，该日志可以记录接口请求的处理过程，从而了解请求失败的原因等等。
75.综上可见，在本方案中，可根据接口安全需求设置接口类型，网页端会根据接口类型的不同选择不同的验签方式来发送接口请求，通过该方式，即可降低网页端及原生端的耦合程度，又可提高数据传输的安全性，打造一个相对安全的接口环境，但是不会导致过多的其他成本。
76.下面对本发明实施例提供的管理装置、设备及介质进行介绍，下文描述的管理装置、设备及介质与上文描述的管理方法可以相互参照。
77.参见图3，本发明实施例提供的一种基于混合模式移动应用的接口请求管理装置结构示意图，所述混合模式移动应用具有网页端及原生端；所述接口请求管理装置包括：
78.第一确定模块11，用于在网页端发送接口请求前，确定目标接口的接口类型；所述接口类型为服务器端根据各接口的安全需求设置的；
79.第一生成模块12，用于在所述接口类型为网页验签接口时，通过网页验签方式生成第一签名；
80.第一发送模块13，用于结合所述第一签名向所述服务器端的目标端口发送接口请求；
81.第二生成模块14，用于在所述接口类型为原生验签接口时，通过所述原生端的原生验签方式生成第二签名；
82.第二发送模块15，用于结合所述第二签名向所述服务器端的目标端口发送接口请求。
83.其中，所述装置还包括：
84.第三发送模块，用于在所述接口类型为不验签接口时，直接向所述目标端口发送不携带签名的接口请求。
85.其中，所述第一生成模块包括：
86.第一字符串生成单元，用于根据所述网页端的请求头属性信息及接口参数信息生成第一字符串；
87.第一签名生成单元，用于将所述第一字符串与所述网页端的密钥组合，并加密后生成第一签名。
88.其中，所述第二生成模块，包括：
89.第二字符串生成单元，用于根据所述原生端的请求头属性信息及接口参数信息生成第二字符串；
90.第二签名生成单元，用于将所述第二字符串与所述原生端的密钥组合，并加密后生成第二签名。
91.其中，所述装置还包括：
92.第二确定模块，用于通过所述服务器端确定各个接口的安全需求；
93.第三确定模块，用于根据各个接口的安全需求确定对应的接口类型；其中，与低安全需求的接口对应的接口类型为不验签接口，与中安全需求的接口对应的接口类型为网页验签接口，与高安全需求的接口对应的接口类型为原生验签接口。
94.其中，所述装置还包括：
95.接收模块，用于通过所述服务器端接收接口请求；
96.第一判断模块，用于判断与所述接口请求对应的接口类型是否为不验签接口；若是，则触发响应模块；若否，则触发第一验证模块；
97.所述响应模块，用于响应所述接口请求；
98.第一验证模块，用于对所述接口请求中的header数据进行验证；若验证失败，则请求失败；若验证成功，则触发第二判断模块；
99.第二判断模块，用于判断与所述接口请求对应的接口类型为网页验签接口还是原生验签接口；
100.第二验证模块，用于在接口类型为网页验签接口时，通过网页验签方式对所述接口请求中携带的签名进行验证；若验证成功，则触发所述响应模块；若验证失败，则请求失败；
101.第三验证模块，用于在接口类型为为原生验签接口时，通过原生验签方式对所述接口请求中携带的签名进行验证；若验证成功，则触发所述响应模块；若验证失败，则请求失败。
102.参见图4，本发明实施例还公开了一种电子设备结构示意图，包括：
103.存储器21，用于存储计算机程序；
104.处理器22，用于执行所述计算机程序时实现上述任意方法实施例所述的基于混合模式移动应用的接口请求管理方法的步骤。
105.在本实施例中，设备可以是pc(personal computer，个人电脑)，也可以是智能手机、平板电脑、掌上电脑、便携计算机等终端设备。
106.该设备可以包括存储器21、处理器22和总线23。
107.其中，存储器21至少包括一种类型的可读存储介质，所述可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，sd或dx存储器等)、磁性存储器、磁盘、光盘等。存储器21
在一些实施例中可以是设备的内部存储单元，例如该设备的硬盘。存储器21在另一些实施例中也可以是设备的外部存储设备，例如设备上配备的插接式硬盘，智能存储卡(smart media card,smc)，安全数字(secure digital,sd)卡，闪存卡(flash card)等。进一步地，存储器21还可以既包括设备的内部存储单元也包括外部存储设备。存储器21不仅可以用于存储安装于设备的应用软件及各类数据，例如执行管理方法的程序代码等，还可以用于暂时地存储已经输出或者将要输出的数据。
108.处理器22在一些实施例中可以是一中央处理器(central processing unit,cpu)、控制器、微控制器、微处理器或其他数据处理芯片，用于运行存储器21中存储的程序代码或处理数据，例如执行管理方法的程序代码等。
109.该总线23可以是外设部件互连标准(peripheral component interconnect，简称pci)总线或扩展工业标准结构(extended industry standard architecture，简称eisa)总线等。该总线可以分为地址总线、数据总线、控制总线等。为便于表示，图4中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
110.进一步地，设备还可以包括网络接口24，网络接口24可选的可以包括有线接口和/或无线接口(如wi
‑
fi接口、蓝牙接口等)，通常用于在该设备与其他电子设备之间建立通信连接。
111.可选地，该设备还可以包括用户接口25，用户接口25可以包括显示器(display)、输入单元比如键盘(keyboard)，可选的用户接口25还可以包括标准的有线接口、无线接口。可选地，在一些实施例中，显示器可以是led显示器、液晶显示器、触控式液晶显示器以及oled(organic light
‑
emitting diode，有机发光二极管)触摸器等。其中，显示器也可以适当的称为显示屏或显示单元，用于显示在设备中处理的信息以及用于显示可视化的用户界面。
112.图4仅示出了具有组件21
‑
25的设备，本领域技术人员可以理解的是，图4示出的结构并不构成对设备的限定，可以包括比图示更少或者更多的部件，或者组合某些部件，或者不同的部件布置。
113.本发明实施例还公开了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意方法实施例所述的基于混合模式移动应用的接口请求管理方法的步骤。
114.其中，该存储介质可以包括：u盘、移动硬盘、只读存储器(read
‑
only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
115.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。
116.对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。