CN116186648A - 一种低代码元数据保护的方法及系统 - Google Patents

Abstract

本申请公开了一种低代码元数据保护的方法及系统。该方法首先生成第一低代码元数据，并向第一低代码元数据中添加第一签名信息，第一签名信息包括第一低代码元数据的第一开发者的第一版权信息。然后对第一签名信息进行加密以生成第一签名文件，第一签名文件中包括的第一版权信息在第一低代码元数据被修改时不变。最后将第一签名文件保存在低代码平台的数据库中。本申请中还公开了一种低代码元数据保护的系统。在本申请实施例中，实现了对于低代码元数据的开发者的版权信息的保护。

Description

一种低代码元数据保护的方法及系统

技术领域

本申请涉及信息技术安全领域，特别涉及一种低代码元数据保护的方法及系统。

背景技术

低代码开发平台是为企业级用户和社会化开发者群体提供的集成低代码开发平台。平台集成了各类开源开发工具和开发组件，丰富以可视化、组态式为主要特征的集成开发环境，满足企业级用户拖拉拽方式快速高效生成工业应用((application，APP))的需求。

在低代码开发平台中需要用到低代码元数据进行APP的开发，低代码元数据是一种用来定义低代码APP的数据结构，一般一个低代码APP包括菜单导航、视图、页面、控件、对象、模型到表列等元数据，通过可视化编程来生成元数据。

在现有的低代码开发平台中，没有针对低代码元数据的进行保护，并且没有针对低代码元数据对应的开发者信息进行产权保护没有涉及，导致开发者开发的APP及源代码容易被剽窃，进而降低了开发者使用低代码平台开发APP的积极性。

发明内容

有鉴于此，本申请实施例提供了一种低代码元数据保护的方法及系统，旨在实现低代码元数据的安全及产权保护需求。

第一方面，本申请实施例提供了一种低代码元数据保护的方法，应用于低代码平台，所述方法包括：

生成第一低代码元数据，并向所述第一低代码元数据中添加第一签名信息，所述第一签名信息包括所述第一低代码元数据的第一开发者的第一版权信息；

所述第一签名信息进行加密以生成第一签名文件，所述第一签名文件中包括的所述第一版权信息在所述第一低代码元数据被修改时不变；

将所述第一签名文件保存在所述低代码平台的数据库中。

可选的，所述第一开发者的第一版权信息，具体包括：

所述第一开发者的开发者编号，所述开发者编号由所述低代码平台预先配置且具有唯一性。

可选的，当所述第一低代码元数据被修改的方式具体为：维持所述第一低代码元数据不变，并在所述第一低代码元数据的基础上新增低代码元数据以得到第二低代码元数据，所述方法还包括：

向所述第二低代码元数据中添加第二签名信息，所述第二签名信息包括所述第二低代码元数据的第二开发者的第二版权信息；

将所述第二签名信息进行加密以生成第二签名文件，所述第二签名文件中包括的所述第二版权信息在所述第二低代码元数据被修改时不变；

将所述第二签名文件保存在所述低代码平台的数据库中。

可选的，当所述第一低代码元数据被修改的方式具体为：直接对所述第一低代码元数据进行修改以得到第二低代码元数据，所述方法还包括：

向所述第二低代码元数据中添加第二签名信息，所述第二签名信息包括所述第一签名文件中的所述第一版权信息；

将所述第二签名信息进行加密以生成第二签名文件，所述第二签名文件中包括的所述第二版权信息在所述第二低代码元数据被修改时不变；

将所述第二签名文件保存在所述低代码平台的数据库中。

可选的，所述第一签名信息进行加密以生成第一签名文件，包括：

利用非对称加密算法对所述第一签名信息进行加密并生成第一签名文件，当对所述第一低代码元数据进行修改并得到所述第二低代码元数据时，使用非对称加密算法对所述第二低代码元数据的第二签名信息重新进行加密，并生成对应的第二签名文件。

可选的，所述方法还包括：

所述低代码平台对所述第一签名文件及第三签名文件进行比对并得到比对结果，根据所述比对结果判断所述第一低代码元数据是否被篡改。

可选的，所述根据所述比对结果判断所述第一低代码元数据是否被篡改，包括：

若所述比对结果为所述第三签名文件与所述第一签名文件不一致，则认定所述第一低代码元数据被篡改，且所述第一低代码元数据停止使用；

若所述比对结果为所述第三签名文件与所述第一签名文件一致，则认定所述第一低代码元数据未被篡改。

可选的，所述方法还包括：

第一用户通过所述低代码平台导出第一低代码元数据，所述第一低代码元数据已由所述低代码平台授权给第二用户；

所述第一用户利用所述第二用户的第二版权信息为所述第一低代码元数据进行加密并发送至所述第二用户，所述第二版权信息包括所述第二开发者的开发者编号，所述开发者编号由所述低代码平台预先配置且具有唯一性；

所述第二用户利用所述第二用户的第二版权信息对所述第一低代码元数据进行解密，并完成对所述第一低代码元数据的导入。

可选的，所述若所述比对结果为所述第三签名文件与所述第一签名文件不一致，则认定所述第一低代码元数据被篡改，还包括：

若认定所述第一低数据元代码被篡改，所述低代码平台重新导入所述第一低数据元代码。

第二方面，本申请实施例提供了一种低代码元数据保护的系统，所述系统包括：

签名模块，用于生成第一低代码元数据，并向所述第一低代码元数据中添加第一签名信息，所述第一签名信息包括所述第一低代码元数据的第一开发者的第一版权信息；

加密模块，用于所述第一签名信息进行加密以生成第一签名文件，所述第一签名文件中包括的所述第一版权信息在所述第一低代码元数据被修改时不变；

保存模块，用于将所述第一签名文件保存在所述低代码平台的数据库中。

第三方面，本申请实施例提供了一种计算机存储介质，所述计算机存储介质中存储有代码，当所述代码被运行时，运行所述代码的设备实现前述第一方面任一项所述方法。

本申请提供了一种低代码元数据保护的方法及系统，该方法应用于低代码平台，在执行所述方法时，首先生成第一低代码元数据，并向第一低代码元数据中添加第一签名信息，第一签名信息包括第一低代码元数据的第一开发者的第一版权信息。然后对第一签名信息进行加密以生成第一签名文件，第一签名文件中包括的第一版权信息在第一低代码元数据被修改时不变。最后将第一签名文件保存在低代码平台的数据库中。如此，通过对签名信息进行加密保障了低代码元数据的安全，同时，当低代码元数据被修改时，该低代码元数据之前的开发者版权信息不会随之改变，而是随之一直保留。通过保留开发者的版权信息能够便于后续对于该低代码元数据的产权确定，明确在不同阶段该低代码元数据的变化过程中各个部分所属的开发者，以此保障开发者的产权。

附图说明

为更清楚地说明本实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为一种低代码元数据保护的方法的流程图；

图2为低代码元数据的结构示意图；

图3为实体模型的基表的示意图；

图4为平台为用户授予唯一的开发者信息的流程图；

图5为低代码元数据防篡改的方法流程图；

图6为元数据的保存及导出的示意图；

图7为企业间应用低代码元数据的版权保护的流程图；

图8为一种低代码元数据保护的系统的结构示意图；

图9为利用低代码元数据新建应用的界面显示示意图。

具体实施方式

在对于现有技术的研究发现，一个典型的低代码开发平台会提供多种设计器，通过可视化、组态式的开发，可以快速配置出各种特定业务需求的功能软件。平台为了降低开发者开发APP的难度，往往会从设计APP角度来定义一套低代码元数据，一方面方便开发者可以直观的理解一个APP的组成，另一方面作为平台，也可以根据低代码元数据的结构去很好的实现APP的运行。平台降低了开发者的门槛，使得企业行业专家可以自主开发LCAP(低代码应用)，这类通过行业专家开发的LCAP往往有非常高的商业价值，对企业来说有很高的知识产品保护需求。因代码简单，在LCAP及元数据代码导入导出以及数据库等层面，都非常容易被剽窃，因而平台建立一套完善的知识产品保护及溯源机制对企业用户来说特别重要。

基于此，本申请提出了一种低代码元数据保护的方法及系统，能够实现对于低代码元数据的原始开发者的产权保护，便于低代码元数据的产权追溯，具体方法为：

首先对用户开发的应用中所用到的低代码元数据进行数据签名，并对数据签名内容进行加密，以增加签名的安全性，签名的内容包括开发者信息、应用的编号及签名字段。当对所述应用对应的低代码元数据进行修改时，原始的开发者编号不会改变。

图1为一种低代码元数据保护的方法的流程图，参见图1所示，本申请提供的一种低代码元数据保护的方法，应用于低代码平台，该方法具体包括：

S101：生成第一低代码元数据，并向所述第一低代码元数据中添加第一签名信息，所述第一签名信息包括所述第一低代码元数据的第一开发者的第一版权信息。

低代码开发平台，是一种为企业级用户和社会化开发者群体提供的集成低代码/无代码开发平台。平台提供以数据、模型驱动的企业级低代码开发工具，替代以传统代码驱动的开发方式，使得生产方式本身发生变化。平台集成了各类开源开发工具和开发组件，丰富以可视化、组态式为主要特征的集成开发环境，满足企业级用户拖拉拽方式快速高效生成工业APP的需求；提供以多语言、低代码为主要特征的低代码开发环境，满足社会化开发者群体自主研发工业APP的需求通过可视化编程技术实现工业APP的快速开发，促进业务人员与技术人员的融合协同，实现全面开发APP的能力。

图2为低代码元数据的结构示意图，如图2所示，低代码元数据是一种用来定义低代码APP的数据结构，一般一个低代码APP由APP、菜单导航、视图、页面、控件、对象、模型到表列等元数据组成，通过可视化编程来生成元数据。低代码平台会提供各种可视化设计器，通过设计器开发者能够采用简单拖拉拽的方式实现可视化编程：创建应用，创建视图、页面，并拖拉拽控件生成页面，底层相关的对象、模型、字段都会自动生成，最终生成如图2所示的元数据结构，这些元数据结构都会物化保存到数据库中。举例而言，开发者在可视化开发页面中，平台会生成或修改多个元数据，譬如一个页面的创建，一般会生成表、列、实体模型、字段、页面、控件等元数据。

图3为实体模型的基表的示意图，如图3所示，下面以实体模型的元数据为例，实体模型代表一个基本的业务实体或概念(例如，客户、联系人、设备)，实体模型对会对应一个基表，核心的数据会来自该基表的字段(Fields)集合组成，每个字段都与基础表的特定列相关联。如图3所示，左侧的实体模型基表为现有技术中实体模型的基表内容，右侧的实体模型基表为在本申请中实体模型的基表内容，两者相比，在本申请中的基表内容中增加了三项内容，分别为：APP_ID(APP编号)、VENDOR_NAME(开发者编号)、Sign(签名信息)。

在用户利用低代码开发平台开发应用时，首先对低代码平台进行加密狗的授权，在授权信息中烧录开发者信息，授权狗由中心化低代码开发平台统一颁发，保证企业之间开发者信息的唯一性，图4为平台为用户授予唯一的开发者信息的流程图。企业独立安装supIDE后，只有导入授权信息(license)才能激活平台并使用。开发者创建APP后会生成全球唯一的APP ID，平台会通过读取授权狗中的开发者信息，为APP定义APP开发者信息，可保证APP级别的知识产权保护。

开发者编号具有唯一性，由低代码开发平台颁发给用户，用户无法自行进行修改，在用户利用低代码开发平台开发应用时，会将用户对应的开发者编号写入应用中。

关于Sign(签名信息)，签名信息内包含了加密后的APP编号、开发者编号及其他低代码元数据的相关信息，如图3所示，其他低代码元数据的相关信息包括但不限于以下内容：名称、别名、基表、类型等，具体的内容视低代码元数据而定，不同类型的低代码元数据对应的信息各不相同，在此不作限定。

在S101中提出了“向第一低代码元数据中添加第一签名信息”，其中的第一签名信息中包括但不限于有第一开发者的版权信息、名称、类型等内容，其中第一开发者的版权信息可以指开发者编号。这里提到的第一低代码元数据、第一签名信息、第一开发者中的“第一”只是用于与其他的同类信息进行区分，并不具有顺序的含义。

S102：所述第一签名信息进行加密以生成第一签名文件，所述第一签名文件中包括的所述第一版权信息在所述第一低代码元数据被修改时不变。

签名信息中包括加密后的低代码元数据信息的字段，利用加密算法对签名信息进行加密形成签名文件，并保存在数据库中，便于后续签名文件的比对。

具体的加密算法可以采用非对称加密算法，非对称加密算法采用公钥(publickey)和私钥(privatekey)两种不同的密钥来进行加解密。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密，反之亦然。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

非对称加密算法实现机密信息交换的基本过程是：甲方生成一对密钥并将公钥公开，需要向甲方发送信息的其他角色(乙方)使用该密钥(甲方的公钥)对机密信息进行加密后再发送给甲方；甲方再用自己私钥对加密后的信息进行解密。甲方想要回复乙方时正好相反，使用乙方的公钥对数据进行加密，同理，乙方使用自己的私钥来进行解密。

具体地，非对称加密指的是根据特殊规则生成两把密钥A和B，分别叫做公钥和私钥。私钥自己保留，公钥则分发给其他用户用来和自己通信，理论上生成的两把密钥选择哪一把作为私钥都可以，但是出于效率和安全等方面的要求，公钥和私钥再生成时会给出特殊的条件，所以在实际使用过程中，两者通常是不会互换的。通俗的讲，公钥用于加密需要传送的报文，报文只想给特定的用户看到，所以只有拥有对应的私钥的特定的用户才能解密这个报文。所以只有对应私钥持有人才能看到报文的内容。

常见的非对称加密算法有RSA算法和ECC算法。其中RSA算法是目前最有影响力的公钥加密算法，也是被普遍认为是目前最优秀的公钥方案之一。RSA算法是第一个能同时用于加密和数字签名的算法，也易于理解和操作。RSA是被研究得最广泛的公钥算法。ECC(椭圆加密算法)是一种公钥加密体制，主要优势是在某些情况下它比其他的方法使用更小的密钥——比如RSA加密算法——提供相当的或更高等级的安全。不过一个缺点是加密和解密操作的实现比其他机制时间长。它相比RSA算法，对CPU消耗严重。在本申请的实施例中，对于加密算法不作限制，只要是能够保证低代码元数据的安全性的加密算法均可使用。

加密后的签名文件需要保存在低代码平台的数据库中，在数据库中不同的低代码元数据均有其对应的元数据表用于保存信息。

当开发者在平台进行可视化编程中，相关的元数据包括开发者信息都会通过由平台提供的非对称签名加密算法对数据加密并生成签名文件，开发者每一次修改代码元数据都可以通过非对称加密算法重新生成签名文件并保存到元数据表中。由于签名文件中包含了开发者的版权信息，所以可以达到可溯源的目的，一旦发生知识产权问题，可通过签名文件比对来达到版权保护的目的。

图5为低代码元数据防篡改的方法流程图，如图5所示，当有用户直接修改了保存在数据库中的低代码元数据对应的签名文件中的信息，如：直接修改表S_BUSCOMP中某条数据的类型字段，从TEXT修改为了DATE，从而生成了新的签名文件。那么此时若通过低代码平台查看该低代码元数据，低代码平台将进行签名文件的比对，将该低代码元数据之前保存的签名文件与新的签名文件进行比对，若比对检查后发现修改后的数据生成的签名与数据库中之前保存的签名文件不一致(由于类型字段的数据变动，导致生成的签名文件中的数据与之前不符)，那么此时低代码平台会认定低代码元数据被篡改，于是通过重新导入该低代码元数据或是回滚至上一版本的低代码元数据进行修复，如此实现了防止低代码元数据被篡改。

通过加密后生成签名文件并保存在数据库中，可以有效防护源代码数据被篡改，如果存在非平台修改数据库中的低代码元数据的信息，修改后会自动生成新的签名文件。平台会利用之前保存在数据库中的签名文件与新生成的签名文件进行签名比对，若发现签名文件比对不上，则证明低代码元数据被篡改了，那么这部分代码关联的逻辑将无法使用，开发者只能通过平台的代码回滚或重新导入低数据元代码解决。

在本申请中的低数据元代码平台可以为低代码元数据生成对应的签名文件，且在本平台内针对同一低代码元数据进行合法修改，修改后的低代码元数据新生成的对应的签名文件与其之前的签名文件内容保持一致，不会出现签名文件比对不上的情况。关于签名文件的比对，在低代码元数据需要被使用的时候都会进行。

在本申请的低代码平台中，当页面或其他元数据通过平台的复制粘贴等达到复用代码的目的时，平台会继续保留元数据原始开发者的信息，其他开发者可以继续修改代码，但是原始著作的版权信息，也可以说是原始的开发者编号不会改变，平台不会因为代码在哪个平台而使用哪个平台的开发者信息，这样可以保证代码在不同平台流转过程中，代码的原始作者信息会一直保留。在算法上，一旦元数据创建，平台会一直保留原始开发者信息，后续元数据的签名会依据开发者信息等生成签名。这样当低代码元数据在不同平台流转中，一个低代码元数据中会保留不同企业的低代码元数据的版权信息，为后面当发生企业知识产权纠纷中提供很好的依据。

通俗的讲，低代码元数据是可以被修改的，可以由开发该低代码元数据的人进行修改，也可以由其他人进行修改。但是修改的过程需要在低代码平台进行，修改的方式也可以分为两类，一种是在原始的低代码元数据的基础上进行修改，一种是在该低代码元数据采用新增的方式进行二次开发。如果采用的是第一种修改方式的话，那么该低代码元数据的原始的开发者编号不会发生改变；如果是采用第二种修改方式的话，那么该低代码元数据的原始的开发者编号不会改变，但是新增部分的低代码元数据对应的开发者编号将是完成新增部分的那个开发者对应的开发者编号。

若是在其他平台直接修改数据库中保存的低代码元数据并生成新的签名文件，低代码平台会根据低代码元数据之前保存在数据库中的签名文件与新的签名文件进行比对，若比对不一致则认定低代码元数据被篡改，该低代码元数据将无法被使用。

除了在低代码平台的底层对低代码元数据通过生成加密的签名文件进行签名保护，平台为提升开放性，也提供了导入导出低代码元数据或部分低代码元数据的功能。导出的格式为文件格式，平台对低代码元数据进行了了知识产权的保护，也就是进行签名保护且签名文件中保存有原始的开发者的编号。文件通过平台自研的对称加密生成，默认的导入导出会通过当前平台的加密狗开发者信息生成的散列值进行加解密。如果企业有分享低代码元数据的需求，可以通过平台提供的授权功能，通过填入对方开发者信息的方式来加密源代码数据，然后对方平台就可以继续使用自身的授权狗来完成源代码到解密并导入。通过非平台的授权机制，对加密混淆的源代码文件的修改都会导致文件损害，无法进行分发。图6为元数据的保存及导出的示意图。如图6所示，开发者通过低代码平台开发应用(APP)，此时低代码平台会对应生成相关的低代码元数据，而且会同时携带有APP_ID、开发者信息等进行数据签名，签名后保存至数据库，数据库中包含有视图、页面、控件、对象、模型、字段、表、列等数据，并携带有签名信息防止被篡改。当低代码元数据需要导出时，可以选择导出整个APP的元数据，也可以选择导出部分元数据，在导出整个APP的元数据时需要对APP的低代码元数据(源代码)进行加密混淆，在导出部分元数据时需要对该部分元数据进行加密混淆。

图7为企业间应用低代码元数据的版权保护的流程图，如图7所示，具体为：

当企业用户A利用低代码开发平台开发出了低代码元数据，且企业用户A将该低代码元数据通过低代码平台授权给企业用户B。那么此时，企业用户A通过低代码平台A导出授权给企业用户B的低代码元数据(根据授权机制，只有企业用户B能够导入该低代码元数据)。企业用户B通过低代码平台B导入企业用户A提供的该低代码元数据，企业用户B可以对该低代码元数据进行二次开发，企业用户B在对该低代码元数据进行开发的过程中新增的部分对应的版权信息会保存为企业用户B的版权信息，若企业用户B仅是在该低代码元数据的基础上进行修改，而不存在额外新增的部分，那么该低代码元数据的版权信息仍为企业用户A的版权信息。

S103：将所述第一签名文件保存在所述低代码平台的数据库中。

在本申请实施例中，首先生成第一低代码元数据，并向第一低代码元数据中添加第一签名信息，第一签名信息包括第一低代码元数据的第一开发者的第一版权信息。然后对第一签名信息进行加密以生成第一签名文件，第一签名文件中包括的第一版权信息在第一低代码元数据被修改时不变。最后将所述第一签名文件保存在所述低代码平台的数据库中。如此，通过对于低代码元数据的开发者的版权信息进行加密保存，且当开发者所开发的低代码元数据被修改时，低代码元数据中之前所保存的开发者版权信息保持不变。同时当低代码元数据在不同平台上进行分享时，该低代码元数据的原始开发者的版权信息保持不变，便于后续对于该低代码元数据的溯源以及对该低代码元数据的知识产权的保护。

本申请实施例中还提供了一种低代码元数据保护的系统，图8为一种低代码元数据保护的系统的结构示意图，如图8所示，系统具体包括：

签名模块100，用于生成第一低代码元数据，并向所述第一低代码元数据中添加第一签名信息，所述第一签名信息包括所述第一低代码元数据的第一开发者的第一版权信息；

加密模块200，用于所述第一签名信息进行加密以生成第一签名文件，所述第一签名文件中包括的所述第一版权信息在所述第一低代码元数据被修改时不变；

保存模块300，用于将所述第一签名文件保存在所述低代码平台的数据库中。

在可选的实现方式中，所述第一开发者的第一版权信息，具体包括：所述第一开发者的开发者编号，所述开发者编号由所述低代码平台预先配置且具有唯一性。

图9为利用低代码元数据新建应用的界面显示示意图，如图9所示，图中的开发者组织编号具有唯一性且不能够被修改。

在可选的实现方式中，当所述第一低代码元数据被修改的方式具体为：维持所述第一低代码元数据不变，并在所述第一低代码元数据的基础上新增低代码元数据以得到第二低代码元数据，所述系统具体用于：

利用签名模块100向所述第二低代码元数据中添加第二签名信息，所述第二签名信息包括所述第二低代码元数据的第二开发者的第二版权信息；

利用加密模块200将所述第二签名信息进行加密以生成第二签名文件，所述第二签名文件中包括的所述第二版权信息在所述第二低代码元数据被修改时不变；

利用保存模块300将所述第二签名文件保存在所述低代码平台的数据库中。

在可选的实现方式中，当所述第一低代码元数据被修改的方式具体为：直接对所述第一低代码元数据进行修改以得到第二低代码元数据，所述系统具体用于：

利用签名模块100向所述第二低代码元数据中添加第二签名信息，所述第二签名信息包括所述第一签名文件中的所述第一版权信息；

利用加密模块200将所述第二签名信息进行加密以生成第二签名文件，所述第二签名文件中包括的所述第二版权信息在所述第二低代码元数据被修改时不变；

利用保存模块300将所述第二签名文件保存在所述低代码平台的数据库中。

在可选的实现方式中，所述加密模块200具体用于：

利用非对称加密算法对所述第一签名信息进行加密并生成第一签名文件，当对所述第一低代码元数据进行修改并得到所述第二低代码元数据时，使用非对称加密算法对所述第二低代码元数据的第二签名信息重新进行加密，并生成对应的第二签名文件。

在可选的实现方式中，所述系统具体用于：

所述低代码平台对所述第一签名文件及第三签名文件进行比对并得到比对结果，根据所述比对结果判断所述第一低代码元数据是否被篡改。

若所述比对结果为所述第三签名文件与所述第一签名文件不一致，则认定所述第一低代码元数据被篡改，且所述第一低代码元数据停止使用；

若所述比对结果为所述第三签名文件与所述第一签名文件一致，则认定所述第一低代码元数据未被篡改。

在可选的实现方式中，所述系统具体用于：

第一用户通过所述低代码平台导出第一低代码元数据，所述第一低代码元数据已由所述低代码平台授权给非所述低代码平台的其他平台的第二用户；

所述第一用户利用所述第二用户的第二版权信息为所述第一低代码元数据进行加密并发送至所述第二用户，所述第二版权信息包括所述第二开发者的开发者编号，所述开发者编号由所述低代码平台预先配置且具有唯一性；

所述第二用户利用所述第二用户的第二版权信息对所述第一低代码元数据进行解密，并完成对所述第一低代码元数据的导入。

通过上述提供的一种低代码元数据保护的系统能够实现对于低代码元数据的开发者信息进行产权保护。

本申请实施例还提供了对应的设备以及计算机可读存储介质，用于实现本申请实施例提供的方案。

其中，所述设备包括存储器和处理器，所述存储器用于存储指令或代码，所述处理器用于执行所述指令或代码，以使所述设备执行本申请任一实施例所述的一种低代码元数据保护的方法。

在实际应用中，所述计算机可读存储介质可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本实施例中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述，仅为本申请的一种具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (10)

1.一种低代码元数据保护的方法，其特征在于，应用于低代码平台，所述方法包括：

生成第一低代码元数据，并向所述第一低代码元数据中添加第一签名信息，所述第一签名信息包括所述第一低代码元数据的第一开发者的第一版权信息；

所述第一签名信息进行加密以生成第一签名文件，所述第一签名文件中包括的所述第一版权信息在所述第一低代码元数据被修改时不变；

将所述第一签名文件保存在所述低代码平台的数据库中。

2.根据权利要求1所述的方法，其特征在于，所述第一开发者的第一版权信息，具体包括：

所述第一开发者的开发者编号，所述开发者编号由所述低代码平台预先配置且具有唯一性。

3.根据权利要求1所述的方法，其特征在于，当所述第一低代码元数据被修改的方式具体为：维持所述第一低代码元数据不变，并在所述第一低代码元数据的基础上新增低代码元数据以得到第二低代码元数据，所述方法还包括：

向所述第二低代码元数据中添加第二签名信息，所述第二签名信息包括所述第二低代码元数据的第二开发者的第二版权信息；

将所述第二签名信息进行加密以生成第二签名文件，所述第二签名文件中包括的所述第二版权信息在所述第二低代码元数据被修改时不变；

将所述第二签名文件保存在所述低代码平台的数据库中。

4.根据权利要求1所述的方法，其特征在于，当所述第一低代码元数据被修改的方式具体为：直接对所述第一低代码元数据进行修改以得到第二低代码元数据，所述方法还包括：

向所述第二低代码元数据中添加第二签名信息，所述第二签名信息包括所述第一签名文件中的所述第一版权信息；

将所述第二签名信息进行加密以生成第二签名文件，所述第二签名文件中包括的所述第二版权信息在所述第二低代码元数据被修改时不变；

将所述第二签名文件保存在所述低代码平台的数据库中。

5.根据权利要求1所述的方法，其特征在于，所述第一签名信息进行加密以生成第一签名文件，包括：

利用非对称加密算法对所述第一签名信息进行加密并生成第一签名文件，当对所述第一低代码元数据进行修改并得到所述第二低代码元数据时，使用非对称加密算法对所述第二低代码元数据的第二签名信息重新进行加密，并生成对应的第二签名文件。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述低代码平台对所述第一签名文件及第三签名文件进行比对并得到比对结果，根据所述比对结果判断所述第一低代码元数据是否被篡改。

7.根据权利要求6所述的方法，其特征在于，所述根据所述比对结果判断所述第一低代码元数据是否被篡改，包括：

若所述比对结果为所述第三签名文件与所述第一签名文件不一致，则认定所述第一低代码元数据被篡改，且所述第一低代码元数据停止使用；

若所述比对结果为所述第三签名文件与所述第一签名文件一致，则认定所述第一低代码元数据未被篡改。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

第一用户通过所述低代码平台导出第一低代码元数据，所述第一低代码元数据已由所述低代码平台授权给第二用户；

所述第一用户利用所述第二用户的第二版权信息为所述第一低代码元数据进行加密并发送至所述第二用户，所述第二版权信息包括所述第二开发者的开发者编号，所述开发者编号由所述低代码平台预先配置且具有唯一性；

所述第二用户利用所述第二用户的第二版权信息对所述第一低代码元数据进行解密，并完成对所述第一低代码元数据的导入。

9.根据权利要求7所述的方法，其特征在于，所述若所述比对结果为所述第三签名文件与所述第一签名文件不一致，则认定所述第一低代码元数据被篡改，还包括：

若认定所述第一低数据元代码被篡改，所述低代码平台重新导入所述第一低数据元代码。

10.一种低代码元数据保护的系统，其特征在于，所述系统包括：

签名模块，用于生成第一低代码元数据，并向所述第一低代码元数据中添加第一签名信息，所述第一签名信息包括所述第一低代码元数据的第一开发者的第一版权信息；

加密模块，用于所述第一签名信息进行加密以生成第一签名文件，所述第一签名文件中包括的所述第一版权信息在所述第一低代码元数据被修改时不变；保存模块，用于将所述第一签名文件保存在所述低代码平台的数据库中。

Images