CN115577344A - 一种权限管理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种权限管理方法，该方法包括：获取多个应用的路由信息，以及所述多个应用的关联关系；根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树；其中，所述路由结构树包括所述多个应用的所有路由节点；将所述路由结构树显示在权限配置界面；基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息；根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。如此，通过构建路由结构树，统一配置账号在多个应用下的路由权限，可以使得权限配置更加统一高效，有效减少后期维护成本。

Description

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

技术领域

本发明涉及互联网技术领域，尤其涉及一种权限管理方法、装置、设备及存储介质。

背景技术

微前端是最近两年兴起的一种架构，它将多个子应用集成到一个主应用中。随着近两年微前端架构的出现，如何为多个子应用统一配置路由权限成为新的挑战。现有技术中，各个子应用的独自进行权限配置。在单个子应用的架构下，路由权限写在各个子应用的业务代码中。然而，这种权限配置方法不能让子应用专注于业务开发，仍然需要子应用的开发人员自己实现权限逻辑；且没有提出一种统一、高效的权限配置方式，各种权限逻辑散落在子应用中，增加了后期的维护成本的技术问题。

发明内容

为解决上述技术问题，本申请实施例期望提供一种权限管理方法、装置、设备及存储介质。

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

第一方面，提供了一种权限管理方法，方法包括：

获取多个应用的路由信息，以及所述多个应用的关联关系；

根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树；其中，所述路由结构树包括所述多个应用的所有路由节点；

将所述路由结构树显示在权限配置界面；

基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息；

根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

上述方案中，所述应用的路由信息包括所述应用的所有路由节点以及所述所有路由节点间的路由层级关系；其中，单个应用的所述所有路由节点包括一个根路由节点和M个子路由节点，M取大于等于0的整数；

上述方案中，所述关联关系包括所述多个应用间的应用层级关系；其中，所述应用层级关系，用于将所述多个应用分为一个主应用和N个子应用，N取大于等于1的整数。

上述方案中，所述根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树，包括：

根据所述应用层级关系，确定所述多个应用中的主应用和子应用；

根据所述路由层级关系，将所述主应用的所有路由节点分为主应用根路由节点和主应用子路由节点，将所述子应用的所有路由节点分为子应用根路由节点和子应用子路由节点；

将所述主应用根路由节点作为第一层路由节点，将所述主应用子路由节点和所述子应用根路由节点作为第二层路由节点，将所述子应用子路由节点作为第三层路由节点，得到所述路由结构树。

上述方案中，所述根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断，包括：

所述主应用根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

上述方案中，所述基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息，包括：

在所述路由结构树上选定目标账号在所述多个应用中有权访问的所有路由节点，得到所述目标账号的有权路由节点；将所述有权路由节点作为所述目标账号的权限信息；其中，所述目标账号为所述至少一个账号中任一个账号。

上述方案中，根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断，包括：

获取访问用户的访问账号；从所述至少一个账号在所述多个应用中的权限信息，确定所述访问账号对应的权限信息；根据所述访问账号对应的权限信息对所述访问账号的路由跳转请求做出权限判断；若所述账户的权限信息中包括所述路由跳转请求对应的路由节点，则执行跳转；若所述账户的权限信息中不包括所述路由跳转请求对应的路由节点，则取消跳转并显示提示信息。

上述方案中，所述多个应用中目标应用的路由信息更新时，获取所述目标应用通过钩子脚本、项目脚手架或依赖包提交的更新后的路由信息；

将所述更新后的路由信息作为所述目标应用的路由信息。

第二方面，提供了一种权限管理装置，所述装置包括：

获取模块，用于获取多个应用的路由信息，以及所述多个应用的关联关系；

构建模块，用于根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树；其中，所述路由结构树包括所述多个应用的所有路由节点；

显示模块，用于将所述路由结构树显示在权限配置界面；

配置模块，用于基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息；

处理模块，用于根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

第三方面，提供了一种权限管理设备，所述设备包括：处理器和配置为存储能够在处理器上运行的计算机程序的存储器，其中，所述处理器配置为运行所述计算机程序时，执行前述任一项所述方法的步骤。

第四方面，提供了一种计算机存储介质，其上存储有计算机程序，其中，该计算机程序被处理器执行时实现前述方法的步骤。

本申请公开了一种权限管理方法，该方法包括：获取多个应用的路由信息，以及所述多个应用的关联关系；根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树；其中，所述路由结构树包括所述多个应用的所有路由节点；将所述路由结构树显示在权限配置界面；基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息；根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。如此，通过构建路由结构树，统一配置账号在多个应用下的路由权限，可以使得权限配置更加统一高效，有效减少后期维护成本。

附图说明

图1为本申请实施例中权限管理方法的第一流程示意图；

图2为本申请实施例中权限管理方法的第二流程示意图；

图3为本申请实施例中微前端架构示意图；

图4为本申请实施例中路由结构树的图形化示意图；

图5(a)为本申请实施例中账号或角色选择框的示意图；

图5(b)为本申请实施例中角色单选框的示意图；

图6为本申请实施例中权限管理方法的第三流程示意图；

图7为本申请实施例中一种应用通过钩子脚本、项目脚手架或依赖包提交路由信息的方法；

图8为本申请实施例中权限配置界面示意图；

图9为本申请实施例中权限管理方法实现装置的示意图；

图10为本申请实施例中权限管理装置的组成结构示意图；

图11为本申请实施例中权限管理设备的组成结构示意图。

具体实施方式

为了能够更加详尽地了解本申请实施例的特点与技术内容，下面结合附图对本申请实施例的实现进行详细阐述，所附附图仅供参考说明之用，并非用来限定本申请实施例。

前端开发即web页面开发，现代前端开发框架有个重要特征即前后端分离，页面的路由切换由前端负责。随着业务规模的发展，单个前端应用的打包体积越来越大，构建所需的时间越来越久，因而出现了将多个应用集成到一个主应用中的需求。微前端是最近两年兴起的一种架构，它将多个子应用集成到一个主应用中。随着微前端架构的出现，如何为多个子应用统一配置前端路由权限成为新的挑战。本申请提出一种权限管理方法、装置、设备及存储介质，可以实现多个应用路由权限的统一配置。

图1为本申请实施例中权限管理方法的第一流程示意图，如图1所示，权限管理的方法具体可以包括：

步骤101：获取多个应用的路由信息，以及所述多个应用的关联关系。

这里，应用的路由信息用于表征单个应用下的所有路由节点的信息。其中，一个路由节点对应一个页面路径。当页面从一个路由节点跳转到另一个路由节点时，可以称为路由跳转。可以通过为账户设置有权访问的路由节点来实现权限配置。还可以针对不同路由节点设置不同的路由名称，用于对路由节点进行直观区分。

通过获取多个应用的路由信息，可以为各个应用的权限配置提供基础，这里的权限配置可以为路由权限的配置。路由权限为路由跳转的权限，用于对路由跳转进行限制，即用于对路由节点对应的页面跳转进行限制。

在一些实施例中，所述应用的路由信息包括所述应用的所有路由节点以及所述所有路由节点间的路由层级关系；其中，单个应用的所述所有路由节点包括一个根路由节点和M个子路由节点，M取大于等于0的整数。

这里，所有路由节点间的路由层级关系可以根据路由节点对应的页面路径间的层级关系得到。示例性的，根据所述路由节点间的路由层级关系，可以将单个应用的所有路由节点分为根路由节点和子路由节点。其中，单个应用的所述所有路由节点包括一个根路由节点和M个子路由节点，M取大于等于0的整数。

通过将路由节点进行层级区分，可以根据路由节点间的路由层级关系，快速查找到需要的路由节点。

这里，所述关联关系用于表征应用间的关联信息。在一个页面模块中，可以存在多个应用，多个应用之间可以存在着关联，示例性的，在微前端系统中，可以将多个应用集成在一个应用下。

在一些实施例中，所述关联关系包括所述多个应用间的应用层级关系；其中，所述应用层级关系，用于将所述多个应用分为一个主应用和N个子应用，N取大于等于1的整数。

通过获取多个应用间的应用层级关系，可以在进行权限配置时，快速查找到需要选择的应用。

步骤102：根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树；其中，所述路由结构树包括所述多个应用的所有路由节点。

这里的路由结构树用于有规律地表征所述多个应用下的所有路由节点。通过将所有应用下的所有路由节点有规律地进行整合，可以在进行路由权限配置时，快速找到并选定需要的路由节点。

步骤103：将所述路由结构树显示在权限配置界面。

这里，权限配置界面用于对所述路由结构树进行直观展示，使得权限配置人员可以直接根据路由结构树对目标账号在所述多个应用下的权限进行配置。在一些实施中，可以将路由结构树以图形化的形式展示在权限配置界面，直观地展示出所有路由节点，方便权限配置人员的配置操作。

步骤104：基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息。

这里，权限信息用于表征账号在所述多个应用中的路由权限。权限配置人员基于路由结构树进行至少一个账号的权限配置，可以实现统一为账号在多个应用下的权限进行配置，而不用在各个应用分别进行账号的权限配置，有效减小后期维护成本。

在一些实施例中，所述基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息，包括：

在所述路由结构树上选定目标账号在所述多个应用中有权访问的所有路由节点，得到所述目标账号的有权路由节点；将所述有权路由节点作为所述目标账号的权限信息；其中，所述目标账号为所述至少一个账号中任一个账号。

这里，通过将目标账号的有权路由节点作为目标账号的权限信息，可以直接根据账号的跳转请求对应的路由节点是不是该账号的有权路由节点，对账号的路由跳转请求进行权限判断。

步骤105：根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

这里，路由跳转请求为跳转到目标路由节点的请求。当访问账号登录时，可以根据访问账号的权限信息对路由跳转请求进行权限判断，进而根据判断结构确定是否执行所述路由跳转请求。

这里，步骤101至步骤105的执行主体可以为权限管理设备的处理器。

本申请的技术方案，通过由多个应用的路由信息和多个应用的关联关系，构建了一个包括所有路由节点的路由结构树，并基于该路由结构树实现了对账号在多个应用中路由权限的统一配置，并基于配置的权限对路由跳转请求做出权限判断。如此，通过构建路由结构树，统一配置账号在多个应用下的路由权限，可以使得权限配置更加统一高效，有效减少后期维护成本。

为了能更加体现本申请的目的，在本申请上实施例的基础上，进行进一步的举例说明，图2为本申请实施例中权限管理方法的第二流程示意图。如图2所示，权限管理方法具体包括：

步骤201：获取多个应用的路由信息，以及所述多个应用的关联关系；其中，应用的路由信息包括所述应用的所有路由节点以及所述所有路由节点间的路由层级关系，所述关联关系包括所述多个应用间的应用层级关系。

所述应用的路由信息包括所述应用的所有路由节点以及所述所有路由节点间的路由层级关系；其中，单个应用的所述所有路由节点包括一个根路由节点和M个子路由节点，M取大于等于0的整数。

每个路由节点包含至少两个信息，其一是页面路径，其二是用于方便识别的路由命名。路由信息可以是一种树状的数据，它的表现形式可以是JSON，也可以是XML。

所述关联关系包括所述多个应用间的应用层级关系；其中，所述应用层级关系，用于将所述多个应用分为一个主应用和N个子应用，N取大于等于1的整数。

在一些实施例中，所述获取多个应用的路由信息包括：获取多个应用通过钩子脚本、项目脚手架或依赖包提交的路由信息。

在一些实施例中，所述方法还包括：所述多个应用中目标应用的路由信息更新时，获取所述目标应用通过钩子脚本、项目脚手架或依赖包提交的更新后的路由信息；将所述更新后的路由信息作为所述目标应用的路由信息。

在一些实施例中，提交路由信息的时机还可以是代码版本更新时，以使得获取的路由信息是当前最新的路由信息。各应用可以通过用于自动读取单个应用的路由信息的脚本或者前端依赖包或者集成该依赖包的前端工程脚手架，在代码版本更新时，来提交路由信息。

步骤202：根据所述应用层级关系，确定所述多个应用中的主应用和子应用。

在一个页面模块中，可以存在多个应用，多个应用之间可以存在着关联，示例性的，在微前端系统中，可以将多个应用集成在一个应用下，图3展示了一种微前端架构示意图，在一个主应用下集成了两个子应用，分别为子应用1和子应用2，每个子应用包括3个组件。

步骤203：根据所述路由层级关系，将所述主应用的所有路由节点分为主应用根路由节点和主应用子路由节点，将所述子应用的所有路由节点分为子应用根路由节点和子应用子路由节点。

步骤204：将所述主应用根路由节点作为第一层路由节点，将所述主应用子路由节点和所述子应用根路由节点作为第二层路由节点，将所述子应用子路由节点作为第三层路由节点，得到所述路由结构树。

通过路由层级关系和应用层级关系，将主应用和子应用的路由节点展示在路由结构树中，可以在进行后续的权限配置时，快速定位到需要的路由节点。

示例性的，图4展示了一种路由结构树，如图4所示，主应用根路由对应的节点作为第一层路由节点，主应用子路由1、主应用子路由2和子应用1根路由、子应用2根路由对应的节点作为第二层路由节点，子应用1子路由1、子应用1子路由2、子应用2子路由1、子应用2子路由2对应的节点作为第三层路由节点。

步骤205：将所述路由结构树显示在权限配置界面。

这里，权限配置界面用于对所述路由结构树进行直观展示，使得权限配置人员可以直接根据路由结构树对账号在所述多个应用下的权限进行配置。在一些实施中，可以将路由结构树以图形化的形式显示在权限配置界面，直观地展示出所有路由节点，方便权限配置人员的配置操作。

上述图形化的路由结构树的显示方式包括但不限于web网页、windows客户端应用、Android客户端应用、ios客户端应用。在显示界面，除了路由结构树外，还包括账号或角色选择框，权限配置人员可以在选定账号或角色选择框中的目标账号或目标角色后，在路由结构树上勾选出该目标账号或目标角色有权访问的路由节点。将选择出的有权访问的路由节点作为该角色在多个应用中的权限信息，并将每个账号或角色的权限信息提交至服务器存在数据库中。

示例性的，权限配置界面还可以展示图5(a)所示的一种账号或角色选择框。用于对账号或角色进行选择。除了图5(a)中的角色框外，还可以通过图5(b)所示的角色单选框进行角色的展示及选择。

步骤206：基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息。

这里，权限信息用于表征账号在所述多个应用中的路由权限。权限配置人员基于路由结构树进行至少一个账号的权限配置，可以实现统一为账号在多个应用下的权限进行配置，而不用在各个应用分别进行账号的权限配置，有效减小后期维护成本。

在一些实施例中，所述基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息，包括：在所述路由结构树上选定目标账号在所述多个应用中有权访问的所有路由节点，得到所述目标账号的有权路由节点；将所述有权路由节点作为所述目标账号的权限信息；其中，所述目标账号为所述至少一个账号中任一个账号。

步骤207：根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

在一些实施例中，所述根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断，包括：

获取访问用户的访问账号；

从所述至少一个账号在所述多个应用中的权限信息，确定所述访问账号对应的权限信息；

根据所述访问账号对应的权限信息对所述访问账号的路由跳转请求做出权限判断；

若所述账户的权限信息中包括所述路由跳转请求对应的路由节点，则执行跳转；若所述账户的权限信息中不包括所述路由跳转请求对应的路由节点，则取消跳转并显示提示信息。

这里的提示信息用于提示用户该账号无权访问该跳转请求对应的路由节点。

通过在访问账号登录后，将该账号对应的权限信息与路由跳转请求对应的路由节点进行对比，可以直接根据账号的跳转请求对应的路由节点是不是该账号的权限信息中包含的路由节点，实现对账号的路由跳转请求的权限判断。

本申请的技术方案，通过将应用分为主应用和子应用，将所述主应用和主应用的所有路由节点分为主应用根路由节点和主应用子路由节点，来通过构建路由结构树，可以使得路由结构树更为直观规律地显示出多个应用下的所有路由节点，便于配置人员进行权限配置。本申请可以统一配置账号在多个应用下的路由权限，使得权限配置更加统一高效，有效减少后期维护成本。

为了能更加体现本申请的目的，在本申请上实施例的基础上，进行进一步的举例说明，图6为本申请实施例中权限管理方法的第三流程示意图，应用于微前端。

在该实施例中，微前端的实现采用qiankun框架；主、子应用前端项目均采用vue框架，依赖用webpack管理；代码管理工具为Git，提交路由信息的钩子使用pre-commit，该钩子执行一个node.js脚本，应用的路由信息直接提交至对应数据库；子应用的路由信息和应用总体的路由层级以JSON的形式传输、保存；图形化配置系统路由权限的形式为web页面，配置的服务逻辑由主应用实现。

如图6所示，权限管理方法具体流程为：

步骤601：获取多个应用通过钩子脚本、项目脚手架或依赖包提交的路由信息。

其中，应用的路由信息包括所述应用的所有路由节点以及所述所有路由节点间的路由层级关系。根据所述路由节点间的路由层级关系，可以将单个应用的所有路由节点分为根路由节点和子路由节点。其中，单个应用的所述所有路由节点包括一个根路由节点和M个子路由节点，M取大于等于0的整数。

获取多个应用通过钩子脚本、项目脚手架或依赖包提交的路由信息，还包括：在所述多个应用中目标应用的路由信息更新时，获取所述目标应用通过钩子脚本、项目脚手架或依赖包提交的更新后的路由信息；将所述更新后的路由信息作为所述目标应用的路由信息。

通过在目标应用的路由信息更新时，获取更新后的路由信息，将所述更新后的路由信息作为所述目标应用的路由信息，可以使得获取的路由信息是当前最新的路由信息。应用通过钩子脚本、项目脚手架或依赖包提交更新后的路由信息，可以实现路由信息更新时路由信息的自动提交。

在一些实施例中，提交路由信息的时机还可以是代码版本更新时，以使得获取的路由信息是当前最新的路由信息。各应用可以通过用于自动读取单个应用的路由信息的脚本或者前端依赖包或者集成该依赖包的前端工程脚手架，在代码版本更新时，来提交路由信息。

示例性的，多个应用通过钩子脚本、项目脚手架或依赖包提交路由信息可以由以下方法实现：

在单个应用的代码工程中集成一个工具依赖包。该工具依赖包的特征为，代码版本更新的时候，将应用中的路由信息提交到权限服务，使得提交到权限服务的路由信息为最新的路由信息。上述权限服务可以是当前微前端系统服务端，也可以是一个独立于业务项目的权限管理服务。对于权限服务的地址参数，仅需要在引入工具依赖包的时候设置。上述的版本更新可以是指代码的一次提交到仓库，也可以是一次版本的发布。

如果提交路由信息的时机是在代码提交时，代码管理工具包括但不限于Git和SVN。Git和SVN能在特定的重要动作触发时，触发自定义脚本，这种机制称之为钩子(hook)。在代码提交动作或者代码上传动作发生时的钩子中执行自定义的脚本，将当前应用的路由信息提交到指定地址的权限服务。

示例性的，图7展示了一种应用通过钩子脚本、项目脚手架或依赖包提交路由信息的方法，主要由步骤701和702构成：

步骤701：用项目脚手架初始化应用，修改应用中项目脚手架参数。

具体的，在微前端的所有前端应用中引入路由提交钩子脚本，设置要提交的权限服务的地址，并设置在代码管理工具Git的pre-commit(保存变化的代码在本地)时，执行该提交路由信息的脚本。

其中，钩子脚本.git/hooks/pre-commit的定义仅仅是以node自行updateFeRoutes.js(更新路由信息)。

步骤702：git commit触发pre-commit钩子，上传当前应用的路由信息。

具体的，根据Git提供的现有机制，在定义上述步骤701的.git/hooks/pre-commit脚本后，开发人员一旦执行git commit指令提交当前最新的代码，就会自动在提交前一刻的时机触发pre-commit钩子。

该钩子执行步骤701所定义的updateFeRoutes.js脚本，该脚本在读取当前应用的路由信息后直接请求权限数据库，将整个微前端应用的路由信息数据取出，更新当前应用对应的路由节点后保存回数据库。

步骤602：获取当前微前端架构下多个应用之间的应用层级关系，将所述多个应用分为主应用和子应用。

其中，所述多个应用包括一个主应用和N个子应用，N取大于等于1的整数。在一个页面模块中，可以存在多个应用，多个应用之间可以存在着关联，示例性的，在微前端系统中，可以将多个应用集成在一个应用下，图3展示了一种微前端架构示意图，在一个主应用下集成了两个子应用，分别为子应用1和子应用2，每个子应用包括3个组件。

步骤603：根据所述路由层级关系，将所述主应用的所有路由节点分为主应用根路由节点和主应用子路由节点，将所述子应用的所有路由节点分为子应用根路由节点和子应用子路由节点。

步骤604：将所述主应用根路由节点作为第一层路由节点，将所述主应用子路由节点和所述子应用根路由节点作为第二层路由节点，将所述子应用子路由节点作为第三层路由节点，得到所述路由结构树。

通过路由层级关系和应用层级关系，将主应用和子应用的路由节点展示在路由结构树中，可以在进行后续的权限配置时，快速定位到需要的路由节点。

步骤605：将所述路由结构树以图形化的形式显示在权限配置界面。

示例性的，权限配置界面采用web页面形式，如图8所示，展示了一种权限配置界面。图8所示的权限配置界面包括账号或角色选择框和路由结构树。其中，路由结构树包括主应用和自应用下的所有路由节点。账号或角色选择框用于由权限配置人员选定需要配置的目标账号或角色，路由结构树用于由权限配置人员选定目标账号有权访问的所有路由节点。

步骤606：基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息。

权限配置人员按如下步骤901-903操作以配置账号在所述多个应用中的权限信息，具体的：

步骤901：进入权限配置页面。

具体的：权限配置人员在浏览器中输入地址，进入到事先开发好的权限配置页面；权限配置页向服务器拉取整个微前端应用的路由结构树、所有账号列表、所有角色列表；权限配置页根据步骤902的信息将账号或角色选择框、路由结构树渲染。

步骤902：在权限配置页配置账号或角色的权限信息。

具体的：点击账号或角色选择框，该选择框以下拉菜单的形式展现出可选的所有账号或角色；选择下拉菜单的一项账号或角色，该下拉菜单消失，选择框展示已选中的账号或角色，所选中的账号ID或角色ID被保存在内存中；在路由结构树中勾选一个或多个路由节点，选中的路由节点以列表的形式保存在内存中；点击提交后，将上述账号ID或角色ID以及账号ID或角色ID对应的权限列表通过接口提交到服务器。

步骤903：服务器在收到“账号ID-权限列表”后，数据库的账号表中的目标项的“权限”字段被替换为新的权限列表。若收到“角色ID-权限列表”，数据库的账号表中的“角色”字段值与获得的“角色ID”一致的项，其“权限”字段被替换为新的权限列表。

步骤607：主应用根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

具体地：用户进入应用，输入账号密码进行登陆；登陆成功后，主应用通过接口拿到当前账户的权限列表，并在内存中；在主应用的路由钩子中以权限列表为依据，判断该账号所要跳转的路由节点是否有权限，若有，则执行跳转，若无，则不执行跳转并输出提示信息。

通过由主应用对访问账号进行路由跳转请求的权限判断，可以避免将权限判断的逻辑散落在各个子应用中，便于后期维护。

图9展示了一种权限管理方法的实现装置，该装置具体包括：实现脚手架，包含pre-commit和上传脚本逻辑；应用用脚手架，用于初始化应用，配置参数；权限配置页，用于实现对账户或角色的权限配置；主应用中的权限判断逻辑，用于实现对路由跳转请求的权限判断。

本申请的技术方案，通过采用钩子脚本提交应用路由信息到服务器的方案，达到多个前端应用的路由信息的自动更新与提交；通过采用图形化配置账号或角色的在所有应用中的路由权限的方案，以统一配置账号在多个应用下的路由权限，使得权限配置更加统一高效；通过采用由主应用对所有应用的路由跳转进行权限判断，可以避免将权限判断的逻辑散落在各个子应用中，使得路由拦截逻辑集中、易于后期维护。

为实现本申请实施例的方法，本申请实施例还提供了一种权限管理装置，如图10所示，该装置100包括：

获取模块1001，用于获取多个应用的路由信息，以及所述多个应用的关联关系；

构建模块1002，用于根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树；其中，所述路由结构树包括所述多个应用的所有路由节点；

显示模块1003，用于将所述路由结构树显示在权限配置界面；

配置模块1004，用于基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息；

处理模块1005，用于根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

采用上述技术方案，通过由多个应用的路由信息和多个应用的关联关系，构建了一个包括所有路由节点的路由结构树，并基于该路由结构树实现了对账号在多个应用中路由权限的统一配置，并基于配置的权限对路由跳转请求做出权限判断。如此，通过构建路由结构树，统一配置账号在多个应用下的路由权限，可以使得权限配置更加统一高效，有效减少后期维护成本。

在一些实施例中，所述应用的路由信息包括所述应用的所有路由节点以及所述所有路由节点间的路由层级关系；其中，单个应用的所述所有路由节点包括一个根路由节点和M个子路由节点，M取大于等于0的整数；

这里，所有路由节点间的路由层级关系可以根据路由节点对应的页面路径间的层级关系得到。通过将路由节点进行层级区分，可以根据路由节点间的路由层级关系，快速查找到需要的路由节点。

在一些实施例中，所述关联关系包括所述多个应用间的应用层级关系；其中，所述应用层级关系，用于将所述多个应用分为一个主应用和N个子应用，N取大于等于1的整数。

通过获取多个应用间的应用层级关系，可以在进行权限配置时，快速查找到需要选择的应用。

在一些实施例中，所述构建模块1002，用于

根据所述应用层级关系，确定所述多个应用中的主应用和子应用；

根据所述路由层级关系，将所述主应用的所有路由节点分为主应用根路由节点和主应用子路由节点，将所述子应用的所有路由节点分为子应用根路由节点和子应用子路由节点；

将所述主应用根路由节点作为第一层路由节点，将所述主应用子路由节点和所述子应用根路由节点作为第二层路由节点，将所述子应用子路由节点作为第三层路由节点，得到所述路由结构树。

通过将应用分为主应用和子应用，将所述主应用和主应用的所有路由节点分为主应用根路由节点和主应用子路由节点，来通过构建路由结构树，可以使得路由结构树更为直观规律地显示出多个应用下的所有路由节点，便于配置人员进行权限配置。

在一些实施例中，所述处理模块1005，用于所述主应用根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

在一些实施例中，所述配置模块1004，用于在所述路由结构树上选定目标账号在所述多个应用中有权访问的所有路由节点，得到所述目标账号的有权路由节点；将所述有权路由节点作为所述目标账号的权限信息；其中，所述目标账号为所述至少一个账号中任一个账号。

这里，通过将目标账号的有权路由节点作为目标账号的权限信息，可以在后续进行权限判断时，直接根据账号的跳转请求对应的路由节点是不是该账号的有权路由节点，对账号的路由跳转请求进行权限判断。

通过由主应用对访问账号进行路由跳转请求的权限判断，可以避免将权限判断的逻辑散落在各个子应用中，便于后期维护。

在一些实施例中，所述处理模块1005，用于获取访问用户的访问账号；从所述至少一个账号在所述多个应用中的权限信息，确定所述访问账号对应的权限信息；根据所述访问账号对应的权限信息对所述访问账号的路由跳转请求做出权限判断；若所述账户的权限信息中包括所述路由跳转请求对应的路由节点，则执行跳转；若所述账户的权限信息中不包括所述路由跳转请求对应的路由节点，则取消跳转并显示提示信息。

通过在访问账号登录后，将该账号对应的权限信息与路由跳转请求对应的路由节点进行对比，可以直接根据账号的跳转请求对应的路由节点是不是该账号的权限信息中包含的路由节点，实现对账号的路由跳转请求的权限判断。

在一些实施例中，所述装置100还包括更新单元(图10中未示出)，用于所述多个应用中目标应用的路由信息更新时，获取所述目标应用通过钩子脚本、项目脚手架或依赖包提交的更新后的路由信息；将所述更新后的路由信息作为所述目标应用的路由信息。

通过在目标应用的路由信息更新时，获取更新后的路由信息，将所述更新后的路由信息作为所述目标应用的路由信息，可以使得获取的路由信息是当前最新的路由信息。应用通过钩子脚本、项目脚手架或依赖包提交更新后的路由信息，可以实现路由信息更新时路由信息的自动提交。

基于上述权限管理装置中各单元的硬件实现，本申请实施例还提供了另一种权限管理设备，如图11所示，该设备110包括：处理器1101和配置为存储能够在处理器上运行的计算机程序的存储器1102；

其中，处理器1101配置为运行计算机程序时，执行前述实施例中的方法步骤。

当然，实际应用时，如图11所示，该权限管理设备中的各个组件通过总线系统1103耦合在一起。可理解，总线系统1103用于实现这些组件之间的连接通信。总线系统1103除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图11中将各种总线都标为总线系统1103。

在实际应用中，上述处理器可以为特定用途集成电路(ASIC，ApplicationSpecific Integrated Circuit)、数字信号处理装置(DSPD，Digital Signal ProcessingDevice)、可编程逻辑装置(PLD，Programmable Logic Device)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的设备，用于实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。

上述存储器可以是易失性存储器(volatile memory)，例如随机存取存储器(RAM，Random-Access Memory)；或者非易失性存储器(non-volatile memory)，例如只读存储器(ROM，Read-Only Memory)，快闪存储器(flash memory)，硬盘(HDD，Hard Disk Drive)或固态硬盘(SSD，Solid-State Drive)；或者上述种类的存储器的组合，并向处理器提供指令和数据。

在示例性实施例中，本申请实施例还提供了一种计算机可读存储介质，例如包括计算机程序的存储器，计算机程序可由权限管理设备的处理器执行，以完成前述方法的步骤。

应当理解，在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。本申请中表述“具有”、“可以具有”、“包括”和“包含”、或者“可以包括”和“可以包含”在本文中可以用于指示存在对应的特征(例如，诸如数值、功能、操作或组件等元素)，但不排除附加特征的存在。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开，不必用于描述特定的顺序或先后次序。例如，在不脱离本发明范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。

本申请实施例所记载的技术方案之间，在不冲突的情况下，可以任意组合。

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

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

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

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

Claims (11)

1.一种权限管理方法，其特征在于，所述方法包括：

获取多个应用的路由信息，以及所述多个应用的关联关系；

根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树；其中，所述路由结构树包括所述多个应用的所有路由节点；

将所述路由结构树显示在权限配置界面；

基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息；

根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

2.根据权利要求1所述的方法，其特征在于，

所述应用的路由信息包括所述应用的所有路由节点以及所述所有路由节点间的路由层级关系；其中，单个应用的所述所有路由节点包括一个根路由节点和M个子路由节点，M取大于等于0的整数。

3.根据权利要求2所述的方法，其特征在于，所述关联关系包括所述多个应用间的应用层级关系；其中，所述应用层级关系，用于将所述多个应用分为一个主应用和N个子应用，N取大于等于1的整数。

4.根据权利要求3所述的方法，其特征在于，所述根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树，包括：

根据所述应用层级关系，确定所述多个应用中的主应用和子应用；

根据所述路由层级关系，将所述主应用的所有路由节点分为主应用根路由节点和主应用子路由节点，将所述子应用的所有路由节点分为子应用根路由节点和子应用子路由节点；

将所述主应用根路由节点作为第一层路由节点，将所述主应用子路由节点和所述子应用根路由节点作为第二层路由节点，将所述子应用子路由节点作为第三层路由节点，得到所述路由结构树。

5.根据权利要求3所述的方法，其特征在于，所述根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断，包括：

所述主应用根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

6.根据权利要求1所述的方法，其特征在于，所述基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息，包括：

在所述路由结构树上选定目标账号在所述多个应用中有权访问的所有路由节点，得到所述目标账号的有权路由节点；

将所述有权路由节点作为所述目标账号的权限信息；

其中，所述目标账号为所述至少一个账号中任一个账号。

7.根据权利要求1所述的方法，其特征在于，所述根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断，包括：

获取访问用户的访问账号；

从所述至少一个账号在所述多个应用中的权限信息，确定所述访问账号对应的权限信息；

根据所述访问账号对应的权限信息对所述访问账号的路由跳转请求做出权限判断；

若所述账户的权限信息中包括所述路由跳转请求对应的路由节点，则执行跳转；

若所述账户的权限信息中不包括所述路由跳转请求对应的路由节点，则取消跳转并显示提示信息。

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

所述多个应用中目标应用的路由信息更新时，获取所述目标应用通过钩子脚本、项目脚手架或依赖包提交的更新后的路由信息；

将所述更新后的路由信息作为所述目标应用的路由信息。

9.一种权限管理装置，所述装置包括：

获取模块，用于获取多个应用的路由信息，以及所述多个应用的关联关系；

构建模块，用于根据所述关联关系，将所述多个应用的路由信息组成一个路由结构树；其中，所述路由结构树包括所述多个应用的所有路由节点；

显示模块，用于将所述路由结构树显示在权限配置界面；

配置模块，用于基于所述路由结构树，配置至少一个账号在所述多个应用中的权限信息；

处理模块，用于根据至少一个账号在所述多个应用中的权限信息，对访问账号进行路由跳转请求的权限判断。

10.一种数据处理设备，其特征在于，所述设备包括：处理器和配置为存储能够在处理器上运行的计算机程序的存储器，

其中，所述处理器配置为运行所述计算机程序时，执行权利要求1-8任一项所述方法的步骤。

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

Images