一种权限处理方法、装置、电子设备及存储介质

技术领域

本申请涉及权限技术领域，尤其涉及一种权限处理方法、装置、电子设备及存储介质。

背景技术

随着信息化技术的快速发展，权限管理在各类系统中扮演着越来越重要的角色。然而，现有的权限管理方式往往存在着授权方式单一、适用范围有限、难以适应复杂多变的业务需求等问题。此外，随着云计算、大数据等新技术的广泛应用，租户级别的权限管理需求日益凸显，传统的权限管理方式难以满足这些需求。

在现有的权限管理方式中，通常采用基于角色或用户的授权方式，这种方式难以实现租户级别的权限管理，也难以满足复杂多变的业务需求。

发明内容

有鉴于此，本申请实施例提供了一种权限处理方法、装置、电子设备及存储介质，不仅抽象出了可授予的权限和可被授权的主体，还引入了权限承接中间件(grantor)的概念，实现了多层次的权限管理和灵活的授权方式。同时，该方法还考虑了权限管理的安全性、可追溯性和可扩展性等方面的需求。

本申请实施例的技术方案是这样实现的：

第一方面，本申请实施例提供一种权限处理方法，所述方法包括：

基于业务需求确定至少一种目标权限，以及基于所述业务需求确定至少一个授权主体，其中，所述目标权限表征可被授予的权限，所述授权主体表征可被授予权限的主体；

响应于授权请求，获取所述至少一种目标权限中的待授权权限，以及获取所述至少一个授权主体中的待授权主体，并通过权限承接中间件对所述待授权权限和待授权主体进行关联，以完成授权。

第二方面，本申请实施例还提供一种权限处理装置，所述装置包括：

确定模块，用于基于业务需求确定至少一种目标权限，以及基于所述业务需求确定至少一个授权主体，其中，所述目标权限表征可被授予的权限，所述授权主体表征可被授予权限的主体；

关联模块，用于响应于授权请求，获取所述至少一种目标权限中的待授权权限，以及获取所述至少一个授权主体中的待授权主体，并通过权限承接中间件对所述待授权权限和待授权主体进行关联，以完成授权。

第三方面，本申请实施例还提供一种电子设备，包括：处理器、存储介质和总线，所述存储介质存储有所述处理器可执行的机器可读指令，当电子设备运行时，所述处理器与所述存储介质之间通过总线通信，所述处理器执行所述机器可读指令，以执行第一方面任一项所述的权限处理方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器运行时执行第一方面任一项所述的权限处理方法。

本申请实施例具有以下有益效果：

通过定义多种可授予的权限和多种可被授权的主体，实现了更加精细的权限控制。同时，通过引入grantor的概念，可以将权限管理分为多个层次，实现权限的分级管理和控制，简化了授权过程；此外，还考虑了权限管理的安全性问题。通过实现动态的权限调整和撤销机制，可以避免权限的滥用和误用，提高系统的安全性。同时，通过审计和监控功能，可以实现对权限管理的可追溯性，增强了系统的可靠性；最后，还具有良好的可扩展性和可维护性。通过模块化的设计方式，可以方便地扩展系统的功能和性能，满足不断增长的业务需求。同时，通过统一的权限管理平台，可以降低维护成本，提高系统的可维护性；另外，本申请还通过正向授权和逆向授权满足了不同场景下的权限需求。正向授权允许管理员根据已有的权限来为主体进行授权，这种方式简单直接，可以快速满足主体的基本权限需求。而逆向授权则允许根据主体的特定需求为其量身定制权限，这种方式更加个性化，可以精确满足主体的特殊权限需求。两种方式相结合，使得权限管理更加灵活多变，适应了更多复杂的实际应用场景，最后，通过动态授权的方式，还能够实时响应并处理权限调整的需求，提高了系统的时效性和适应性。动态授权允许系统根据实时事件或条件自动调整权限，这种调整可以是临时的，也可以是永久的，可以根据实际需求灵活变通。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1是本申请实施例提供的权限处理方法的方法流程图；

图2是本申请实施例提供的基于权限等级进行授权的方法流程图；

图3是本申请实施例提供的动态授权的方法流程图；

图4是本申请实施例提供的权限处理装置的结构示意图；

图5是本申请实施例提供的电子设备的组成结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

在以下的描述中，所涉及的术语“第一第二第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一第二第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语是为了描述本申请实施例的目的，不是在限制本申请。

参见图1，图1是本申请实施例提供的权限处理方法的方法流程图，将结合图1示出的步骤S101-S102进行说明。

步骤S101、基于业务需求确定至少一种目标权限，以及基于所述业务需求确定至少一个授权主体，其中，所述目标权限表征可被授予的权限，所述授权主体表征可被授予权限的主体；

步骤S102、响应于授权请求，获取所述至少一种目标权限中的待授权权限，以及获取所述至少一个授权主体中的待授权主体，并通过权限承接中间件对所述待授权权限和待授权主体进行关联，以完成授权。

上述权限处理方法，通过定义多种可授予的权限和多种可被授权的主体，实现了更加精细的权限控制。同时，通过引入grantor的概念，可以将权限管理分为多个层次，实现权限的分级管理和控制，简化了授权过程；此外，还考虑了权限管理的安全性问题。通过实现动态的权限调整和撤销机制，可以避免权限的滥用和误用，提高系统的安全性。同时，通过审计和监控功能，可以实现对权限管理的可追溯性，增强了系统的可靠性；最后，还具有良好的可扩展性和可维护性。通过模块化的设计方式，可以方便地扩展系统的功能和性能，满足不断增长的业务需求。同时，通过统一的权限管理平台，可以降低维护成本，提高系统的可维护性；另外，本申请还通过正向授权和逆向授权满足了不同场景下的权限需求。正向授权允许管理员根据已有的权限来为主体进行授权，这种方式简单直接，可以快速满足主体的基本权限需求。而逆向授权则允许根据主体的特定需求为其量身定制权限，这种方式更加个性化，可以精确满足主体的特殊权限需求。两种方式相结合，使得权限管理更加灵活多变，适应了更多复杂的实际应用场景，最后，通过动态授权的方式，还能够实时响应并处理权限调整的需求，提高了系统的时效性和适应性。动态授权允许系统根据实时事件或条件自动调整权限，这种调整可以是临时的，也可以是永久的，可以根据实际需求灵活变通。

下面分别对本申请实施例的上述示例性的各步骤进行说明。

在步骤S101中，基于业务需求确定至少一种目标权限，以及基于所述业务需求确定至少一个授权主体，其中，所述目标权限表征可被授予的权限，所述授权主体表征可被授予权限的主体。

首先，业务需求是确定目标权限和授权主体的关键因素。业务需求的来源可以是业务需求文档、用户反馈、市场需求等。在明确业务需求后，需要分析业务需求，确定需要授予哪些权限，以及哪些主体需要这些权限。

例如，业务需求可能是需要实现一个订单管理功能，那么目标权限就可以是订单查看、订单编辑、订单删除等，而授权主体可以是具有订单管理职责的员工或管理员。

在步骤S102中，响应于授权请求，获取所述至少一种目标权限中的待授权权限，以及获取所述至少一个授权主体中的待授权主体，并通过权限承接中间件对所述待授权权限和待授权主体进行关联，以完成授权。

当接收到授权请求时，系统需要响应请求并获取相关的待授权权限和待授权主体。授权请求可以来自于用户界面、API调用等。

例如，用户可以在界面上选择一个角色并为其授予订单查看权限。系统接收到这个请求后，会获取订单查看这一待授权权限，以及选择的角色作为待授权主体。

接下来，通过权限承接中间件，将待授权权限和待授权主体进行关联。这个中间件可以是一个服务、一个模块或一段代码，其作用是实现权限和主体的关联。具体的实现方式可以根据系统的架构和技术选型来确定。

例如，可以通过在数据库中创建一个关联表，将角色ID和权限ID存储在表中，实现角色和权限的关联。这样，当需要检查某个角色是否具有某个权限时，只需查询这个关联表即可。

通过以上步骤，可以完成基于业务需求和授权请求的权限授予过程，实现更加精细和灵活的权限管理。

在一些实施例中，所述授权请求包括正向授权请求和逆向授权请求，所述正向授请求表征为所述待授权主体授予所述待授权权限的过程，所述逆向授权请求表征将所述待授权权限授予所述待授权主体的过程，所述正向授权请求和所述逆向授权请求分别对应于一授权标识，所述正向授权请求对应的授权标识和所述逆向授权请求对应的授权标识不同。

正向授权请求和逆向授权请求在授权过程中的处理略有不同。正向授权请求通常表示将权限授予给主体的过程，可以理解为将权限“分配”给主体。在具体实现中，系统可能会根据请求中的参数或标识来判断请求类型，然后根据请求内容获取待授权权限和待授权主体，通过权限承接中间件完成权限的授予操作。

逆向授权请求则通常表示将主体授予权限的过程，可以理解为将主体“赋予”权限。在具体实现中，系统同样会根据请求中的参数或标识来判断请求类型，然后获取待授权权限和待授权主体，通过权限承接中间件完成主体的授权操作。

需要注意的是，正向授权请求和逆向授权请求的区分并不是绝对的，具体的实现方式会根据系统的需求和设计来确定。例如，有些系统可能会将这两种请求合并为一种请求，通过不同的参数或标识来区分处理逻辑。另外，授权标识的使用可以更加清晰地描述和理解授权过程。通过为不同的授权请求类型分配不同的授权标识，可以更加直观地了解授权操作的类型和对象，方便进行权限管理和审计。

上述正向授权请求和逆向授权请求的区分以及授权标识的使用，可以为权限管理提供更加精细和灵活的控制方式，提高系统的安全性和可维护性。

在一些实施例中，所述方法还包括：

通过所述授权标识与所述权限承接中间件的关联操作实现所述正向授权请求或所述逆向授权请求，每次关联操作对应的授权标识唯一，且实现所述正向授权请求的所述授权标识与实现所述逆向授权请求的所述授权标识不同。

这里，每次关联操作都会有一个唯一的授权标识与之对应，并且实现正向授权请求的授权标识与实现逆向授权请求的授权标识是不同的。

具体而言，正向授权请求通常指的是根据已有的权限来为主体授权，可以使用grant作为授权标识，而逆向授权请求则是根据主体的需求为其分配相应的权限，则可以使用grant-to作为授权标识。通过授权标识的使用，可以清晰地区分这两种不同的授权请求，确保系统在处理授权请求时不会出现混淆或错误。

这种设计可以进一步提高系统的灵活性和准确性，使得权限管理更加精细化。同时，通过为每种授权请求分配唯一的授权标识，也增强了系统的安全性，有助于防止潜在的权限泄露或滥用风险。

上述的方式，通过授权标识与权限承接中间件的关联操作实现正向和逆向授权请求，并为每种请求分配唯一的授权标识，可以使系统的权限管理更加完善，提高系统的安全性和灵活性。

在一些实施例中，参见图2，图2是本申请实施例提供的步骤S201-S203的流程示意图，所述权限承接中间件为多个，所述通过权限承接中间件对所述待授权权限和待授权主体进行关联，可以通过步骤S201-S203实现，将结合各步骤进行说明。

在步骤S201中，确定所述授权请求的请求方对应的权限等级。

这里，确定授权请求的请求方对应的权限等级是非常关键的。这需要根据具体的业务需求和系统设计来设定。例如，不同的用户角色可能对应不同的权限等级，系统管理员可能拥有最高的权限等级，而普通用户则拥有较低的权限等级。

在步骤S202中，基于所述权限等级，从多个权限承接中间件中确定与所述权限等级匹配或低于所述权限等级的目标权限承接中间件。

这里，基于请求方的权限等级，从多个权限承接中间件中确定与权限等级匹配或低于权限等级的目标权限承接中间件。这一步需要根据预先定义的规则或映射表来实现。例如，可以定义一个中间件列表，每个中间件对应一个权限等级范围，然后根据请求方的权限等级来选择相应的中间件。

在步骤S203中，通过所述目标权限承接中间件对所述待授权权限和待授权主体进行关联。

这里，通过目标权限承接中间件对待授权权限和待授权主体进行关联。这一步的具体实现方式会根据中间件的设计和功能来确定。例如，目标权限承接中间件可能提供了一个关联接口，通过调用这个接口并传入待授权权限和待授权主体作为参数，就可以完成关联操作。

需要注意的是，多个权限承接中间件的使用可以提供更加灵活和可扩展的权限管理方式。不同的中间件可以实现不同的功能或策略，根据具体的业务需求来选择合适的中间件，可以更好地满足系统的需求。同时，根据请求方的权限等级来选择中间件也可以进一步提高系统的安全性。通过限制低权限等级的请求方只能使用低级别的中间件，可以避免权限提升或滥用的情况。

上述的方式，通过多个权限承接中间件对待授权权限和待授权主体进行关联的过程，可以实现更加精细和灵活的权限管理，提高系统的安全性和可维护性。

在一些实施例中，所述方法还包括：

对所述权限承接中间件的关联操作进行记录，以及将所记录的关联操作作为授权日志进行存储。

对权限承接中间件的关联操作进行记录和存储的具体实现方式可以根据系统的需求和设计来确定。一般来说，可以通过在权限承接中间件中添加日志记录功能，将关联操作的相关信息记录下来，并存储到指定的位置。

具体来说，当通过权限承接中间件对待授权权限和待授权主体进行关联时，中间件会自动触发日志记录功能，将关联操作的相关信息记录下来。这些信息可以包括操作时间、操作人、操作内容等，以便后续的查询和分析。

为了保证数据的安全性和可追溯性，可以对授权日志进行加密和备份操作。例如，可以使用加密算法对日志数据进行加密，确保数据的安全性；同时，可以将日志数据备份到多个存储位置，防止数据丢失或损坏。

通过记录和存储授权日志，可以实现对权限管理过程的全面监控和审计，提高系统的安全性和可维护性。同时，授权日志也为后续的故障排查、数据分析等提供了重要的数据支持。例如，可以通过分析授权日志，了解系统的权限管理情况，发现潜在的安全风险或问题，及时采取相应的措施进行处理。

上述方式对权限承接中间件的关联操作进行记录和存储是非常必要的，可以提高系统的安全性和可维护性，并为后续的管理和分析提供了重要的数据支持。

在一些实施例中，参见图3，图3是本申请实施例提供的步骤S301-S303的流程示意图，所述方法还包括步骤S301-S303，将结合各步骤进行说明。

在步骤S301中，响应于动态授权请求，确定所述动态授权请求所包括的至少一个动态事件。

这里，动态授权请求可能来自于不同的来源，例如用户操作、系统事件等，这些请求中包含了需要进行动态授权的事件信息。系统需要能够及时响应这些请求，并提取出其中的动态事件信息，以便进行后续的处理。

在步骤S302中，基于所述至少一个动态事件为所述权限承接中间件创建授权事件，其中，所述授权事件与所述动态事件相匹配。

这里，授权事件是与动态事件相匹配的，用于触发中间件进行相应的权限调整。创建授权事件的具体方式可以根据中间件的设计和功能来确定，可以通过定义事件类型、设置事件参数等方式来实现。同时，需要确保授权事件与动态事件的匹配性和准确性，以便中间件能够正确地响应并进行权限调整。

在步骤S303中，基于所述授权事件对所述权限承接中间件进行调整，以实现动态授权。

这里，通过调整中间件，可以实现对权限的动态管理和控制，满足不同场景下的权限需求。具体的调整方式会根据中间件的设计和功能来确定，可以通过调用中间件的接口、执行相关函数或修改中间件配置等方式来实现。在调整过程中，需要确保中间件的稳定性和安全性，避免因为权限调整而引发系统问题或安全风险。

上述的方式，可以实现更加精细和灵活的动态授权过程，使得系统的权限管理更加高效和可靠。同时，动态授权也可以提高系统的适应性和可扩展性，能够更好地满足不同场景下的权限需求。

在一些实施例中，所述权限承接中间件对应一图形用户界面，所述图形用户界面包括第一区域和第二区域，所述第一区域用于放置所述待授权权限，所述第二区域用于放置所述待授权主体。

权限承接中间件可以对应一个图形用户界面(GUI)，以便用户更直观地进行权限管理操作。这个图形用户界面可以包括第一区域和第二区域，分别用于放置待授权权限和待授权主体。

具体来说，第一区域可以显示当前可用的权限列表或权限图标，用户可以通过选择或拖拽等方式将需要的权限放置到该区域。第二区域则可以显示当前可用的主体列表或主体图标，用户同样可以通过选择或拖拽等方式将待授权的主体放置到该区域。

通过这样的图形用户界面设计，用户可以直观地进行权限和主体的选择和关联操作，提高了用户体验和操作的便捷性。同时，图形用户界面也可以根据不同的业务需求和设计来进行定制，以满足不同场景下的权限管理需求。

需要注意的是，图形用户界面的具体实现方式可以根据系统的设计和开发语言来确定，可以使用常见的前端框架或GUI库来进行实现。同时，为了确保界面的安全性和稳定性，也需要对界面进行相应的安全措施和性能优化。

在一些实施例中，所述方法还包括：

对所述权限承接中间件的关联操作进行记录，并对每条记录创建回滚节点；

响应于回滚操作，从回滚节点中确定目标回滚节点，并根据所述目标回滚节点对关联操作进行回滚。

对权限承接中间件的关联操作进行记录并创建回滚节点，可以在系统中形成一个完整的操作日志，这个日志包含了所有的关联操作信息和对应的回滚节点。通过操作日志，可以实现对系统操作的可追溯性和审计功能，提高系统的安全性和可维护性。

具体来说，当进行关联操作时，系统会自动记录这个操作的相关信息，例如操作时间、操作人、操作内容等，并创建一个对应的回滚节点。回滚节点中包含了进行回滚所需的所有信息，例如操作前的状态、操作数据等，以便能够准确地恢复到操作前的状态。

当需要进行回滚操作时，系统会根据用户的请求从操作日志中查找目标回滚节点，然后根据目标回滚节点对关联操作进行回滚。这个过程可以自动完成，也可以由用户手动触发，具体实现方式可以根据系统的设计和需求来确定。

通过创建回滚节点，可以确保系统在出现问题或误操作时能够及时恢复到正常状态，避免数据损失和系统崩溃等风险。同时，回滚节点的使用也可以提高系统的可维护性和可靠性，为后续的故障排查和数据恢复提供了重要的支持。

需要注意的是，为了保证操作日志的安全性和完整性，需要对操作日志进行加密和备份操作，确保数据的安全性和可追溯性。

上述的方式，可以提高系统的安全性和可维护性，确保系统在出现问题时能够及时恢复并正常运行。

综上所述，通过本申请实施例具有以下有益效果：

通过定义多种可授予的权限和多种可被授权的主体，实现了更加精细的权限控制。同时，通过引入grantor的概念，可以将权限管理分为多个层次，实现权限的分级管理和控制，简化了授权过程；此外，还考虑了权限管理的安全性问题。通过实现动态的权限调整和撤销机制，可以避免权限的滥用和误用，提高系统的安全性。同时，通过审计和监控功能，可以实现对权限管理的可追溯性，增强了系统的可靠性；最后，还具有良好的可扩展性和可维护性。通过模块化的设计方式，可以方便地扩展系统的功能和性能，满足不断增长的业务需求。同时，通过统一的权限管理平台，可以降低维护成本，提高系统的可维护性；另外，本申请还通过正向授权和逆向授权满足了不同场景下的权限需求。正向授权允许管理员根据已有的权限来为主体进行授权，这种方式简单直接，可以快速满足主体的基本权限需求。而逆向授权则允许根据主体的特定需求为其量身定制权限，这种方式更加个性化，可以精确满足主体的特殊权限需求。两种方式相结合，使得权限管理更加灵活多变，适应了更多复杂的实际应用场景，最后，通过动态授权的方式，还能够实时响应并处理权限调整的需求，提高了系统的时效性和适应性。动态授权允许系统根据实时事件或条件自动调整权限，这种调整可以是临时的，也可以是永久的，可以根据实际需求灵活变通。

基于同一发明构思，本申请实施例中还提供了与第一实施例中权限处理方法对应的权限处理装置，由于本申请实施例中的装置解决问题的原理与上述权限处理方法相似，因此装置的实施可以参见方法的实施，重复之处不再赘述。

如图4所示，图4是本申请实施例提供的权限处理装置400的结构示意图。权限处理装置400包括：

确定模块401，用于基于业务需求确定至少一种目标权限，以及基于所述业务需求确定至少一个授权主体，其中，所述目标权限表征可被授予的权限，所述授权主体表征可被授予权限的主体；

关联模块402，用于响应于授权请求，获取所述至少一种目标权限中的待授权权限，以及获取所述至少一个授权主体中的待授权主体，并通过权限承接中间件对所述待授权权限和待授权主体进行关联，以完成授权。

本领域技术人员应当理解，图4所示的权限处理装置400中的各单元的实现功能可参照前述权限处理方法的相关描述而理解。图4所示的权限处理装置400中的各单元的功能可通过运行于处理器上的程序而实现，也可通过具体的逻辑电路而实现。

在一种可能的实施方式中，所述授权请求包括正向授权请求和逆向授权请求，所述正向授请求表征为所述待授权主体授予所述待授权权限的过程，所述逆向授权请求表征将所述待授权权限授予所述待授权主体的过程，所述正向授权请求和所述逆向授权请求分别对应于一授权标识，所述正向授权请求对应的授权标识和所述逆向授权请求对应的授权标识不同。

在一种可能的实施方式中，所述权限承接中间件为多个，关联模块402通过权限承接中间件对所述待授权权限和待授权主体进行关联，包括：

确定所述授权请求的请求方对应的权限等级；

基于所述权限等级，从多个权限承接中间件中确定与所述权限等级匹配或低于所述权限等级的目标权限承接中间件；

通过所述目标权限承接中间件对所述待授权权限和待授权主体进行关联。

在一种可能的实施方式中，关联模块402还包括：

对所述权限承接中间件的关联操作进行记录，以及将所记录的关联操作作为授权日志进行存储。

在一种可能的实施方式中，关联模块402还包括：

响应于动态授权请求，确定所述动态授权请求所包括的至少一个动态事件；

基于所述至少一个动态事件为所述权限承接中间件创建授权事件，其中，所述授权事件与所述动态事件相匹配；

基于所述授权事件对所述权限承接中间件进行调整，以实现动态授权。

在一种可能的实施方式中，所述权限承接中间件对应一图形用户界面，所述图形用户界面包括第一区域和第二区域，所述第一区域用于放置所述待授权权限，所述第二区域用于放置所述待授权主体。

在一种可能的实施方式中，关联模块402还包括：

对所述权限承接中间件的关联操作进行记录，并对每条记录创建回滚节点；

响应于回滚操作，从回滚节点中确定目标回滚节点，并根据所述目标回滚节点对关联操作进行回滚。

上述权限处理装置通过定义多种可授予的权限和多种可被授权的主体，实现了更加精细的权限控制。同时，通过引入grantor的概念，可以将权限管理分为多个层次，实现权限的分级管理和控制，简化了授权过程；此外，还考虑了权限管理的安全性问题。通过实现动态的权限调整和撤销机制，可以避免权限的滥用和误用，提高系统的安全性。同时，通过审计和监控功能，可以实现对权限管理的可追溯性，增强了系统的可靠性；最后，还具有良好的可扩展性和可维护性。通过模块化的设计方式，可以方便地扩展系统的功能和性能，满足不断增长的业务需求。同时，通过统一的权限管理平台，可以降低维护成本，提高系统的可维护性；另外，本申请还通过正向授权和逆向授权满足了不同场景下的权限需求。正向授权允许管理员根据已有的权限来为主体进行授权，这种方式简单直接，可以快速满足主体的基本权限需求。而逆向授权则允许根据主体的特定需求为其量身定制权限，这种方式更加个性化，可以精确满足主体的特殊权限需求。两种方式相结合，使得权限管理更加灵活多变，适应了更多复杂的实际应用场景，最后，通过动态授权的方式，还能够实时响应并处理权限调整的需求，提高了系统的时效性和适应性。动态授权允许系统根据实时事件或条件自动调整权限，这种调整可以是临时的，也可以是永久的，可以根据实际需求灵活变通。

如图5所示，图5为本申请实施例提供的电子设备500的组成结构示意图，所述电子设备500，包括：

处理器501、存储介质502和总线503，所述存储介质502存储有所述处理器501可执行的机器可读指令，当电子设备500运行时，所述处理器501与所述存储介质502之间通过总线503通信，所述处理器501执行所述机器可读指令，以执行本申请实施例所述的权限处理方法的步骤。

实际应用时，所述电子设备500中的各个组件通过总线503耦合在一起。可理解，总线503用于实现这些组件之间的连接通信。总线503除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图5将各种总线都标为总线503。

上述电子设备通过定义多种可授予的权限和多种可被授权的主体，实现了更加精细的权限控制。同时，通过引入grantor的概念，可以将权限管理分为多个层次，实现权限的分级管理和控制，简化了授权过程；此外，还考虑了权限管理的安全性问题。通过实现动态的权限调整和撤销机制，可以避免权限的滥用和误用，提高系统的安全性。同时，通过审计和监控功能，可以实现对权限管理的可追溯性，增强了系统的可靠性；最后，还具有良好的可扩展性和可维护性。通过模块化的设计方式，可以方便地扩展系统的功能和性能，满足不断增长的业务需求。同时，通过统一的权限管理平台，可以降低维护成本，提高系统的可维护性；另外，本申请还通过正向授权和逆向授权满足了不同场景下的权限需求。正向授权允许管理员根据已有的权限来为主体进行授权，这种方式简单直接，可以快速满足主体的基本权限需求。而逆向授权则允许根据主体的特定需求为其量身定制权限，这种方式更加个性化，可以精确满足主体的特殊权限需求。两种方式相结合，使得权限管理更加灵活多变，适应了更多复杂的实际应用场景，最后，通过动态授权的方式，还能够实时响应并处理权限调整的需求，提高了系统的时效性和适应性。动态授权允许系统根据实时事件或条件自动调整权限，这种调整可以是临时的，也可以是永久的，可以根据实际需求灵活变通。

本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有可执行指令，当所述可执行指令被至少一个处理器501执行时，实现本申请实施例所述的权限处理方法。

在一些实施例中，存储介质可以是磁性随机存取存储器(FRAM，FerromagneticRandom Access Memory)、只读存储器(ROM，Read Only Memory)、可编程只读存储器(PROM，Programmable Read Only Memory)、可擦除可编程只读存储器(EPROM，ErasableProgrammable Read Only Memory)、电可擦除可编程只读存储器(EEPROM，ElectricallyErasable Programmable Read Only Memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD ROM，Compact Disc Read Only Memory)等存储器；也可以是包括上述存储器之一或任意组合的各种设备。

在一些实施例中，可执行指令可以采用程序、软件、软件模块、脚本或代码的形式，按任意形式的编程语言(包括编译或解释语言，或者声明性或过程性语言)来编写，并且其可按任意形式部署，包括被部署为独立的程序或者被部署为模块、组件、子例程或者适合在计算环境中使用的其它单元。

作为示例，可执行指令可以但不一定对应于文件系统中的文件，可以被存储在保存其它程序或数据的文件的一部分，例如，存储在超文本标记语言(HTML，HyperTextMarkupLanguage)文档中的一个或多个脚本中，存储在专用于所讨论的程序的单个文件中，或者，存储在多个协同文件(例如，存储一个或多个模块、子程序或代码部分的文件)中。

作为示例，可执行指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

上述计算机可读存储介质通过定义多种可授予的权限和多种可被授权的主体，实现了更加精细的权限控制。同时，通过引入grantor的概念，可以将权限管理分为多个层次，实现权限的分级管理和控制，简化了授权过程；此外，还考虑了权限管理的安全性问题。通过实现动态的权限调整和撤销机制，可以避免权限的滥用和误用，提高系统的安全性。同时，通过审计和监控功能，可以实现对权限管理的可追溯性，增强了系统的可靠性；最后，还具有良好的可扩展性和可维护性。通过模块化的设计方式，可以方便地扩展系统的功能和性能，满足不断增长的业务需求。同时，通过统一的权限管理平台，可以降低维护成本，提高系统的可维护性；另外，本申请还通过正向授权和逆向授权满足了不同场景下的权限需求。正向授权允许管理员根据已有的权限来为主体进行授权，这种方式简单直接，可以快速满足主体的基本权限需求。而逆向授权则允许根据主体的特定需求为其量身定制权限，这种方式更加个性化，可以精确满足主体的特殊权限需求。两种方式相结合，使得权限管理更加灵活多变，适应了更多复杂的实际应用场景，最后，通过动态授权的方式，还能够实时响应并处理权限调整的需求，提高了系统的时效性和适应性。动态授权允许系统根据实时事件或条件自动调整权限，这种调整可以是临时的，也可以是永久的，可以根据实际需求灵活变通。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法和电子设备，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，平台服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

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