CN116756727B - 一种数据权限控制方法、装置、电子设备和存储介质 - Google Patents

Abstract

本发明提出了一种数据权限控制方法、装置、电子设备和存储介质。本发明的数据权限控制方法包括：1）对应用程序客户端发起的请求添加用户信息和业务信息；2）在应用程序服务端拦截SQL语句并将其解析为语法树；3）在应用程序服务端对客户端配置的数据权限规则进行规范；4）在应用程序客户端配置数据权限规则；5）应用程序服务端判断用户操作是否受数据权限规则限制；6）基于数据权限规则修改语法树，进行数据权限控制。采用本发明数据权限控制方法，可免去遍历操作SQL语句的步骤，并且通过可配置的方式来配置并管理数据权限，降低了实现的复杂度。

Description

一种数据权限控制方法、装置、电子设备和存储介质

技术领域

本发明涉及信息系统中的数据权限控制领域，具体涉及一种基于SQL语法树的数据权限控制方法和系统。

背景技术

数据权限控制是软件系统中的常见功能，作为软件系统的一种安全控制机制，用于控制数据的显示或操作，以确保敏感数据的安全性和隐私性，防止未经授权的用户访问和操作数据。它可以帮助维护数据的完整性和准确性，提高数据的安全性，降低数据泄露的风险。

目前主流的数据权限控制方法可以归类为基于角色的访问控制（RBAC, RoleBased Access Control）和基于属性的访问控制（ABAC, Attribute Based AccessControl）等。在技术实现上，大部分系统都通过修改SQL语句以达到控制数据访问权限的目的。然而，数据权限控制本身需要频繁进行SQL查询操作，不同的修改SQL语句的方式，对系统的开销是有直接影响的。

例如，公开号为CN104484621A的中国专利，公开了一种基于SQL的数据权限控制方法，它的权限管理方式的实现逻辑为：通过关键词FROM，WHERE定位原SQL语句中需要提取的信息并用逗号对原SQL语句进行分割，之后对分割后的SQL语句进行遍历，其目的在于定位需要修改的部分的位置后，通过增加、删除、修改查询条件来实现数据权限的控制。

目前主流的数据权限控制方法有以下两个缺点：

1）系统采用拦截SQL语句、定位关键词、修改查询条件或遍历查询条件的方式来实现权限控制。在数据被频繁要求访问的时候，这样的方式会浪费大量的系统资源，对服务器以及数据库的性能都是一种挑战。

2）在管理端，大部分产品通过单独的权限管理系统进行数据权限的管理配置，这样的管理方式在使用时都有比较繁琐的流程，系统在日常使用中也需要管理人员进行维护，这些维护操作也造成了人力资源的浪费，同时，这些管理方式往往存在配置困难、移植困难、维护困难以及系统复杂度高等问题。

另外，可配置思想也是目前计算机软件中前后端交互系统的主流思想。其核心理念是将一部分配置内容从程序中分离出来，然后将其写入配置文件、数据库、环境变量或其他外部资源中，通过配置文件等与程序进行交互。

常见的可配置思想具体实现过程可分为：通过配置中心的配置方式或者通过客户端的配置方式。第一种方式，通过在配置中心里修改配置文件内容实现配置的实时生效，例如，阿里巴巴的开源框架Nacos就是一个常用的配置中心。第二种方式，通过客户端来配置，通常会将配置存入数据库或系统缓存等类型的外部资源中，这种方式适用于与业务挂钩的功能，也是本发明使用的配置方式。

组件是一种可重用且可替换的软件单元，是将特定的、实现了某功能的代码进行封装使用的代码模块。因此，可配置思想的实现通常与服务端组件相互搭配使用。组件单元化的特性使其只用负责功能上的完整性，因为一个组件只负责一个功能实现，使得组件成为一个轻量级的功能模块，能够快速移植到任何项目中。

将可配置思想应用于数据权限控制，可有助于将普遍的数据权限复杂配置极简化，尽可能多的用简单配置代替复杂的权限配置系统。同时，基于可配置思想的可扩展性，数据权限功能也能封装成组件的形式进行使用，有效减少使用数据权限功能时的复杂操作。

发明内容

本发明提供一种基于SQL语法树的数据权限控制方法，不同于传统上将整段搜索条件根据关键词定位后进行修改，本发明权限控制方法着重于修改并重组SQL语法树的逻辑节点，免去了遍历操作SQL语句的步骤，并且通过可配置的方式来配置并管理数据权限，降低了实现的复杂度。

本发明的第一目的在于提供一种数据权限控制方法，它包括如下步骤：

1）对应用程序客户端发起的请求添加用户信息和业务信息；

2）在应用程序服务端拦截SQL语句并将其解析为语法树；

3）在应用程序服务端对客户端配置的数据权限规则进行规范；

4）在应用程序客户端配置数据权限规则；

5）应用程序服务端判断用户操作是否受数据权限规则限制，如果不受限制，服务端放行该SQL语句，如果受限制，获取SQL语句的数据权限规则；

6）基于数据权限规则修改语法树，进行数据权限控制。

进一步的，所述在应用程序服务端拦截SQL语句并将其解析为语法树包括如下步骤：

1）应用程序服务端创建拦截器，对SQL语句进行拦截，通过SQL语句的真实对象获取SQL的数据权限标识；

2）将拦截到的SQL语句解析为语法树。

进一步的，所述的在应用程序服务端对客户端配置的数据权限规则进行规范包括如下步骤：

1）应用程序服务端列举所有数据权限控制范围；

2）应用程序服务端列举所有客户端能够配置的数据逻辑运算符。

进一步的，所述的在应用程序客户端配置数据权限规则包括如下步骤：

1）配置数据权限规则的关联功能；

2）配置数据库条件语句；

3）配置数据权限标识。

进一步的，所述的在应用程序客户端配置数据权限规则还包括对资源树信息的请求路径进行配置。

进一步的，所述的应用程序服务端判断用户操作是否受数据权限限制包括如下步骤：

1）基于数据权限标识判断是否放行；

2）基于请求属性和请求头信息判断是否放行；

3）未放行时获取数据权限规则。

进一步的，所述的基于数据权限规则修改语法树进行数据权限控制包括如下步骤：

1）获取SQL语句主体部分，并将主体部分转换为表示SQL语句查询语句的对象；

2）获取原SQL语句条件表达式，服务端根据数据权限规则，为每一个原SQL语句的条件表达式创建一个节点；

3）根据原SQL语句的条件表达式是否为空，通过对新生成的节点进行接入或替换操作来修改原SQL语句的条件表达式。

本发明第二目的在于提供一种数据权限控制装置，它包括：

请求修改模块，用于对应用程序客户端发起的请求添加用户信息和业务信息；

请求拦截与解析模块，用于在应用程序服务端拦截SQL语句并将其解析为语法树；

数据权限规范模块，用于在应用程序服务端对客户端配置的数据权限规则进行规范；

数据权限配置模块，用于在应用程序客户端配置数据权限规则；

数据权限规则判断与放行模块，用于在应用程序服务端判断用户操作是否受数据权限限制，如果不受限制，服务端放行该SQL语句，如果受限制，获取SQL语句的数据权限规则；

语法树修改模块，用于基于配置的数据权限规则修改语法树，进行数据权限控制。

本发明第三目的在于提供一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行存储器上所存储的程序，实现上述任一项所述的数据权限控制方法步骤。

本发明第四目的在于提供一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现上述任一项所述的数据权限控制方法步骤。

本发明的有益技术效果：

1）基于可配置思想，服务端数据权限功能以组件的形式实现。不同产品线的开发团队或人员，只需引入该组件，即可实现对语法树的解析与修改，有效提高数据权限功能模块的复用性，解决了权限系统移植困难的问题，做到随时引用、随时应用。同时，组件的引用形式能够减少不同人员修改模块导致的代码混乱，降低故障概率。进一步的，如果后续数据权限功能需要进行升级或维护，也只需要针对组件这样轻量级的模块运营，并不需要对以系统为规模的项目进行升级维护。

2）基于拦截、解析并操作SQL语法树来实现数据权限控制，应用程序在数据权限方面的代码与业务逻辑相互解耦，降低了代码重构和维护的难度。服务端通过修改SQL语法树结构进行权限控制，相比其他权限控制方法，有效避免了通过迭代定位关键词方法带来的程序复杂的问题，大大降低程序的复杂度。同时，通过限制查询的方式间接控制其他数据库操作的实施，使得本发明只用专注于处理查询条件，省去了针对所有SQL操作进行判断并逐一操作带来的复杂性和冗余，进一步降低了整个功能实施上的复杂性，满足了整个数据权限组件的轻量级需求。

3) 对客户端请求头内容进行修改，将业务按钮和用户信息存入请求头，大大减少服务端访问数据库获取这些信息的频率，从而减小服务器的开销，加快整个应用程序的响应速度。

4）基于可配置思想，配置的数据权限规则具有很强的扩展能力，可以针对简单的单条件限制提供最基础的数据权限配置、针对复杂的树状结构信息进行权限配置以及根据用户需求对复杂条件进行配置。在实际应用上只需在应用服务客户端进行简单的配置，无需修改代码、无需重新部署即可使用。

5）支持应用程序客户端在配置数据权限后实时生效。配置数据权限如更改数据权限可视范围、新增新的数据权限配置、删除已有的数据权限配置、修改可见字段等。配置后，无需重新部署应用程序服务端，即时更新缓存，即时生效，可降低应用程序服务端运维的复杂度。

综上所述，本发明的数据权限控制方法，能大幅度提高整个系统的数据安全性、完整性与可靠性。同时，可配置思想降低了配置的复杂度，且配置修改能够实时生效，避免了配置复杂、实施复杂等问题。功能实现上，通过针对查询结果间接控制其他数据库操作的方法以及针对SQL语法树节点的修改，能够降低开发工作量，同时降低系统的运维难度。

附图说明

图1是本发明实施例数据权限控制方法的步骤图；

图2是本发明实施例客户端进行处理后请求头结构的示意图；

图3是本发明实施例拦截、放行和修改SQL语句的流程图；

图4是本发明实施例对SQL语法树的条件语句WHERE的语法树结构分析图；

图5是本发明实施例服务端对客户端特殊规则条件配置的处理对照图；

图6是本发明实施例服务端对数据权限整体处理逻辑的流程示意图；

图7是本发明实施例中针对“SELECT ID, NAME FROM USERS WHERE ID = 1;”语句的语法树结构示意图；

图8是本发明实施例中针对“SELECT ID, NAME FROM USERS;”语句的语法树结构示意图；

图9是对图7实施例中进行数据权限控制后的语法树结构示意图；

图10是对图8实施例中进行数据权限控制后的语法树结构示意图。

具体实施方式

为了进一步理解本发明，下面结合实施例对本发明优选实施方案进行描述，但是应当理解，这些描述只是为进一步说明本发明的特征和优点，而不是对本发明权利要求的限制。

本实施例涉及的数据权限管理，是针对具体角色下用户对具体数据库操作进行限制，涉及具体的数据库操作业务，优选通过应用程序客户端配置的方法来实现可配置的方案。

为了完成数据权限控制，如图1所示，本发明实施例采用以下步骤。

S1、对应用程序客户端发起的请求添加用户信息和业务信息。

信息系统确定一个用户的数据权限，并针对其拥有的数据权限范围对SQL语法树进行修改，需要获取大量信息来鉴权或判断。因此在高并发系统中，若不能灵活的运用请求或者缓存负载信息，可能会导致应用程序运行时产生过大的数据库访问量，造成系统堵塞等一系列严重问题。本实施例需要对应用程序客户端发起的请求做一定修改，以确保服务端能以更快的响应速度处理业务请求中的数据权限控制。

现有的客户端和服务端主要通过HTTP协议通信。HTTP请求头是HTTP协议中的一部分，用于在客户端与服务端之间传递附加的信息和元数据。一个HTTP请求头中，除了HOST和USER_AGENT等必须携带的部分外，还可以自定义添加一些内容。如表1所示，本实施例在请求头中添加一个名为biz-Header的头域用于存储业务信息。业务信息可以是用户操作一个WEB页面上的按钮所产生的信息。按钮是在应用程序中常用的可让用户点击调用业务逻辑的操作媒介，例如，WEB页面中的可用鼠标操作的“点击搜索”等都是按钮。在请求发起时，客户端将按钮信息存入一个JSON对象，并将此JSONObject存入请求头的业务信息中发送至服务端。修改后HTTP请求头结构信息如图2和表1所示。

表1 修改后的HTTP请求头

考虑到数据权限与操作用户信息的强关联性，本实施例也将在客户端操作的用户信息存入请求头中，在请求头中添加一个名为current_user的头域，在域值中写入当前请求用户信息。用户信息包括身份标识（如用户ID、用户名）和客户端标识（如客户端ID）。将涉及数据权限操作的用户信息，通过应用程序客户端传给服务端，而非频繁在服务端进行数据库操作，有助于减小服务器开销，提升服务端的响应速度。

本实施例的客户端发起的请求，在请求头中包含了新添加的用户信息和业务信息。需要说明的是，由于携带了如用户信息之类的敏感信息，为防止信息泄露，可通过API报文加密或其他方式对信息进行加密处理。

如图2所示，HTTP报文包括HTTP请求头，HTTP请求头中新增了“当前用户信息”和“存储按钮信息的JsonObject”，并对“当前用户信息”这个敏感信息进行加密。

S2、在应用程序服务端拦截原SQL语句并将其解析为语法树。

要在应用程序服务端要创建SQL拦截器，服务端需要结合实际使用的持久层框架。持久层框架是一种常用的开发工具，用于简化和优化数据的存储过程，使开发人员能够更便捷地对数据库进行操作。一般应用程序都会采用特定的框架进行应用程序服务端的持久层开发，无论采用哪种框架，都有对应的拦截器供开发者使用。

S21、应用程序服务端创建拦截器，对原SQL语句进行拦截，通过原SQL语句的真实对象获取SQL的数据权限标识。

S211、创建拦截器，对原SQL语句进行拦截，并将拦截到的代理对象还原为真实对象。

本实施例应用程序服务端基于MyBatis框架实现持久层业务，MyBatis框架是一款半自动的ORM（Object Relation Mapping对象关系映射）持久层框架，支持定制化SQL、存储过程以及高级映射。本实施例通过实现MyBatis框架的拦截器，对数据库操作进行拦截和处理，以实现对SQL语句的拦截和修改。在本实施例中，MyBatis框架的拦截器采用其自带的Interceptor，Interceptor作为该框架的一种拦截器，用于对MyBatis的操作进行拦截和处理。

需要说明的是，拦截器拦截到的内容，并不是真正的SQL语句，而是经过代理的对象。代理对象是一个用来代替真实对象的概念，其具有与真实对象相同的接口，但在某些情况下，它也有可能隐藏真实对象的实现细节等内容。因此，在Mybatis框架下，服务端需要将代理对象进行还原，还原为携带了原SQL信息的真实对象，以便进行后续操作。比如，原SQL信息的真实对象在Java编程语言中是StatementHandler对象，Mybatis框架下还原StatementHandler是很常用的一项技术，在此不做赘述。

S212、通过真实对象获取原SQL语句数据权限标识。

在本发明实施例中，服务端将通过上一步骤中转换得到的真实对象获取针对每一条具体SQL语句的唯一标识，将该值作为SQL数据权限标识，并作为后续标识一条客户端配置的数据权限规则的标识符。需要说明的是，SQL语句的唯一标识，可以根据使用的不同框架自主进行选择。在本发明实施例中，服务端采用Mybatis框架的映射文件的唯一标识符MapperId作为SQL语句的唯一标识。

在后续步骤，客户端配置完成数据权限后，服务端会同步将配置的数据权限标识存入缓存。在业务逻辑运行时，每当服务端接收到带SQL语句的请求时，会通过本步骤从被拦截的SQL请求中获取数据权限标识，并判断该标识是否存在于缓存中。如果存在，即表示该次数据库操作受数据权限范围影响，该次操作将会被数据权限组件来处理。

MapperId是Mybatis框架SQL语句映射文件中的唯一标识符，用来标识当前用户的SQL操作。MapperId是由服务端业务代码中的映射文件所在位置的全限定类名和方法名组合而成。如结构为“com.test.common.mapper.selectUserById”这样类型的字符串就是映射文件标识MapperId。获取MapperId的方法在Mybaits框架的官方文档中都有详细的指导，在此不做过多赘述。服务端在获取MapperId后，将该值作为一条SQL语句的数据权限标识。

至此，拦截器对原SQL语句的拦截工作就完成了，经过拦截和对数据的处理，服务端获得了重要的数据权限标识。

S22、将拦截到的原SQL语句解析为语法树。

SQL语句的解析需要用到解析器，当前市面上有大量的开源解析器提供给开发人员使用。在本实施例中，服务端借助于开源工具JSQLPaser完成SQL语句的解析，将SQL语句转化为一棵语法树。以下是将SQL语句解析为语法树的一个实施例，具体步骤如下：

S221、获取原SQL语句的字符串。

本实施例中，服务端可以从S211获取的真实对象中获取原SQL语句的字符串。该字符串即为用户在实际操作系统的过程中产生的原SQL语句。获取过程在开源工具JSQLParser的官方说明中有详细描述，在此不进行赘述。

S222、将原SQL语句解析为一棵语法树。

获取到原SQL语句后，服务端通过解析器将原SQL语句解析为一棵SQL语法树。该语法树表示经过解析后的原SQL语句对象，它包含了很多原SQL信息，例如操作类型（增、删、查、改）、数据表名、数据字段名、操作符和表达式等。

在Java编程语言中，SQL语法树的根节点是Statement节点。在本发明实施例后续的修改语法树步骤中，将以SQL语法树的根节点作为起点，逐层定位SQL语句中的信息并修改语法树上的节点。通过这种方式，可解决当前大部分数据权限系统通过遍历关键词的方式定位语句、修改语句带来的服务资源浪费情况。

S3、在应用程序服务端对客户端配置的数据权限规则进行规范。

采用可配置思想进行数据权限的控制是本发明实施例的一个创新点，其为数据权限的配置带来了简洁化、组件化的便利，让该实施例的数据权限控制摆脱了单独的管理系统而独立存在。然而，配置简洁化也带来了一些问题，过于灵活和简洁的配置偶尔会导致用户对数据权限进行错误配置，该配置将在后续修改语法树步骤中会直接影响语法树结构。为防止因用户错误配置导致数据权限不生效甚至产生脏数据，本实施例在应用程序服务端拦截并将原SQL语句解析为语法树后，还需在应用程序服务端对客户端配置的数据权限规则进行规范。

本实施例在应用程序服务端对客户端配置的数据权限规则进行规范包括以下两个方面：

S31、应用程序服务端列举所有数据权限控制范围。

应用程序服务端通过创建配置类，列出所有的数据权限控制范围常量。服务端通过该常量对权限生效的范围进行控制。本实施例对数据权限可控制范围的配置，是通过对数据权限控制范围常量使用占位符进行赋值来实现。在实际运行过程中，服务端将根据具体的服务器时间、当前访问数据库的用户ID、部门等信息，对范围常量进行具体赋值。

数据权限控制范围常量的引入，使得客户端无需再对权限的生效范围进行配置，具体的值，会由服务端在具体运行过程中进行赋值。因此，该数据权限控制范围常量这个概念的引入，使得本发明实施例对整个数据权限的配置更加简洁灵活。这也是本发明实施例中基于可配置思想的一个体现。

本实施例中列举的数据权限控制范围常量：

USER_NAME_CONTEXT用户名上下文：使用该上下文表示此用户名用户只能访问其拥有的权限。

USER_ID_CONTEXT用户ID上下文：限制该ID的用户只能访问其拥有的权限。

USER_ORG_NO_CONTEXT用户部门上下文：用于表示当前用户所属的部门编号或组织编号。通过该上下文，可以基于部门级别来限制用户对数据的访问权限，确保用户只能查看或操作其所属部门的数据。

SYS_DATE_CONTEXT系统日期上下文：用于表示当前系统日期。可以使用该上下文来限制数据权限在特定日期范围内生效，或者在某个日期之前或之后的数据可见。

SYS_TIME_CONTEXT系统时间上下文：用于表示当前系统时间。类似于系统日期上下文，可以使用该上下文来限制数据权限在特定时间范围内生效，或者在某个时间之前或之后的数据可见。

USER_POST_NO_CONTEXT用户岗位上下文：用于表示当前用户的岗位编号。通过该上下文，可以根据用户的岗位来限制其对数据的访问权限，确保用户只能访问其岗位所关联的数据。

S32、应用程序服务端列举所有客户端能够配置的数据逻辑运算符。

应用程序服务端通过创建配置类，列出所有支持的逻辑运算符常量。在后续应用程序客户端配置数据权限规则步骤中，客户端配置的数据权限规则条件必须在所有支持的逻辑运算符常量中。

本实施例列举的逻辑运算符常量如下：

EQUALS等于，NOT_EQUALS不等于，GREATER_THAN大于， ESCAPE_GREATER_THAN大于转换符，MINOR_THAN小于，ESCAPE_MINOR_THAN小于转换符，GREATER_THAN_EQUALS大于等于，ESCAPE_GREATER_THAN_EQUALS大于等于转换符，MINOR_THAN_EQUALS小于等于，ESCAPE_MINOR_THAN_EQUALS小于等于转换符，IS_NULL为空，IS_NOT_NULL不为空，LIKE模糊等于，LIKE_NOT模糊不等于，BETWEEN介于之间，NOT_BETWEEN不介于之间，IN包含，NOT_IN不包含，NOT_AUTH不可见，USER_CUSTOM用户自定义。

需要说明的是，以上数据操作逻辑运算符常量和数据权限控制范围常量可以根据实际使用情况进行调整。

本步骤对数据权限规则所做的规范将在后续修改SQL语法树步骤中生效，具体生效方式将在后续步骤中阐述。需要注意的是，本步骤为服务端的一个规范操作，其实施顺序并非一定要在S2步骤后实施，该规范步骤可以在S1或S2步骤前后进行实施。

S4、在应用程序客户端配置数据权限规则。

基于可配置思想，本实施例可根据不同用户需求配置不同规则供用户使用。如：

针对简单的单条件限制提供最基础的数据权限配置，本实施例中定义为默认规则。

为了应对复杂的树形结构资源，如：门户树、部门树等，本发明实施例基于可配置思想，提供资源树结构配置方式，在本发明实施例中定义为资源树规则。通过该配置规则可自动装配选择资源的ID进行数据隔离，无需手动查找需要保护的敏感资源ID信息，是一种以更便捷更迅速的方式对资源进行保护的配置规则。

当默认规则和资源树规则数据权限规则无法满足需求时，可提供对规则的自定义设置。它可以针对复杂条件进行配置。本实施例中将这个规则定义为自定义规则。

本实施例通过资源树规则和自定义规则配置功能的拓展能力，提供给用户强大的数据权限配置功能。

每种规则都需要对配置项进行配置。以下是数据权限规则配置步骤：

S41、配置数据权限规则的关联功能

关联功能是配置某操作按钮代表的数据库操作类型，包括编辑、查询、删除等。应用程序客户端通过指定某个按钮，选择按钮代表的关联功能，即完成对关联功能的配置。经过配置的指定按钮，在被点击时，如果使用了跟所配置的关联功能一样的数据库操作类型，则会进行数据权限的控制。

关联功能配置的目的是为了区分不同按钮下的数据权限。例如：在两个不同的菜单页面，用户可以通过关联按钮的功能配置来实现同一操作在不同菜单下的数据权限。虽然两个菜单在服务端里都是调用了同一个数据库操作逻辑，但是受关联功能的影响，查询结果也会完全不同。

需要再次说明的是，这里的编辑、查询、删除等操作，并不是数据权限直接限制编辑、查询、删除这些操作，而是通过数据权限对点击按钮后返回的查询结果进行限制，以此来间接影响编辑、查询、删除等操作。下面用一个例子进行详细说明：

例如，某用户想对A数据进行删除操作，如果删除按钮的数据权限关联功能被设置为“删除”，当用户点击删除按钮时，受数据权限影响，A数据不会被查询到用户浏览的页面上，因此用户无法选中A数据进行删除操作，以此来间接的达到控制用户A操作数据的目的。

S42、配置数据库条件表达式

数据库条件表达式WHERE，代表了一条SQL运行需要满足的条件。在本发明实施例中，针对默认规则、资源树规则的数据库条件表达式配置，用规则字段、规则条件和规则值三个配置项来代表数据库字段、数据库逻辑运算符以及数据库字段对应的值。配置一条数据库的条件语句，表示对该数据权限规则附加条件。

需要注意的是，在默认规则和资源树规则中，规则条件受上述服务端列举的数据逻辑运算符限制，让其可配置项仅限于上述步骤中列举的逻辑运算符范围内。针对自定义规则，配置方法将在后续填写完整的数据库条件语句步骤中叙述。

例如，不希望用户查询到数据库某张数据表中name为A的数据。可在配置关联功能为“查询”后，配置规则字段为name，规则条件为不等于（!=），规则值为A。则会产生一个数据库条件语句name != A。如果该规则对应的SQL语句受数据权限限制，在后续修改SQL语法树步骤中，条件语句将会被拼凑到语法树中，完成对数据权限的控制。需要注意的是，针对自定义规则，配置数据库条件表达式的方法会与上述内容不同。

自定义规则应用于多个查询条件，特殊的如时间范围的限制条件，以及逻辑运算符超过了S3步骤限制范围的情况。因此，在该规则下，客户端去除了对规则条件的约束，以满足让用户自定义数据权限规则的高灵活性。但需要说明的是，由于去除了约束，该规则下的错误和风险也提高了。

针对自定义规则，数据库条件表达式配置不再需要客户端分别配置规则条件、规则字段以及规则值。在该规则下，客户端直接配置数据库的条件表达式。例如，希望对某角色下用户进行数据权限的限定，使其不能够查询NAME LIKE（包含）A并且 gender = male的数据。在应用程序客户端，设定关联功能为“查询”，因去除了规则条件、规则字段以及规则值的配置，用户可以配置：“name like A and gender = male”。该条件在后续操作中，将被解析为两棵子树，并通过一定的判断后以合适的方式拼接在原SQL语法树上，完成数据权限的控制。

S43、配置数据权限标识

本实施例步骤的数据权限标识，是表示客户端对具体SQL语句的数据权限规则进行的配置。本实施例MyBatis框架下对数据权限规则的配置操作，是指在客户端将需要限制的SQL语句的数据权限标识进行填写，并将填写的数据权限标识存储于数据库中和缓存中。

需要说明的是，本步骤中数据权限标识与前述步骤S212获取原SQL数据权限标识中所述数据权限标识是相等的数据，但两者起到不同的功能和作用。本步骤中的数据权限标识表示客户端配置了针对具体SQL语句的数据权限，应用程序服务端将该步骤配置好的数据权限标识存储于数据库中和缓存中，其目的类似于将在客户端填写的数据权限标识放入了仓库中。而在步骤S212获取的原SQL数据权限标识，并不是从缓存或数据库中得到，而是通过解析被拦截的原SQL真实对象得到。在本步骤配置数据权限标识和步骤S212获取原SQL数据权限标识，二者的作用是为了在后续应用程序服务端判断用户操作是否受数据权限限制步骤中，应用程序服务端将解析出的数据权限标识值放到本步骤存储的数据权限标识仓库中进行比较，以此判断此次操作是否被数据权限所限制。如果解析出的数据权限标识值不存在于本步骤存放数据权限标识的仓库中，则代表本次被拦截的SQL语句不受数据权限的影响。

S44、配置可选项

本实施例的可选项配置，可根据客户端配置需求进行配置，比如，在前述配置项基础上，配置可见字段、备注、开关等。

1）可见字段为该数据权限规则生效后所影响的SQL语句的返回字段。可见字段可同时填写多个，用分隔符如逗号分隔。

例如，客户端配置可选字段为“name, age”，若受该权限规则影响的SQL语句受数据权限限制，返回结果只会有name和age的数据，其他数据将会被隐藏。

2）备注：对当前数据权限规则的备注。

3）开关：启用或停用当前数据权限规则。

需要说明的是，配置可选项非客户端强制要求配置项，如果没有其他自选配置，可以省略该步骤。

通过以上步骤S41-S44，就完成了默认规则的配置。针对资源树规则，还需要做以下额外配置：

路径信息表示查询当前资源树的客户端资源路径。针对资源树规则，客户端还需对资源树信息的请求路径进行配置，填写完整的请求路径信息。需确保该路径正确，以便于让客户端通过调用该路径能够查询整颗资源树的内容。

例如，希望对某角色下用户进行数据权限的限定，限制其无法浏览某企业下的A部门信息，则可以选择资源树规则进行配置。

在配置时，配置关联功能为“查询”，规则条件为不等于（!=），规则字段为name，规则值为a。此外，还需要选择一棵部门资源树，资源树上需要有路径信息，假设为department/info/tree，该路径信息为查询该部门树的接口路径。当选择该资源树后，每当调用该资源树信息，即为该路径时，会自动添加规则“name != a”，由此达到限制该角色下用户查看A部门信息的目的。

资源树规则是为了简化应用中经常要求限制部门等敏感信息的操作而设计的特有的配置模式。该模式通过默认规则配置也能够达到同样效果，但步骤会复杂很多。这也是基于可配置思想下本实施例在操作上带来的便捷之处，大量代码方面的内容被配置取代，带来的不仅是使用上的便捷，也可对配置进行灵活延伸，使复杂配置简化。

需要注意的是，本发明实施例步骤S4是在客户端上进行数据权限配置，与服务端进行的内容是互相独立的。因此，该步骤并非一定要在S3在应用程序服务端对客户端配置的数据权限规则进行规范步骤后进行，可以在S2或S3步骤前后进行实施。

S5、应用程序服务端判断用户操作是否受数据权限限制，如果不受限制，服务端放行该SQL语句，如果受限制，获取SQL语句的数据权限规则，进入S6。

放行的概念是指：将SQL语句不作任何处理直接跳过数据权限组件，由后续业务代码进行处理。因为组件化的核心思想是每一个组件提供单一的功能，数据权限组件是服务端专门用于数据权限控制的模块。因此，在数据权限组件中，不应对除数据权限以外的业务进行干预，如果不受数据权限限制，选择放行，即对SQL语句不作任何处理直接跳过数据权限组件。

在实现逻辑上，数据权限组件将业务逻辑的SQL语句进行了拦截，等于从中间打断了一个系统业务原有的逻辑，因此该处的放行，等同于直接结束数据权限组件的运行逻辑。

本实施例中，服务端判断是否进行数据权限控制的步骤包括：

S51、基于数据权限标识判断是否放行。首先，服务端从缓存中获取S4存入的全部的数据权限标识，当数据库操作请求发送到服务端时，通过S212解析出的数据权限标识来判断目前的数据权限标识是否在缓存中拥有。如果未拥有，说明对于该次请求并未做数据权限的限制，可以直接放行。

S52、基于请求属性和请求头信息判断是否放行。在S1中，在对客户端请求进行修改后，将用户信息和业务信息添加进了请求头中。在本实施例步骤中，服务端在此时取出请求头中的数据，判断是否放行。具体判断流程如下：

S521、获取请求中的请求属性信息，判断是否放行。

本实施例中可以获取请求属性RequestAttributes来判断请求信息的完整性。该属性是一个HTTP请求中传递数据和请求状态的容器。如果无法获取到当前这个属性的值，代表当前请求不完整，可能因为客户端或网络原因产生了一个错误请求。因此此处对该SQL语句放行，由放行后的后续业务逻辑提供报错信息。

S522、获取请求信息中的URL信息，判断是否放行。如果未获取到URL信息，代表该请求信息不完整，因此跳过SQL解析直接放行，由放行后的后续业务逻辑提供报错信息。

S523、获取请求头中的用户信息，判断是否放行。用户信息在请求头中的current_user头域。如果未能获取到用户信息，代表该请求不是从应用程序客户端发送，此时有两种情况：

1）该请求未经过客户端直接访问了服务端，这种情况在开发人员本地调试或者微服务间跨服务调用时会出现。

2）此次客户端请求信息不完整，丢失用户数据。

无论是上述哪种情况，服务端都对SQL操作进行放行。第一种情况，放行的理由是数据权限不应影响开发人员的调试工作或微服务之间的互相调用，以免造成不便。第二种情况，服务端依然选择对SQL语句放行，是因为数据权限组件不应处理业务上的逻辑，交由放行后的后续业务逻辑提供报错信息。

S524、获取请求头中的业务信息，判断是否放行。业务信息在请求头中的biz_header头域，记录了用户的操作信息，例如该操作发生在哪个菜单下。同用户信息一样，如果业务信息为空，表示本次操作为开发人员的本地调试、微服务之间的跨服务调用或请求信息不完整，服务端应对其放行。

S53、未放行时获取数据权限规则。对于不满足上述放行的情形，后续需要处理数据权限规则。通过获取当前用户信息、业务信息和数据权限标识，从数据库中查询数据权限的所有信息，包括关联功能、规则条件、规则字段和规则值等。

S6、基于数据权限规则修改语法树，进行数据权限控制。

本实施例基于数据权限规则对语法树进行修改，然后应用程序服务端依据修改后的语法树完成对用户数据权限的控制。需要注意的是，在代码层面SQL语句并不是一棵树结构，一个SQL语句只在数据库中会被解析为树结构。而本发明实施例通过类与子类的关系映射数据库中节点和子节点关系，从而在代码中模拟出了一个树的结构。服务端可以在这棵语法树上模拟数据库中对SQL的解析行为，对语法树进行拆分、重组，从而实现数据权限的控制。

如图3所示，以下是服务端处理一个SQL语句的解析流程图：

S61、获取原SQL语句主体部分，并将主体部分转换为表示原SQL语句查询语句的对象。

在S22步骤，服务端已将原SQL语句解析成了一个以Statement为根节点的SQL语法树。通过Statement节点，可以获取原SQL语句的主体部分SelectBody。

需要说明的是，这个SelectBody在代码中体现为一个通用的对象，包含了所有数据库操作的功能。

本发明实施例中，如前述S4所述，服务端只会对查询操作进行权限控制，以达到间接控制其他SQL操作的目的。因此，服务端将主体部分SelectBody通过类型转换的方式转换为表示SQL语句查询语句的对象PlainSelect。PlainSelect对象是在JAVA解析器库中用于表示SQL查询语句中的SELECT子句的类，表示这是针对SQL查询进行的操作。

S62、判断数据权限规则是否配置了可见字段，针对配置了可见字段的数据权限规则，用列表存储可见字段范围，修改主体部分的可见字段范围。

获取S4中所配置的数据权限规则允许的可见字段，命名为“visibleColumn”，同时，服务端需要创建一个列表保存可见字段信息。在获取时，如果可见字段是“*”， 即为全部字段，则直接存放到列表中。否则，服务端将visibleColumn里面的可见字段信息用分隔符进行拆分，存放到创建的列表中。服务端将用这个新的列表替换原来的查询对象自带的列表。例如，应用程序客户端配置了可见字段为ID、NAME和GENDER，那么服务端将会用[ID,NAME, GENDER]的列表替换原来的查询对象携带的列表信息。

需要说明的是，本步骤只针对在数据权限规则配置阶段配置了可见字段的规则情况下才进行操作。如果数据权限规则中没有配置可见字段，则无需执行此操作步骤。

S63、获取原SQL语句条件表达式。

在一个SQL语句中，WHERE子句是数据库操作的条件表达式，在JAVA的解析库中，用Expression这个关键接口来表示WHERE语句的信息，在本发明实施例的树状图中，Expression则表示WHERE子树的根节点信息。本实施例中，用WHERE_CLAUSE表示WHERE子句。在语法树结构中，WHERE_CLAUSE是一条SQL语句中所有Expression节点的父节点。

根据图4展示的WHERE_CLAUSE节点的具体结构，通过SQL语法树实现数据权限控制方法的核心思路就是修改WHERE_CLAUSE下的子节点，对CONDITION（指条件表达式）进行新增、修改、删除、拼接等操作。将新节点接入原WHERE_CLAUSE节点达到数据的不可见、不可操作等目的。

S64、服务端根据数据权限规则，为每一个原SQL语句的条件表达式创建一个节点

Expression节点在JAVA语句中代表了当前SQL的WHERE子句的信息。本实施例中，通过修改WHERE子句来达到控制数据权限的目的，实际就是修改Expression节点的过程。需要特别注意的是，如果用户采用S4中的自定义规则，针对一个SQL语句配置了多个规则条件的情况，服务端需要为每一个规则条件生成一个Expression对象。需要说明的是，步骤S3的数据权限规则规范限制此时会对Expression对象生效并产生限制，详细步骤将在后面的内容中描述。

在生成Expression对象的步骤中，服务端会对S3中数据权限控制范围常量的占位符根据当前用户信息、系统日期、系统时间等进行赋值，并创建出一个对应的Expression节点。每一个Expression节点下有一颗子树，子树由规则字段、规则值和规则条件组成。如：针对“等于”，要在代码中对Expression的左节点规则字段和右节点规则值用“=”进行连接。同理，对于其他的逻辑表达式，都要用对应的符号进行拼接。

图4展示了一棵SQL语法树中WHERE子句的具体结构，在该图中，根节点WHERE_CLAUSE表示该图是一个Where子句，OPERATOR用AND、OR等二元符号连接多个条件集。每个条件集由一个或多个Expression条件表达式构成。多个Expression节点组合成一个AND_EXPRESSION节点并再次通过OPERATOR二元符号进行链接，表示Expression之间的逻辑关系。每个Expression节点下，有表示数据库字段COL、数据库逻辑操作符COMPARISON以及数据库字段对应的值VAL，它们分别对应本发明实施例中的规则字段、规则条件以及规则值。

参见图5。在生成Expression对象过程中，我们需要注意一些特殊的数据权限规则：

1）IN 和 NOT_IN：一个SQL语句中如果出现这两个逻辑运算符，表示该规则包含了多个条件表达式。例如：“SELECT * FROM USER WHERE NAME IN ‘A’,‘B’,‘C’；”在这个语句中，IN符号后面包含了三个表达式‘A’,‘B’,‘C’。对于这样的情况，服务端需要创建一个JSQLParser工具库中的MultiExpressionList列表存储IN 或 NOT_IN 语句中的规则值，用于在这样的情况下表达SQL中的多个表达式。

2）如果用户在S3步骤的自定义规则配置中，将规则值设定为时间类型，服务端需要将自定义时间转化为JSQLParser工具库中的TimeKeyExpression对象，以表示用户自定义的时间范围查询条件。

3）对生成的Expression节点，基于S3步骤的限制内容，服务端对错误的配置规则进行特殊处理。

服务端为每一个规则条件子树的内容，生成一个Expression节点。服务端对节点下的规则条件进行判断，看规则条件是否在S3列举的逻辑运算符常量中。如果不在S3所列举常量中，服务端将会产生一个等于符号的规则条件，用于代替规则配置中原有的规则条件。该规则条件将会连接一个由服务端规定的规则字段和规则值。服务端需要让该字段和规则值用等号连接时逻辑判断永远为false。

例如，服务端规定当规则条件超过S3列举的逻辑运算符常量范围时，规则字段为固定值“ID”，规则值为固定值“-10000”。当用户设置了自定义数据权限规则“Happy !==Sad”，因为规则条件“!==”不在上述S3所限制的逻辑操作符中，服务端会用“ID”来代替规则字段“Happy”，用“=”代替规则条件“!==”，用“-10000”代替规则值“Sad”。最后拼凑的子树为：ID = -10000。因为数据库中ID都为正整数， 因此ID = -10000的条件永远不可能满足，用户也无法对数据库进行任何操作，以此完成了对脏数据的处理，实现了对系统数据的限制和保护，可进一步，保证整个系统不会出现因为错误配置产生错误数据等情况。在极大给予用户配置自由的同时，能保证整个系统的安全性和完整性。

S65、根据原SQL语句的条件表达式是否为空，通过对新生成的节点进行接入或替换操作来修改原SQL语句的条件表达式。

服务端将根据原Expression来判断修改后的Expression节点是通过AND拼接进原WHERE子句，还是替换整个WHERE子句。如果原Expression为空，进行替换，反之，进行拼接操作。经过替换或者拼接，就完成了对Expression修改，能够实现数据权限控制的语法树也修改完成。后续，服务端的业务代码将调用修改后的SQL语句，完成权限控制。

图3是服务端在对一条SQL语句进行数据权限控制时进行的完整流程示意图，包括了S2、S5和S6步骤。

下面通过两个实例对S6步骤进行说明。实例1中，令原SQL语句是：“SELECT ID,NAME FROM USERS WHERE ID = 1;”，解析后的语法树如图7所示。实例2中，令原SQL语句是：“SELECT ID, NAME FROM USERS;”，解析后的语法树如图8所示。需要说明的是，S6中描述的术语是从代码实现角度进行考量并使用的，为了更直观描述语法树结构，将语法树图中的树节点用词转化为了通用的SQL节点。

图7和图8两棵语法树的根节点都是STATEMEN节点。子节点SELECT_STATEMTNT表示这是一个SELECT查询，左子节点SELECT_CLAUSE携带查询的内容以及条件，右子节点FROM_ITEM携带的表信息。在这个例子中，SELECT_STATEMENT是一个PlainSelect节点。它包含以下子节点：

1）COLUMNS_LIST：这个节点包含一个或多个COLUMN节点，表示SELECT子句中的字段或表达式。在这个例子中，有两个COLUMN节点，分别是ID和NAME。

2）FROM_ITEM：这个节点表示FROM子句中的表或子查询。在这个例子中，FROM_ITEM是一个TABLE节点，表示USERS。

3）WHERE_CLAUSE：这个节点表示查询的WHERE子句。在这个例子中，WHERE是一个EqualsTo节点，表示等于，其左节点表示ID字段，而右节点是一个ID对应的值。

图8的语法树结构如下：

第一层 STATEMENT：陈述式，是语法树根节点

第二层 SELECT_STATEMEN；查询陈述式

第三层 SELECT_CLAUSE：查询子句

第四层 SELECT：查询

第四层 COLUMNS：列集

第五层 COLUMNS_LIST：列表

第六层 COLUMN：列

第七层 ID：ID列

第七层 NAME：姓名列

第八层 WHERE_CLAUSE：WHERE子句

第九层 WHERE：WHERE关键字

第九层 CONDITION：条件

第十层 EXPR：表达式

第三层 FROM_ITEM 查询字句

第四层 FROM：FROM关键字

第四层 TABLE：表

第五层 USERS：用户表

图7的语法树与图8的语法树的差别是：在“EXPR”下增加了一个子树。“OPERATOR”是操作符“=”，规则字段是“ID”，规则值“VAL”的数值是“1”。

对照图3，依据客户端配置的数据权限规则，用户配置数据权限，限制对ID = 1的数据的查询，此时对语法树的进行如下操作：

1）获取原SQL语句主体部分，即图7、图8中整棵树的信息。

2）客户端未对可见字段进行限制，跳过替换可见字段的步骤。

3）获取原SQL条件表达式，图7、图8中，为WHERE_CLAUSE节点及其子树。

4）为客户端配置的数据权限规则ID != 1生成新的Expression节点。服务端创建一个新的Expression节点，会将客户端配置的规则条件作为子树接入该节点。子树的根节点为规则条件。图中表示为操作符Operator，值为!=，规则条件的左子节点规则字段设置为ID，右子节点规则值设置为1。

5）服务端根据原SQL语法树的Expression节点判断新生成的Expression节点是接入WHERE语句还是替换整个WHERE。

如图7所示，原SQL语句的Expression节点不为空，因此生成的Expression接入原WHERE语句中，对SQL语法树的修改完成。修改后的语法树如图9所示。图9与图7的区别是，新增了“EXTRA_EXPR”这个额外表达式及“ID != 1”的子树，额外表达式与原有的“EXPR”表达式组合为“AND_EXPR”这样的“和表达式”。修改后的WHERE语句为：ID = 1 AND ID != 1，因为两个条件互斥，他们不能同时满足，因此查询不会匹配任何的行，结果集将为空。从而限制了ID = 1的数据被查询展示。

如图8所示，原SQL语句的Expression节点为空，因此生成的Expression将替换原WHERE语句的Expression节点。对SQL语法树的修改完成。修改后的语法树如图10所示。图10与图8的区别是，在原有的“EXPR”表达式下新增了“ID != 1”的子树，子树有“OPERATOR”和左子节点“ID”以及右子节点“VAL”。修改后的WHERE语句为： ID != 1，因此查询时会将ID != 1的结果返回。从而限制了ID = 1的数据被查询展示。

本发明的实施例还提供了一种基于SQL语法树的数据权限控制装置，包括客户端和服务端，以及如下模块：

请求修改模块，用于对应用程序客户端发起的请求添加用户信息和业务信息；

请求拦截与解析模块，用于在应用程序服务端拦截SQL语句并将其解析为语法树；

数据权限规范模块，用于在应用程序服务端对客户端配置的数据权限规则进行规范；

数据权限配置模块，用于基于应用程序服务端对数据权限规则的规范，在应用程序客户端配置数据权限规则；

数据权限规则判断与放行模块，用于在应用程序服务端判断用户操作是否受数据权限限制，如果不受限制，服务端放行该SQL语句，如果受限制，获取SQL语句的数据权限规则；

语法树修改模块，用于基于配置的数据权限规则修改语法树，进行数据权限控制。

本发明实施例还提供了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行存储器上所存储的程序，实现前述基于SQL语法树的数据权限控制方法实施例的各步骤。

关于该方法各个步骤的具体实现以及相关解释内容可以参见图1-图10所示的方法实施例，在此不做赘述。

本实施例提到的电子设备的存储器可以包括随机存取存储器(Random AccessMemory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。

上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessing，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本发明实施例还提供了一种计算机可读存储介质，该计算机可读存储介质内存储有计算机程序，该计算机程序被处理器执行时实现前述基于SQL语法树的数据权限控制方法实施例的各步骤。关于该方法各个步骤的具体实现以及相关解释内容可以参见图1-图10所示的方法实施例，在此不做赘述。

需要说明的是，本说明书中的各个实施例均采用相关的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。

尤其，对于装置、电子设备、计算机可读存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述描述仅是对本发明较佳实施例的描述，并非对本发明范围的任何限定，本发明领域的普通技术人员根据上述揭示内容做的任何变更、修饰，均属于本发明的保护范围之内。

Claims (8)

1.一种数据权限控制方法，其特征在于包括如下步骤：

1）对应用程序客户端发起的请求添加用户信息和业务信息；

2）在应用程序服务端拦截SQL语句，获取被拦截SQL语句的数据权限标识，并将SQL语句解析为语法树；

3）在应用程序服务端对客户端的数据权限规则配置进行规范，所述规范包括列举所有数据权限控制范围以及所有客户端能够配置的数据逻辑运算符；

4）在应用程序客户端配置数据权限规则，包括配置数据权限规则的关联功能、数据库条件语句和数据权限标识；

5）应用程序服务端判断用户操作是否受数据权限规则限制，如果不受限制，服务端放行该SQL语句，如果受限制，获取SQL语句的数据权限规则；

6）基于数据权限规则修改语法树，进行数据权限控制。

2.根据权利要求1所述的数据权限控制方法，其特征在于，所述在应用程序服务端拦截SQL语句并将其解析为语法树包括如下步骤：

1）应用程序服务端创建拦截器，对SQL语句进行拦截，通过SQL语句的真实对象获取SQL的数据权限标识；

2）将拦截到的SQL语句解析为语法树。

3.根据权利要求1所述的数据权限控制方法，其特征在于，所述的在应用程序客户端配置数据权限规则还包括对资源树信息的请求路径进行配置。

4.根据权利要求1所述的数据权限控制方法，其特征在于，所述的应用程序服务端判断用户操作是否受数据权限限制包括如下步骤：

1）基于数据权限标识判断是否放行；

2）基于请求属性和请求头信息判断是否放行；

3）未放行时获取数据权限规则。

5.根据权利要求1所述的数据权限控制方法，其特征在于，所述的基于数据权限规则修改语法树进行数据权限控制包括如下步骤：

1）获取SQL语句主体部分，并将主体部分转换为表示SQL语句查询语句的对象；

2）获取原SQL语句条件表达式，服务端根据数据权限规则，为每一个原SQL语句的条件表达式创建一个节点；

3）根据原SQL语句的条件表达式是否为空，通过对新生成的节点进行接入或替换操作来修改原SQL语句的条件表达式。

6.一种数据权限控制装置，其特征在于包括：

请求修改模块，用于对应用程序客户端发起的请求添加用户信息和业务信息；

请求拦截与解析模块，用于在应用程序服务端拦截SQL语句，获取被拦截SQL语句的数据权限标识，并将其解析为语法树；

数据权限规范模块，用于在应用程序服务端对客户端的数据权限规则配置进行规范，所述规范包括列举所有数据权限控制范围以及所有客户端能够配置的数据逻辑运算符；

数据权限配置模块，用于在应用程序客户端配置数据权限规则，包括配置数据权限规则的关联功能、数据库条件语句和数据权限标识；

数据权限规则判断与放行模块，用于在应用程序服务端判断用户操作是否受数据权限限制，如果不受限制，服务端放行该SQL语句，如果受限制，获取SQL语句的数据权限规则；

语法树修改模块，用于基于配置的数据权限规则修改语法树，进行数据权限控制。

7.一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行存储器上所存储的程序，实现权利要求1-5任一所述的方法步骤。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1-5任一项所述的方法步骤。