CN108052842A - 签名数据的存储、验证方法及装置 - Google Patents

Abstract

本申请公开了一种签名数据的存储、验证方法及装置，涉及计算机技术领域，解决了相关技术中签名数据在发送至后端存储过程中的安全性问题。所述方法包括：获取用户输入的签名数据，所述签名数据包括签名业务数据以及签名行为数据；在将所述签名数据从前端发送至后端的过程中，从所述签名数据中提取出涉及用户签名操作的签名行为数据；将所述签名行为数据存储至预先构建的数据访问中间件中，进一步用户发送的验证请求从数据访问中间件中获取签名行为数据，将所述签名行为数据与后端存储的签名业务数据进行匹配验证，如果匹配成功，则验证签名通过。本申请适用于签名数据的存储以及验证。

Description

签名数据的存储、验证方法及装置

技术领域

本发明涉及计算机技术领域，尤其是涉及到签名数据的存储、验证方法及装置。

背景技术

随着信息时代的进步和发展，移动终端作为日常生活和商业事务的工具也得到了迅速普及，在用户的生活中占有重要位置。为了配合人们日益丰富的使用需求，为移动终端提供各种功能的应用程序正在持续开发中，而基于移动终端上的平台也在不断更新换代。

通常情况下，为了保证移动终端上应用程序使用的安全性，需要对应用程序进行数字签名，数字签名是一段只有信息的发送者才能生成而别人无法伪造的数字串，通过对签名数据进行验证可以确定应用程序的作者和应用程序之间是否存在信任关系，进一步保证应用程序使用者的安全性。

由于不同的平台***对应用程序运行的要求不尽相同，现有技术通常是每个领域采用专业的开发团队，用该领域特有的编程语言和编程工具进行单独开发，在前端完成用户的签名过程，将签名数据发送至后端存储，以便于在后端完成签名数据的验证。然而，不同的开发团队使得前端与后端的开发很难保证一致性，导致后期的调试与迭代存在很多不便，另外，用户在前端进行电子签名的过程中，浏览器也没可能会存在多次页面跳转，页面跳转会生成额外的数据请求，使得发送至后端存储的签名数据携带有不安全的信息，无法保证签名数据的安全性。

发明内容

本发明实施例提供了签名数据的存储、验证方法及装置，解决了相关技术中签名数据在发送至后端存储过程中的安全性问题。

根据本发明实施例的一个方面，提供一种签名数据的存储方法，包括：获取用户输入的签名数据，所述签名数据包括签名业务数据以及签名行为数据；在将所述签名数据从前端发送至后端的过程中，从所述签名数据中提取出涉及用户签名操作的签名行为数据；将所述签名行为数据存储至预先构建的数据访问中间件中。

进一步地，所述从所述签名数据中提取出涉及用户签名操作的签名行为数据包括：遍历所述签名数据的各个参数，从所述各个参数中提取出涉及用户签名操作的参数；根据所述涉及用户签名操作的参数，从所述签名数据中提取出签名行为数据。

进一步地，在所述获取用户输入的签名数据之前，所述方法还包括：利用预先确定的单页面应用框架，在前端构建单页面应用。

进一步地，在所述将所述签名行为数据存储至预先构建的数据访问中间件中之后，所述方法还包括：将所述签名数据中的签名业务数据存储至后端。

根据本发明实施例的另一方面，提供一种签名数据的验证方法，包括：根据用户发送的验证请求从所述的数据访问中间件中获取签名行为数据；将所述签名行为数据与后端存储的签名业务数据进行匹配验证；如果匹配成功，则验证签名通过，否则验证签名失败。

进一步地，所述将所述签名行为数据与后端存储的签名业务数据进行匹配验证包括：获取所述签名行为数据中的各个参数对应的属性值；通过解析所述签名业务数据，得到所述签名业务数据中涉及用户签名操作的属性信息；将所述签名业务数据中涉及用户签名操作的属性信息与所述签名行为数据中各个参数对应的属性值进行匹配验证。

进一步地于，在所述如果匹配成功，则验证签名通过之后，所述方法还包括：将匹配验证成功的签名数据通过预先构建的数据访问中间件处理后发送至前端显示。

根据本发明实施例的又一方面，提供一种签名数据的存储装置，包括：获取单元，用于获取用户输入的签名数据，所述签名数据包括签名业务数据以及签名行为数据；提取单元，用于在将所述签名数据从前端发送至后端的过程中，从所述签名数据中提取出涉及用户签名操作的签名行为数据；第一存储单元，用于将所述签名行为数据存储至预先构建的数据访问中间件中。

进一步地，所述提取单元包括：第一提取模块，用于遍历所述签名数据的各个参数，从所述各个参数中提取出涉及用户签名操作的参数；第二提取模块，用于根据所述涉及用户签名操作的参数，从所述签名数据中提取出签名行为数据。

进一步地，所述装置还包括：构建单元，用于利用预先确定的单页面应用框架，在前端构建单页面应用。

进一步地，所述装置还包括：第二存储单元，用于将所述签名数据中的签名业务数据存储至后端。

根据本发明实施例的再一方面，提供一种签名数据的验证装置，包括：获取单元，用于根据用户发送的验证请求从所述的数据访问中间件中获取签名行为数据；匹配单元，用于将所述签名行为数据与后端存储的签名业务数据进行匹配验证；第一验证单元，用于如果匹配成功，则验证签名通过；第二验证单元，用于如果匹配不成功，则验证签名失败。

进一步地，所述匹配单元包括：获取模块，用于获取所述签名行为数据中的各个参数对应的属性值；解析模块，用于通过解析所述签名业务数据，得到所述签名业务数据中涉及用户签名操作的属性信息；匹配模块，拥有过将所述签名业务数据中涉及用户签名操作的属性信息与所述签名行为数据中各个参数对应的属性值进行匹配验证。

进一步地，所述装置还包括：显示单元，用于将匹配验证成功的签名数据通过预先构建的数据访问中间件处理后发送至前端显示。

通过本发明，在将签名数据从前端发送至后端的过程中，前端并非直接将签名数据发送到后端，而是从签名数据中提取出涉及用户签名操作的签名行为数据，并将签名行为数据存储至预先构建的数据访问中间件中，通过数据访问中间件实现前端与后端的数据分离，降低了前端与后端的耦合程度，避免了后期调试和迭代存在的不便。与现有技术中处理过程复杂繁重的签名数据的存储方法相比，本发明实施例将整个签名数据的存储过程中将签名数据中签名行为数据与签名业务数据进行分开存储，在前端页面请求签名验证时，并非直接在后端对签名数据进行验证，而是通过用户发送的验证请求从数据访问中间件中获取签名行为数据，由于签名行为数据中可能记录有用户具体签名时的行为属性信息，通过将用户签名行为数据与后端存储的签名业务数据进行匹配验证，进一步保证了签名数据的安全性。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的签名数据的存储方法的流程图一；

图2是根据本发明实施例的签名数据的存储方法的流程图二；

图3是根据本发明实施例的签名数据的验证方法的流程图；

图4是根据本发明实施例的签名数据的存储装置的结构框图一；

图5是根据本发明实施例的签名数据的存储装置的结构框图二；

图6是根据本发明实施例的签名数据的验证装置的结构框图一；

图7是根据本发明实施例的签名数据的验证装置的结构框图二。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

在本实施例中提供了一种签名数据的存储、验证方法，图1是根据本发明实施例的签名数据的存储、验证方法的流程图一，如图1所示，该流程包括如下步骤：

步骤S101，获取用户输入的签名数据；

在安卓***中，为了保证应用程序使用者的安全性，所有的应用程序需要经过数字签名才能安装。通过数字签名来识别应用程序发布者的身份，并建立应用程序之间的信任关系，确保应用程序的完整性。例如，用户在编译完成apk文件后，需要对apk文件进行签名，具体的签名过程可以使用命令生成数字证书，使用数字证书对apk文件进行签名，最后对签名后的apk文件进行优化，提高与***交互的效率。

其中，用户输入的签名数据包括签名行为数据以及签名业务数据，签名行为数据是用户签名操作行为所生成的数据，如签名操作的时间长短、签名操作的日期、签名操作的位置等等，签名业务数据是用户签名的具体内容，如签名的密钥、签名的图片等等，本发明实施例对签名行为数据以及签名业务数据的具体内容不进行限定。

对于本发明实施例，签名数据通过在数据单元上附加一些数据，或是对数据单元所作的密码变换，这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据，防止被他人伪造，或者用别人名义发送信息，提高了应用数据的安全性。

步骤S102，在将所述签名数据从前端发送至后端的过程中，从所述签名数据中提取出涉及用户签名操作的签名行为数据；

需要说明的是，签名数据需要发送至后端进行处理并存储，如果恶意程序改变了应用程序的apk文件，那么在进行apk安装校验时，改变后的信息与签名数据中记录的校验信息不同，应用程序变不能安装成功。

对于本发明实施例，在将签名数据从前端发送至后端的过程中，如果直接将签名数据发送到后端，将签名行为数据与签名业务数据都存储在后端，需要极大地成本来控制数据和优化漏洞，造成维护困难等问题。本发明实施例通过从签名数据中提取出涉及用户签名操作的签名行为数据，将签名行为数据过滤出来，实现签名数据的分离，降低了后端对签名数据维护的成本。

步骤S103，将所述签名行为数据存储至预先构建的数据访问中间件中。

其中，数据访问中间件作为一个中间桥梁，在前端与后端进行签名数据的传输过程中，为应用程序提供数据支撑。

具体应用数据库中间件存储签名数据的过程可以为：在接收到前端的签名数据后，经过做一些简单的数据处理，本发明实施例是提取签名数据中的签名行为数据，并将签名行为数据存储至数据访问中间件中。

需要说明的是，本发明实施例对构造数据访问中间件的方法不进行限定，具体可以使用JSP技术，也可以使用JDBC技术，具体可以根据实际应用场景进行选取合适的数据访问中间件。

本发明实施例提供的一种签名数据的存储方法，在将签名数据从前端发送至后端的过程中，前端并非直接将签名数据发送到后端，而是从签名数据中提取出涉及用户签名操作的签名行为数据，并将签名行为数据存储至预先构建的数据访问中间件中，通过数据访问中间件实现前端与后端的数据分离，降低了前端与后端的耦合程度，避免了后期调试和迭代存在的不便。与现有技术中将所有签名数据存储至后端的签名数据的存储方法相比，本发明实施例将签名数据中签名行为数据与签名业务数据进行分开存储，由于数据访问中间件处于操作***软件与用户的应用软件的中间，可以灵活高效的存储数据，通过数据访问中间件仍能可以实现前端与后端信息交互，进一步保证了签名数据的安全性。

图2是根据本发明实施例的签名数据的存储、验证方法的流程图二，如图2所示，该流程包括如下步骤：

步骤S201，利用预先确定的单页面应用框架，在前端构建单页面应用；

其中，单页面应用指的是在一个页面上集成多种功能，甚至整个***只有一个页面，所有业务功能都是它的子模块，通过特定的方式挂接到主界面上。

上述单页面应用框架可以为AngularJS、backbone、Avalon等等。不同的单页面应用框架中封装有不同的UI组件，具体根据页面需求选择合适的UI组件，当后端数据建模完成数据库搭建后，后端提供相应的异步接口，前端按照页面需求构建单页面应用。例如，当单页面应用框架为AngularJS时，利用Angular进行核心程序开发，Ionic进行移动端核心应用程序开发，Electron封装Angular核心以实现桌面端访问，cordova封装Ionic核心以实现移动端访问。

由于页面跳转会生成额外的数据请求，可能导致发送至后端的签名数据携带有不安全信息，无法保证签名数据的安全性，对于本发明实施例，利用预先确定的单页面应用框架，在前端构建单页面应用，实现无页面跳转，在保证签名数据安全性的同时，使得用户在网页端可以获得原生应用一般的体验，提高了用户的web体验。

步骤S202，获取用户输入的签名数据；

在使用应用程序的过程中，会经常与第三方应用程序进行交互，比如支付宝、微信等应用程序，为了防止应用程序的使用安全，通常会对应用程序添加数字签名来识别用户，这里的数字签名是一个根据某些数据(被签名数据)和实体(人、公司等)的秘钥计算出来的字符串，与手写签名一样，可以是图片、文字、声音或者其任意结合所生成的文件形式，本发明实施例不进行限定。

对于已签名的文件相当于被赋予了可信任的身份，其他用户无法直接修改已签名文件，例如，jarsigner被用于为JAR文件签名时，输出的已签名JAR文件与输入JAR文件完全一样，除了它再META-INP目录下有两个附加的签名文件。

需要说明的是，上述签名数据可以是对一个文件进行签名后生成的数据，也可以是对多个文件进行签名后生成的数据，本发明实施例不进行限定。

步骤S203，在将所述签名数据从前端发送至后端的过程中，遍历所述签名数据的各个参数，从所述各个参数中提取出涉及用户签名操作的参数；

由于签名数据中包括涉及签名操作过程中生成的数据，包含有各个参数，如签名应用名称、签名时间、签名信息等，而签名数据中涉及用户签名操作的参数往往具有时效性，可以用于对签名数据做进一步验证，所以在将签名数据从前端发送至后端的过程中，遍历签名数据的各个参数，从各个参数中提取出设计用户签名操作的参数，如用户签名过程中的点击参数、访问停留时间参数等。

对于本发明实施例，通过在将签名数据从前端发送至后端的过程中，遍历签名数据的各个参数，从各个参数中提取出涉及用户签名操作的参数，以便于后期对签名数据进行安全校验。

步骤S204，根据所述涉及用户签名操作的参数，从所述签名数据中提取出签名行为数据；

通过查找涉及用户签名操作的参数对应的属性值，可以从签名数据中提取出签名行为数据，例如，用户签名停留时间为5秒，用户点击按钮操作次数为2次。

需要说明的是，现有技术在获取到用户的签名数据后直接将签名数据发送至后端，而本发明实施例在将签名数据发送至后端的过程中，预先从签名数据中提取出签名行为数据，将签名行为数据过滤出来，实现签名数据的分离，降低了后端对签名数据维护的成本。

步骤S205，将所述签名行为数据存储至预先构建的数据访问中间件中；

其中，数据访问中间件作为一个中间桥梁，在前端与后端进行签名数据的传输过程中，为应用程序提供数据支撑，具体的数据访问中间件可以通过node.js实现。

对于本发明实施例，当数据访问中间件为node.js时，具体可以利用前端Nginx进行均衡负载和分发操作，node.js作为数据访问中间件，通过调用后端python接口实现功能，利用高并发能力处理签名行为数据，将签名数据存储至MangoDB数据库中。

需要说明的是，本发明实施例对构造数据访问中间件的方法不进行限定，具体还可以使用JSP技术，也可以使用JDBC技术，具体可以根据实际应用场景进行选取合适的数据访问中间件。

步骤S206，将所述签名数据中的签名业务数据存储至后端。

对于本发明实施例，具体可以利用python作为后端，将签名业务数据存储至后端。当前端向后端请求签名数据时，可以通过读写后端MySQL数据库中存储的签名业务数据，通过数据访问中间件node.js将签名数据处理后发送给前端显示。

对于本发明实施例，具体的应用场景可以如下所示，但不限于此，包括：当用户通过桌面端应用、移动应用、web、mobile web访问或使用该应用时，当用户的签名数据通过前端Nginx到达node.js服务器时，node.js服务器会对签名数据进行安全监测，并从中提取出涉及用户签名操作的签名行为数据，并将签名行为数据存入MangoDB数据库中，并将签名数据中剩余的签名业务数据发送至python后端相应接口，python后端会将业务数据进行处理后存入MySQL数据库中，从而完成签名数据的存储。

对于本发明实施例，通过将签名行为数据存储至预先构建的数据访问中间件中，将签名业务数据存储至后端，实现了数据存取与业务处理相隔离，从而使得应用程序的层次清晰，提高程序的可复用性和降低模块间的耦合性。

本发明实施例的另一种签名数据的存储方法，在将签名数据从前端发送至后端的过程中，前端并非直接将签名数据发送到后端，而是从签名数据中提取出涉及用户签名操作的签名行为数据，并将签名行为数据存储至预先构建的数据访问中间件中，通过数据访问中间件实现前端与后端的数据分离，降低了前端与后端的耦合程度，避免了后期调试和迭代存在的不便。与现有技术中将所有签名数据存储至后端的签名数据的存储方法相比，本发明实施例将签名数据中签名行为数据与签名业务数据进行分开存储，由于数据访问中间件处于操作***软件与用户的应用软件的中间，可以灵活高效的存储数据，通过数据访问中间件仍能可以实现前端与后端信息交互，进一步保证了签名数据的安全性。

在本实施例中提供了一种签名数据的验证方法，图3是根据本发明实施例的签名数据的验证方法的流程图，如图3所示，该流程包括如下步骤：

步骤S301，根据用户发送的验证请求从数据访问中间件中获取签名行为数据；

在安卓应用中，通过签名校验是一种普遍的防护策略，通过对签名数据进行校验，可以识别应用程序使用者的身份，防止跨域的攻击或者网络爬虫对***造成意想不到的问题，保证应用程序的使用安全性。

其中，数据访问中间件作为一个中间桥梁，在前端与后端进行签名数据的传输过程中，为应用程序提供数据支撑。

对于本发明实施例，数据访问中间件中存储有签名行为数据，在用户发送验证请求后，需要对签名数据进行验证，通过签名行为数据进行验证可以有效的防止签名数据被篡改。

步骤S302，将所述签名行为数据与后端存储的签名业务数据进行匹配验证；

对于本发明实施例，由于签名数据中包括涉及签名操作过程中生成的数据，包含有各个参数，如签名应用名称、签名时间、签名信息等，而签名数据中涉及用户签名操作的参数往往具有时效性，可以用于对签名数据做进一步验证，通过将签名行为数据与后端存储的签名业务数据进行匹配验证，能够提高验证结果的准确性。

具体将签名行为数据与后端存储的签名业务数据进行匹配验证的过程可以包括但不局限于，首先获取签名行为数据中的各个参数对应的属性信息，如用户签名时长，用户签名次数，然后通过解析签名业务数据，这里可以是图片形式，可以是文字形式，得到签名业务数据中涉及用户签名操作的属性信息，最后将签名业务数据中涉及用户签名操作的属性信息与签名行为数据中各个参数对应的属性值进行匹配验证，如果匹配一致，则说明签名数据是安全的，未被他人修改过，如果匹配不一致，则说明签名数据可能被他人修改。

步骤S303a，如果匹配成功，则验证签名通过；

对于本发明实施例，如果匹配验证成功，说明签名数据未被篡改，进一步将匹配验证成功的签名数据通过预先构建的数据库中间件处理后发送至前端显示。

步骤S303b，如果匹配不成功，验证签名失败。

对于本发明实施例，如果匹配验证为验证不成功，说明签名数据可能被篡改，进一步可以向前端发送验证失败的信息。

对于本发明实施例，具体的应用场景可以如下所示，但不限于此，包括：当接收到用户签名验证请求后，从node.js服务器的MangoDB数据库中获取签名行为数据包括签名日期为20150103，签名次数为2次，进一步从python后端将业务数据为两张签名图片，并且记录了签名日期为2015年1月3日，将签名行为数据与后端存储的签名业务数据进行匹配验证，验证结果匹配成功，则说明验证签名通过，进一步将匹配成功的签名数据通过node.js服务器处理后发送至前端Nginx显示。

本发明实施例的一种签名数据的验证方法，在前端页面请求签名验证时，并非直接在后端对签名数据进行验证，而是通过用户发送的验证请求从数据访问中间件中获取签名行为数据，由于签名行为数据中可能记录有用户具体签名时的行为属性信息，通过将用户签名行为数据与后端存储的签名业务数据进行匹配验证。与现有技术中将直接对后端存储的签名数据进行验证的方法相比，本发明实施例将签名数据中签名行为数据与签名业务数据进行分开存储，进一步以签名行为数据作为依据来校验签名业务数据，进一步提高了签名数据校验的准确性。

图4是根据本发明实施例的签名数据的存储装置的结构框图一，如图4所示，该装置包括：

获取单元41，可以用于获取用户输入的签名数据，所述签名数据包括签名业务数据以及签名行为数据；

提取单元42，可以用于在将所述签名数据从前端发送至后端的过程中，从所述签名数据中提取出涉及用户签名操作的签名行为数据；

第一存储单元43，可以用于将所述签名行为数据存储至预先构建的数据访问中间件中。

本发明实施例提供的一种签名数据的存储装置，在将签名数据从前端发送至后端的过程中，前端并非直接将签名数据发送到后端，而是从签名数据中提取出涉及用户签名操作的签名行为数据，并将签名行为数据存储至预先构建的数据访问中间件中，通过数据访问中间件实现前端与后端的数据分离，降低了前端与后端的耦合程度，避免了后期调试和迭代存在的不便。与现有技术中将所有签名数据存储至后端的签名数据的存储方法相比，本发明实施例将签名数据中签名行为数据与签名业务数据进行分开存储，由于数据访问中间件处于操作***软件与用户的应用软件的中间，可以灵活高效的存储数据，通过数据访问中间件仍能可以实现前端与后端信息交互，进一步保证了签名数据的安全性。

作为图4中所示签名数据的存储装置的进一步说明，图5是根据本发明实施例的签名数据的存储装置的结构框图二，如图5所示，该装置还包括：

构建单元44，可以用于利用预先确定的单页面应用框架，在前端构建单页面应用；

第二存储单元45，可以用于将所述签名数据中的签名业务数据存储至后端。

进一步地，所述提取单元42包括：

第一提取模块421，可以用于遍历所述签名数据的各个参数，从所述各个参数中提取出涉及用户签名操作的参数；

第二提取模块422，可以用于根据所述涉及用户签名操作的参数，从所述签名数据中提取出签名行为数据。

本发明实施例提供的另一种签名数据的存储装置，在将签名数据从前端发送至后端的过程中，前端并非直接将签名数据发送到后端，而是从签名数据中提取出涉及用户签名操作的签名行为数据，并将签名行为数据存储至预先构建的数据访问中间件中，通过数据访问中间件实现前端与后端的数据分离，降低了前端与后端的耦合程度，避免了后期调试和迭代存在的不便。与现有技术中将所有签名数据存储至后端的签名数据的存储方法相比，本发明实施例将签名数据中签名行为数据与签名业务数据进行分开存储，由于数据访问中间件处于操作***软件与用户的应用软件的中间，可以灵活高效的存储数据，通过数据访问中间件仍能可以实现前端与后端信息交互，进一步保证了签名数据的安全性。

图6是根据本发明实施例的签名数据的验证装置的结构框图一，如图6所示，该装置包括：

获取单元51，可以用于根据用户发送的验证请求从权利要求8-11中任一项所述的数据访问中间件中获取签名行为数据；

匹配单元52，可以用于将所述签名行为数据与后端存储的签名业务数据进行匹配验证；

第一验证单元53，可以用于如果匹配成功，则验证签名通过；

第二验证单元54，可以用于如果匹配不成功，则验证签名失败。

本发明实施例的一种签名数据的验证装置，在前端页面请求签名验证时，并非直接在后端对签名数据进行验证，而是通过用户发送的验证请求从数据访问中间件中获取签名行为数据，由于签名行为数据中可能记录有用户具体签名时的行为属性信息，通过将用户签名行为数据与后端存储的签名业务数据进行匹配验证。与现有技术中将直接对后端存储的签名数据进行验证的方法相比，本发明实施例将签名数据中签名行为数据与签名业务数据进行分开存储，进一步以签名行为数据作为依据来校验签名业务数据，进一步提高了签名数据校验的准确性。

作为图6中所示签名数据的存储装置的进一步说明，图7是根据本发明实施例的签名数据的验证装置的结构框图二，如图7所示，该装置还包括：

显示单元55，可以用于将匹配验证成功的签名数据通过预先构建的数据访问中间件处理后发送至前端显示。

进一步地，所述匹配单元52包括：

获取模块521，可以用于获取所述签名行为数据中的各个参数对应的属性值；

解析模块522，可以用于通过解析所述签名业务数据，得到所述签名业务数据中涉及用户签名操作的属性信息；

匹配模块523，可以用于将所述签名业务数据中涉及用户签名操作的属性信息与所述签名行为数据中各个参数对应的属性值进行匹配验证。

本发明实施例的另一种签名数据的验证装置，在前端页面请求签名验证时，并非直接在后端对签名数据进行验证，而是通过用户发送的验证请求从数据访问中间件中获取签名行为数据，由于签名行为数据中可能记录有用户具体签名时的行为属性信息，通过将用户签名行为数据与后端存储的签名业务数据进行匹配验证。与现有技术中将直接对后端存储的签名数据进行验证的方法相比，本发明实施例将签名数据中签名行为数据与签名业务数据进行分开存储，进一步以签名行为数据作为依据来校验签名业务数据，进一步提高了签名数据校验的准确性。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包括在本发明的保护范围之内。

Claims (10)

1.一种签名数据的存储方法，其特征在于，包括：

获取用户输入的签名数据，所述签名数据包括签名业务数据以及签名行为数据；

在将所述签名数据从前端发送至后端的过程中，从所述签名数据中提取出涉及用户签名操作的签名行为数据；

将所述签名行为数据存储至预先构建的数据访问中间件中。

2.根据权利要求1所述的方法，其特征在于，所述从所述签名数据中提取出涉及用户签名操作的签名行为数据包括：

遍历所述签名数据的各个参数，从所述各个参数中提取出涉及用户签名操作的参数；

根据所述涉及用户签名操作的参数，从所述签名数据中提取出签名行为数据。

3.根据权利要求1所述的方法，其特征在于，在所述获取用户输入的签名数据之前，所述方法还包括：

利用预先确定的单页面应用框架，在前端构建单页面应用。

4.根据权利要求1-3中任一项所述的方法，其特征在于，在所述将所述签名行为数据存储至预先构建的数据访问中间件中之后，所述方法还包括：

将所述签名数据中的签名业务数据存储至后端。

5.一种签名数据的验证方法，其特征在于，包括：

根据用户发送的验证请求从权利要求1-4中任一项所述的数据访问中间件中获取签名行为数据；

将所述签名行为数据与后端存储的签名业务数据进行匹配验证；

如果匹配成功，则验证签名通过，否则验证签名失败。

6.根据权利要求5所述的方法，其特征在于，所述将所述签名行为数据与后端存储的签名业务数据进行匹配验证包括：

获取所述签名行为数据中的各个参数对应的属性值；

通过解析所述签名业务数据，得到所述签名业务数据中涉及用户签名操作的属性信息；

将所述签名业务数据中涉及用户签名操作的属性信息与所述签名行为数据中各个参数对应的属性值进行匹配验证。

7.根据权利要求5或6所述的方法，其特征在于，在所述如果匹配成功，则验证签名通过之后，所述方法还包括：

将匹配验证成功的签名数据通过预先构建的数据访问中间件处理后发送至前端显示。

8.一种签名数据的存储装置，其特征在于，包括：

获取单元，用于获取用户输入的签名数据，所述签名数据包括签名业务数据以及签名行为数据；

提取单元，用于在将所述签名数据从前端发送至后端的过程中，从所述签名数据中提取出涉及用户签名操作的签名行为数据；

第一存储单元，用于将所述签名行为数据存储至预先构建的数据访问中间件中。

9.根据权利要求8所述的装置，其特征在于，所述提取单元包括：

第一提取模块，用于遍历所述签名数据的各个参数，从所述各个参数中提取出涉及用户签名操作的参数；

第二提取模块，用于根据所述涉及用户签名操作的参数，从所述签名数据中提取出签名行为数据。

10.一种签名数据的验证装置，其特征在于，包括：

获取单元，用于根据用户发送的验证请求从权利要求8或9所述的数据访问中间件中获取签名行为数据；

匹配单元，用于将所述签名行为数据与后端存储的签名业务数据进行匹配验证；

第一验证单元，用于如果匹配成功，则验证签名通过；

第二验证单元，用于如果匹配不成功，则验证签名失败。