CN113849845B - 对插件文件打包的方法和装置、计算设备和可读存储介质 - Google Patents

Abstract

本发明公开了一种对插件文件打包的方法和装置、计算设备和可读存储介质，所述方法包括：读取配置文件，以验证所述目录是否为待打包目录；读取主插件文件，验证主插件文件的接口合法性；通过环境隔离算法判断主插件文件是否依赖于目录外的子插件文件，提取主插件文件依赖的所有目录外的子插件文件并置入所述目录下；验证用户传入的私钥与证书中的公钥是否匹配；对目录内的主插件文件、子插件文件、证书和静态资源文件打包，压入一个压缩包内。根据本发明技术方案，解决了多开发者开发时多插件文件依赖的问题；保证了插件压缩包不可伪造；减轻了插件仓库WEB服务器的压力。

Description

对插件文件打包的方法和装置、计算设备和可读存储介质

技术领域

本发明涉及计算机插件服务领域，尤其涉及一种对插件文件打包的方法和装置、计算设备和可读存储介质。

背景技术

在实际插件开发中，开发者开发的主插件不仅依赖于自身开发的子插件，还会依赖于大量的第三方库（LIB库中的系统插件）。子插件文件分两大类，一类是用户自己开发的子插件文件，且置于非LIB库或同级目录中（开发者知道位置），另一类是LIB库中的子插件文件，这些子插件文件一般是知名大厂开发的子插件文件，或者是系统子插件文件。通常开发者开发的主插件文件依赖于这两类子插件文件。

目前，插件服务无法应对多插件依赖的场景，比如在主插件依赖于系统子插件的情况下，可能会导致无法调取并上传子插件，从而导致插件上传不完整，浏览器调用插件时会失败，导致插件初始化失败。如果做插件依赖分析，比如用户记录各个插件的依赖关系，上传插件文件时解析插件文件并上传相关依赖，就会增加插件仓库的复杂度，导致插件仓库不能单纯用作插件文件的版本控制，这会增加额外的不同机器环境的适配（且无法估算，因为不同开发者的开发环境都会有差异）。

发明内容

为此，本发明提供了一种对插件文件打包的方法和装置、计算设备和可读存储介质，以力图解决或者至少缓解上面存在的至少一个问题。

根据本发明的一个方面，提供一种对插件文件打包的方法，其中所述插件文件位于目录中，所述目录中还包含记录有主插件文件路径和证书路径的配置文件、存放公钥的证书、静态资源文件，所述方法包括：读取所述配置文件，以确定所述目录是否为待打包目录，在所述目录是待打包目录的情况下：读取主插件文件，验证主插件文件的接口合法性，在验证成功的情况下：通过环境隔离算法判断所述主插件文件是否依赖于目录外的子插件文件，提取主插件文件依赖的所有目录外的子插件文件并置入所述目录下；验证用户传入的私钥与证书中的公钥是否匹配，在匹配的情况下：对目录内的主插件文件、子插件文件、证书和静态资源文件打包，压入一个插件文件包内。

根据本发明另一方面，提供一种对插件文件打包的装置，其中所述插件文件位于目录中，所述目录中还包含记录有主插件文件路径和证书路径的配置文件、存放公钥的证书、静态资源文件，所述装置包括：确定模块，读取所述配置文件，以确定所述目录是否为待打包目录；第一验证模块，读取主插件文件，验证主插件文件的接口合法性；提取模块，通过环境隔离算法判断所述主插件文件是否依赖于目录外的子插件文件，提取主插件文件依赖的所有目录外的子插件文件并置入所述目录下；第二验证模块，验证用户传入的私钥与证书中的公钥是否匹配；压缩模块，对目录内的主插件文件、子插件文件、证书和静态资源文件打包，压入一个插件文件包内。

根据本发明又一方面，提供一种计算设备，包括：至少一个处理器和存储有程序指令的存储器；当所述程序指令被所述处理器读取并执行时，使得所述计算设备执行上述对插件文件打包的方法。

根据本发明又一方面，提供一种存储有程序指令的可读存储介质，当所述程序指令被计算设备读取并执行时，使得所述计算设备执行上述对插件文件打包的方法。

根据本发明技术方案，带来以下有益效果：解决了多开发者开发时多插件文件依赖的问题；保证了插件压缩包不可伪造；减轻了插件仓库WEB服务器的压力。

附图说明

为了实现上述以及相关目的，本文结合下面的描述和附图来描述某些说明性方面，这些方面指示了可以实践本文所公开的原理的各种方式，并且所有方面及其等效方面旨在落入所要求保护的主题的范围内。通过结合附图阅读下面的详细描述，本公开的上述以及其它目的、特征和优势将变得更加明显。遍及本公开，相同的附图标记通常指代相同的部件或元素。

图1示出了根据本发明一个实施例的计算设备100的示意图。

图2示出了根据本发明实施例的对插件文件打包的方法的总体设计方案。

图3示出了根据本发明实施例的对插件文件打包的方法300的示意性流程图。

图4示出了将清单文件的摘要签名插入到压缩包的文件信息和中央目录之间的示意性图示。

图5示出了根据本发明实施例的技术方案产生的压缩包的示意性图。

图6示出了根据本发明实施例的对插件文件打包的装置的示意性框图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

针对现有插件上传加载技术不能解决多插件依赖的问题，本发明提供了一种对插件文件打包的方法和装置、计算设备和可读存储介质，使得能够解决多插件依赖的场景，还可以将插件验证及证书验证的部分放在打包工具方案中处理，减轻插件仓库WEB服务器的压力。

本发明的对插件文件打包的方法在计算设备中执行。计算设备可以是任意具有存储和计算能力的设备，其例如可以实现为服务器、工作站等，也可以实现为桌面计算机、笔记本计算机等个人配置的计算机，或者实现为手机、平板电脑、智能可穿戴设备、物联网设备等终端设备，但不限于此。

图1示出了根据本发明一个实施例的计算设备100的示意图。需要说明的是，图1所示的计算设备100仅为一个示例，在实践中，用于实施本发明的对插件文件打包的方法的计算设备可以是任意型号的设备，其硬件配置情况可以与图1所示的计算设备100相同，也可以与图1所示的计算设备100不同。实践中用于实施本发明的对插件文件打包的方法的计算设备可以对图1所示的计算设备100的硬件组件进行增加或删减，本发明对计算设备的具体硬件配置情况不做限制。

如图1所示，在基本的配置102中，计算设备100典型地包括系统存储器106和一个或者多个处理器104。存储器总线108可以用于在处理器104和系统存储器106之间的通信。

取决于期望的配置，处理器104可以是任何类型的处理，包括但不限于：微处理器（µP）、微控制器（µC）、数字信息处理器（DSP）或者它们的任何组合。处理器104可以包括诸如一级高速缓存110和二级高速缓存112之类的一个或者多个级别的高速缓存、处理器核心114和寄存器116。示例的处理器核心114可以包括运算逻辑单元（ALU）、浮点数单元（FPU）、数字信号处理核心（DSP核心）或者它们的任何组合。示例的存储器控制器118可以与处理器104一起使用，或者在一些实现中，存储器控制器118可以是处理器104的一个内部部分。

取决于期望的配置，系统存储器106可以是任意类型的存储器，包括但不限于：易失性存储器（诸如RAM）、非易失性存储器（诸如ROM、闪存等）或者它们的任何组合。计算设备中的物理内存通常指的是易失性存储器RAM，磁盘中的数据需要加载至物理内存中才能够被处理器104读取。系统存储器106可以包括操作系统120、一个或者多个应用122以及程序数据124。在一些实施方式中，应用122可以布置为在操作系统上由一个或多个处理器104利用程序数据124执行指令。操作系统120例如可以是Linux、Windows等，其包括用于处理基本系统服务以及执行依赖于硬件的任务的程序指令。应用122包括用于实现各种用户期望的功能的程序指令，应用122例如可以是浏览器、即时通讯软件、软件开发工具（例如集成开发环境IDE、编译器等）等，但不限于此。当应用122被安装到计算设备100中时，可以向操作系统120添加驱动模块。

在计算设备100启动运行时，处理器104会从存储器106中读取操作系统120的程序指令并执行。应用122运行在操作系统120之上，利用操作系统120以及底层硬件提供的接口来实现各种用户期望的功能。当用户启动应用122时，应用122会加载至存储器106中，处理器104从存储器106中读取并执行应用122的程序指令。

计算设备100还包括储存设备132，储存设备132包括可移除储存器136和不可移除储存器138，可移除储存器136和不可移除储存器138均与储存接口总线134连接。

计算设备100还可以包括有助于从各种接口设备（例如，输出设备142、外设接口144和通信设备146）到基本配置102经由总线/接口控制器130的通信的接口总线140。示例的输出设备142包括图形处理单元148和音频处理单元150。它们可以被配置为有助于经由一个或者多个A/V端口152与诸如显示器或者扬声器之类的各种外部设备进行通信。示例外设接口144可以包括串行接口控制器154和并行接口控制器156，它们可以被配置为有助于经由一个或者多个I/O端口158和诸如输入设备（例如，键盘、鼠标、笔、语音输入设备、触摸输入设备）或者其他外设（例如打印机、扫描仪等）之类的外部设备进行通信。示例的通信设备146可以包括网络控制器160，其可以被布置为便于经由一个或者多个通信端口164与一个或者多个其他计算设备162通过网络通信链路的通信。

网络通信链路可以是通信介质的一个示例。通信介质通常可以体现为在诸如载波或者其他传输机制之类的调制数据信号中的计算机可读指令、数据结构、程序模块，并且可以包括任何信息递送介质。“调制数据信号”可以这样的信号，它的数据集中的一个或者多个或者它的改变可以在信号中编码信息的方式进行。作为非限制性的示例，通信介质可以包括诸如有线网络或者专线网络之类的有线介质，以及诸如声音、射频（RF）、微波、红外（IR）或者其它无线介质在内的各种无线介质。这里使用的术语计算机可读介质可以包括存储介质和通信介质二者。

在根据本发明的计算设备100中，应用122包括用于执行本发明的对插件文件打包的方法300的指令，该指令可以指示处理器104执行本发明的对插件文件打包的方法300，以通过打包上传来解决多插件依赖的问题。

本发明的方法300的总体设计如图2所示。在图2中，以UBX应用环境为例进行描述，且插件文件采用SO文件作为示例，然而应理解，本发明不限于UBX应用环境，也适用于其他格式插件文件的情况。如图2所示，本发明技术方案的设计思路是：通过打包工具将多个SO（SO文件是Linux下的程序函数库,即编译好的可以供其他程序使用的代码和数据）、证书及相关文件打包成一个UBX（一种浏览器插件接口平台）自有格式的文件（Build.UBX）来处理多SO依赖的问题，以满足客户多SO上传、下载、运行的需求。

假设用户自行创建了一个build目录作为待打包目录，且创建了配置文件（config.toml或其他格式文件）并存放于该build目录下。用户在配置文件中使用相对目录记录主插件文件路径和证书路径。在配置文件中指定主插件文件路径和证书路径，是为了以供在后续读取并验证主插件文件、验证证书时读取这些文件并使用。

除了配置文件之外，build目录还包含待上传的插件文件（包括主插件文件和子插件文件）、以及证书，其中证书用于存放与用户的私钥配合对文件进行非对称加密解密的公钥。此外，待打包目录中还包含插件文件运行时可能需要的静态资源文件（包括图片、文本等）（图中未示出）。

另外，该配置文件也可以由打包工具自行生成且存放于build目录中。配置文件的部分内容可以如下：

1.#使用相对目录

2. [so]

3. name = "主so文件路径" # 为相对路径,相对于build目录

4.

5. [cert]

6. name = "证书文件路径" # 为相对路径

7.

8. [build]

9. name = "./lib,./resours,./config" #可配置的源文件目录

其中，打包工具可以通过读取build目录（用户自行创建的目录示例）下的配置文件，验证指定的SO和证书，然后通过压缩算法将build目录中的SO文件、证书文件（cert证书）、静态资源进行公私钥加密打包，最终生成文件Build.UBX。

如图2所示，在打包完成后，客户上传生成的UBX格式文件，WEB服务器校验文件有效性，读取UBX文件中清单文件，将相关信息写入数据库。

图3示出了根据本发明一个实施例的对插件文件打包的方法300（即打包工具执行的方法）的流程图。方法300在计算设备（例如前述计算设备100）中执行。下面参考图3描述方法300的详细步骤。如图3所示，方法300包括：

S310，读取配置文件，以确定所述目录是否为待打包目录，如果是，可以执行下一步骤。如果不是，可以继续遍历其他目录以执行该判断，或者可以再一次遍历本目录以防止读取有误。

步骤S310是为了通过配置文件来确定待打包目录，可以首先判断是否存在配置文件，然后判断配置文件的格式是否为期望的格式，再遍历目录，判断目录下是否存在配置文件中定义的主插件文件和证书，具体地通过以上配置文件中的键名（比如name等）和键值（比如“主SO文件路径”等）来执行该判断。在判断存在配置文件、格式符合期望格式且存在定义的文件的情况下，可以确定目录是待打包目录，否则会报错，导致方法300结束。

如之前所述，配置文件可以由方法300创建且置于build目录下。在这种情况下，为了防止用户对文件进行过修改，比如修改了键名等，仍然需要执行步骤S310，以确定是否存在配置文件，以及目录是否为待打包目录。

S320，读取主插件文件，验证主插件文件的接口合法性，在验证成功的情况下，可以执行下一步骤。

当打包工具确定待打包目录后，首先会对主插件文件进行接口合法性的验证。

主插件文件是开发者基于某些规则开发的，期望其实现我们希望它实现的接口，比如初始化的接口、主插件文件信息的接口，主插件文件特殊调用的接口。经过接口合法性验证之后，才知道主插件文件是不是我们期望的主插件文件。

读取主插件文件的过程可以是：主插件文件引用了ubx的接口sdk，对打包工具暴露相关接口。打包工具通过go语言的cgo功能，来读取和调用主插件文件封装接口。应理解，读取主插件文件不限于UBX环境下的具体示例方式，在其他应用场景下，本领域技术人员可以采用其他方式来读取主插件文件并进行验证。

S330，通过环境隔离算法判断所述主插件文件是否依赖于目录外的子插件文件，提取主插件文件依赖的所有目录外的子插件文件并置入所述目录下。

通过图3所示打包工具打包时，会做依赖分析，把所有需要的子插件文件全部打包进来。子插件文件分两大类，一类是用户自己开发的子插件文件，且置于非LIB库或同级目录中（开发者知道位置），另一类是LIB库中的子插件文件，这些子插件文件一般是知名大厂开发的子插件文件，或者是系统子插件文件。通常开发者开发的主插件文件依赖于这两类子插件文件。

在传统技术里，开发者上传插件文件时，只关注自己开发的子插件文件，而对于这一类子插件文件，由于开发者知道存放位置，可以在比如方法300启动之前直接调取到build目录下。对于第二类子插件文件，需要通过环境隔离的方式来验证主插件文件是否依赖于系统子插件文件。

环境隔离可以写在上述CGO包中。环境隔离通过Linux 下的系统功能Namespaces和changeroot相互配合来进行。其中，Namespaces 是 Linux 内核用来隔离内核资源的方式。使得处于不同 Namespace 的进程拥有独立的全局系统资源，改变一个 Namespace 中的系统资源只会影响当前 Namespace 里的进程，对其他 Namespace 中的进程没有影响。change root是改变程式执行时所参考的根目录位置。

通过Namespaces和changeroot相互配合进行环境隔离，来对主插件文件进行隔离，排除对系统子插件文件的依赖，如果发现对系统子插件文件有依赖，就移到build目录下（如果有权限）。如果没有权限，会对用户进行提示。

在实际运行中，如果环境隔离运行且无异常，说明所有依赖的子插件文件都位于build目录里面，且主插件文件对系统子插件文件没有依赖。如果出现异常，说明主插件文件依赖于系统子插件文件。此时通过以下手段提取系统子插件文件：首先，虚拟一个和当前系统隔离开来的环境，这个环境有新的系统目录、新的LIB库目录，在该环境下读取主插件文件的接口，把主插件文件调起来，由于环境隔离，新环境里的新LIB库是空的，在其中找不到任何依赖文件。可以通过一些算法或技术来捕获到返回的错误信息——即找不到任何依赖文件，比如缺少LIB1、LIB2，这些文件都位于系统LIB库中。提取捕获的信息后，如果有权限，可以把缺少的LIB库拷贝一份置入待打包目录中。如果没有权限，可以把捕获的信息告诉用户，让用户自行操作。

S340，验证用户传入的私钥与证书中的公钥是否匹配，在验证成功的情况下，可以执行下一步骤。私钥只有开发者知道，上传私钥后可以对插件文件进行校验。进行该验证以确保数据安全、防止插件是被篡改、伪造的。如果验证失败，可以提醒用户上传新私钥、或者再一次执行验证等。

通过步骤S320和步骤S340，将插件文件验证及证书验证的部分放在打包工具方案中处理，这样减轻了插件仓库WEB服务器的压力。

S350，对目录内的主插件文件、子插件文件、证书和静态资源文件打包，压入一个插件文件包内。

基于步骤S330中所述，步骤S350所述的子插件文件包含主插件文件依赖的所有子插件文件，包括：build目录下已有的子插件文件、位于非LIB库中且被用户调取到build目录下的子插件文件以及通过环境隔离算法调取的系统子插件文件。另外，在传统技术中，需要开发者在上传插件文件的同时上传证书。而在本实施例的方案中，将证书与插件文件一起打包，这样也减轻了插件仓库WEB服务器的压力。

打包结束后可以对整个压缩包加密，来确保安全性。也可以在打包后，通过计算压缩包的哈希值并记录哈希值的方式来加密。

打包过程采用的加密方式还可以是：计算每个主插件文件、子插件文件、证书及资源文件的SHA-1摘要，写入对应清单文件中；计算整个清单文件的摘要，使用用户的私钥计算出摘要的签名；生成压缩文件，将验证后的主插件文件、子插件文件、证书和资源文件全部压入插件文件包内；将插件文件包和信息文件打包成一个压缩包，其中信息文件记录有验证SO、读取SO/证书的信息、清单文件的摘要等；将清单文件的摘要签名插入到压缩包的文件信息和中央目录之间。图4示出了将清单文件的摘要签名插入到压缩包的文件信息（文件的主内容）和中央目录（文件系统构造的一部分）之间的示意性图示。

该加密方式计算文件摘要、通过私钥签名的方式进行加密，对每一个文件的哈希值进行记录。通过这种方式，压缩包本身没有加密，加密的对象是其中包含的信息。通过这种加密方式，因为压缩包没有加密，用户可以拆开压缩包并看到打包的内容，然而如果用户修改了文件，后期也能验证出来。另外，将清单文件的摘要签名插入到压缩包文件的文件信息和中央目录之间，这样不会破坏压缩包内的文件。

产生的压缩包可以如图5所示，在此以插件文件是SO格式且以ZIP格式来打包为例进行说明。如图5所示，打包后的压缩包包含一个info文件和一个ZIP包（即插件文件包），其中info文件用来记录验证SO、读取SO/证书的信息、加密算法的摘要等，ZIP包中含有压缩的插件文件、静态资源等。

在该步骤S350中，打包过程是可配置的。如上所述在build目录下通过打包工具或用户构建有config文件（config.toml），这是文件打包的规则，可以由用户主动填写。在希望连同目录下的静态资源一起打包的情况下，用户可以在配置文件中自定义打包对象，比如在配置文件中规定了只打包文本资源，那么在打包时将打包文本资源，且省略没有指定的静态资源比如图片资源。如果不指定，则将build目录下的所有文件（包括所有静态资源文件）一起打包（除了config文件之外）。

因此，步骤S350还可以包括：判断所述配置文件中是否指定了静态资源文件，在没有指定的情况下，对所述目录内的所有静态资源文件进行打包；在指定的情况下，只对指定的静态资源文件打包。

这样，通过构建打包工具来自动化执行和管理打包流程，可以允许打包过程中灵活的自定义构建配置，比如除了在配置文件中指定主SO和证书的路径之外，还在其中记录是否对静态资源打包以及对哪些静态资源打包。

通过以上过程，最终生成UBX插件文件。插件服务在运行验证UBX文件的时候，只需要读取文件的文件信息中的摘要签名，再通过公钥证书就可以验证文件的合法性了。

根据本发明实施例的技术方案，带来以下有益效果：解决了多开发者开发时多插件文件依赖的问题；保证了插件压缩包不可伪造；减轻了插件仓库WEB服务器的压力。

根据本发明另一实施例，提供一种对插件文件打包的装置。与以上方法实施例的描述类似地，插件文件位于目录中，所述目录中还包含记录有主插件文件路径和证书路径的配置文件、存放公钥的证书、静态资源文件。图6示出了该装置的示意性框图。如图6所示，该装置包括：

确定模块610，读取所述配置文件，以验证所述目录为待打包目录；

第一验证模块620，遍历所述目录，读取主插件文件，验证主插件文件的接口合法性；

提取模块630，通过环境隔离算法判断所述主插件文件是否依赖于目录外的子插件文件，提取主插件文件依赖的所有目录外的子插件文件并置入所述目录下；

第二验证模块640，验证用户传入的私钥与证书中的公钥是否匹配；

压缩模块650，对目录内的主插件文件、子插件文件、证书和静态资源文件打包，压入一个插件文件包内。压缩模块可以通过以下方式进行打包：计算每个主插件文件、子插件文件、证书及资源文件的SHA-1摘要，写入对应清单文件中；计算整个清单文件的摘要，使用用户的私钥计算出摘要的签名；生成压缩文件，将验证后的主插件文件、子插件文件、证书和资源文件全部压入插件文件包内；将插件文件包和信息文件打包成一个压缩包，其中信息文件记录有验证SO、读取SO/证书的信息、清单文件的摘要等；将清单文件的摘要签名插入到压缩包的文件信息和中央目录之间。

可选地，压缩模块可以判断所述配置文件中是否指定了静态资源文件，在没有指定的情况下，对所述目录内的所有静态资源文件进行打包；在指定的情况下，只对指定的静态资源文件打包。

可选地，装置还可以包括：创建模块，在方法启动时，在目录内自动创建所述配置文件。

上述装置实施例中未详细描述的部分，请参考方法实施例中的描述，在此不再予以赘述。

这里描述的各种技术可结合硬件或软件，或者它们的组合一起实现。从而，本发明的方法和设备，或者本发明的方法和设备的某些方面或部分可采取嵌入有形媒介，例如可移动硬盘、U盘、软盘、CD-ROM或者其它任意机器可读的存储介质中的程序代码(即指令)的形式，其中当程序被载入诸如计算机之类的机器，并被所述机器执行时，所述机器变成实践本发明的设备。

在程序代码在可编程计算机上执行的情况下，计算设备一般包括处理器、处理器可读的存储介质(包括易失性和非易失性存储器和/或存储元件)，至少一个输入装置，和至少一个输出装置。其中，存储器被配置用于存储程序代码；处理器被配置用于根据该存储器中存储的所述程序代码中的指令，执行本发明的对插件文件打包的方法。

以示例而非限制的方式，可读介质包括可读存储介质和通信介质。可读存储介质存储诸如计算机可读指令、数据结构、程序模块或其它数据等信息。通信介质一般以诸如载波或其它传输机制等已调制数据信号来体现计算机可读指令、数据结构、程序模块或其它数据，并且包括任何信息传递介质。以上的任一种的组合也包括在可读介质的范围之内。

在此处所提供的说明书中，算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与本发明的示例一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的优选实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多特征。本领域那些技术人员应当理解在本文所公开的示例中的设备的模块或单元或组件可以布置在如该实施例中所描述的设备中，或者可替换地可以定位在与该示例中的设备不同的一个或多个设备中。前述示例中的模块可以组合为一个模块或者此外可以分成多个子模块。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。此外，所述实施例中的一些在此被描述成可以由计算机系统的处理器或者由执行所述功能的其它装置实施的方法或方法元素的组合。因此，具有用于实施所述方法或方法元素的必要指令的处理器形成用于实施该方法或方法元素的装置。此外，装置实施例的在此所述的元素是如下装置的例子：该装置用于实施由为了实施该发明的目的的元素所执行的功能。

如在此所使用的那样，除非另行规定，使用序数词“第一”、“第二”、“第三”等等来描述普通对象仅仅表示涉及类似对象的不同实例，并且并不意图暗示这样被描述的对象必须具有时间上、空间上、排序方面或者以任意其它方式的给定顺序。

尽管根据有限数量的实施例描述了本发明，但是受益于上面的描述，本技术领域内的技术人员明白，在由此描述的本发明的范围内，可以设想其它实施例。此外，应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。

Claims (10)

1.一种对插件文件打包的方法，其中所述插件文件位于目录中，所述目录中还包含记录有主插件文件路径和证书路径的配置文件、存放公钥的证书、静态资源文件，所述方法包括：

读取所述配置文件，以确定所述目录是否为待打包目录，在所述目录是待打包目录的情况下：

读取主插件文件，验证主插件文件的接口合法性，在验证成功的情况下：

运行环境隔离算法并判断所述环境隔离算法运行是否正常；如果正常，则判断主插件文件依赖的所有子插件文件都位于所述目录下；如果异常，则判断主插件文件依赖于所述目录外的子插件文件；将所述目录外的子插件文件置入所述目录下；

验证用户传入的私钥与证书中的公钥是否匹配，在匹配的情况下：

对目录内的主插件文件、子插件文件、证书和静态资源文件打包，压入一个插件文件包内。

2.如权利要求1所述的对插件文件打包的方法，还包括：

在方法启动时，在目录内自动创建所述配置文件。

3.如权利要求1所述的对插件文件打包的方法，其中对目录内的主插件文件、子插件文件、证书和静态资源文件打包包括：

计算每个主插件文件、子插件文件、证书及静态资源文件的SHA-1摘要，写入对应清单文件中；

计算整个清单文件的摘要，使用用户的私钥计算出摘要的签名；

将验证后的主插件文件、子插件文件、证书和静态资源文件全部压入插件文件包内，将插件文件包与信息文件压缩为一个压缩包，所述信息文件记录有验证主插件文件的信息、验证证书的信息和清单文件的摘要；

将清单文件的摘要签名插入到所述压缩包的文件信息和中央目录之间。

4.如权利要求1所述的对插件文件打包的方法，其中步骤“读取所述配置文件，以确定所述目录是否为待打包目录”包括：

确定是否存在所述配置文件，确定所述配置文件的格式是否为期望格式，遍历所述目录且确定所述目录中是否包含所述配置文件中记录其路径的主插件文件和证书，在确定存在所述配置文件，所述配置文件的格式是期望格式，且所述目录中包含所述配置文件中记录其路径的主插件文件和证书的情况下，确定所述目录是待打包目录。

5.如权利要求1所述的对插件文件打包的方法，其中所述配置文件中还指定待打包的静态资源文件，

对目录内的主插件文件、子插件文件、证书和静态资源文件打包包括：

判断所述配置文件中是否指定了静态资源文件，

在没有指定的情况下，对所述目录内的所有静态资源文件进行打包；

在指定的情况下，只对指定的静态资源文件打包。

6.一种对插件文件打包的装置，其中所述插件文件位于目录中，所述目录中还包含记录有主插件文件路径和证书路径的配置文件、存放公钥的证书、静态资源文件，所述装置包括：

确定模块，读取所述配置文件，以确定所述目录是否为待打包目录；

第一验证模块，读取主插件文件，验证主插件文件的接口合法性；

提取模块，用于运行环境隔离算法并判断所述环境隔离算法运行是否正常；如果正常，则判断主插件文件依赖的所有子插件文件都位于所述目录下；如果异常，则判断主插件文件依赖于所述目录外的子插件文件；将所述目录外的子插件文件置入所述目录下；

第二验证模块，验证用户传入的私钥与证书中的公钥是否匹配；

压缩模块，对目录内的主插件文件、子插件文件、证书和静态资源文件打包，压入一个插件文件包内。

7.如权利要求6所述的对插件文件打包的装置，还包括：

创建模块，在方法启动时，在目录内自动创建所述配置文件。

8.如权利要求6所述的对插件文件打包的装置，其中所述压缩模块通过以下方式进行打包：

计算每个主插件文件、子插件文件、证书及静态资源文件的SHA-1摘要，写入对应清单文件中；

计算整个清单文件的摘要，使用用户的私钥计算出摘要的签名；

将验证后的主插件文件、子插件文件、证书和静态资源文件全部压入插件文件包内，并将插件文件包与信息文件压缩为一个压缩包，所述信息文件记录有验证主插件文件的信息、验证证书的信息和清单文件的摘要；

将清单文件的摘要签名插入到压缩包的文件信息和中央目录之间。

9.一种计算设备，包括：

至少一个处理器和存储有程序指令的存储器；

当所述程序指令被所述处理器读取并执行时，使得所述计算设备执行如权利要求1-5中任一项所述的对插件文件打包的方法。

10.一种存储有程序指令的可读存储介质，当所述程序指令被计算设备读取并执行时，使得所述计算设备执行如权利要求1-5中任一项所述的对插件文件打包的方法。

Images