[发明专利]用户权限的动态配置方法、网关及系统

说明书

本发明公开一种用户权限的动态配置方法、网关及系统。其中方法包括：步骤S101,接收当前用户登录信息中的用户身份标识信息及应用组信息；步骤S102,根据用户身份标识信息及应用组信息，匹配预存的用户身份、应用组与API应用程序接口的对应信息，提取当前用户的API应用程序接口列表；步骤S103,判断当前用户请求的API应用程序接口信息是否在当前用户的API应用程序接口列表中，若在，则通过当前用户请求的API访问权限，若否，则不通过当前用户请求的API访问权限。本申请通过网关预存的用户与API的对应关系，实现“用户”的权限进行动态分配，在提高用户管理灵活性的同时，降低了系统数据的整体变动频次，提高了系统的稳定性。

技术领域

本发明涉及用户权限管理、开发及应用领域，尤其涉及用户权限的动态配置方法、网关及系统。

背景技术

在现有的应用平台使用过程中，用户通过用户名和密码后，经过鉴权校验获取当前用户的权限关系，根据不同权限执行相应权限配置的功能。现有的用户权限关系的角色-菜单-功能都是配置好的，给用户分配的角色决定用户的可操作功能有哪些，用户角色是静态的，不能进行动态配置。

因此，现有绝大多数平台的用户权限系统角色是设计时就已固化，给用户设置角色时只能从有限的角色选择分配，不支持动态角色分配不同菜单功能；api接口访问权限对应菜单需要多次重复配置，如果某个url未配置，该模块将不能显示正常；菜单信息是通过js配置信息维护，增一个菜单即需要修改代码，极大降低开发效率。因此，权限关系的角色-菜单-api都是程序静态写入，不能满足客户不同场景给予角色赋予不同权限功能，这样就导致了一个平台很难满足定制化角色和定制化菜单权限，只能在有限的角色获取功能权限集合。

发明人在实现本申请的过程中发现，目前现有的平台不能满足定制化角色和定制化菜单，原因有以下几个方面，首先，不同平台的业务开发流程千差万别，能支撑的权限关系功能也有很大差异。其次，其他平台的组织关系化分不会很细致，比如：游客-注册未激活用户-个人开发者-团队开发者-团队项目组开发者-组成员分配自定义角色，在用户不同身份时对应不同功能权限，权限支持动态配置，这些不同组织关系对于开发的成本会比较高。此外，用户支持加入公司的不同项目组中，在各项目组中会担任不同的角色，切换项目组会有不同的操作权限功能，因此不同组织切换或团队级别可操作的权限等想要很完美的融合到平台是一个很大的挑战。

由此可知，现有的用户权限多为静态分配方式，当新用户加入，或是团队人员变动时，将要重新对用户权限进行配置。不仅操作繁琐，同时不利于对用户权限的统一管理，增加了系统的操作。并且不利于用户的实施操作，降低了系统的可用性。

发明内容

本发明实施例提供一种用户权限的动态配置方法、网关及系统，用于至少解决上述技术问题之一。

第一方面，本发明实施例提供一种用户权限的动态配置方法，

本发明首先平台支持菜单(功能)动态配置，通过给菜单指定code,此code会与api做关联。在不同项目中，管理员或超管可以分配自定义角色，配置该角色能够访问的菜单功能，用户加入项目组后默认给予成员角色，也可动态分配自定义角色，这样就可以支持用户在各个项目组中拥有管理员或超管配置的自定义角色。同时DUI平台用户权限支持角色组成关系，不同角色不用重复配置菜单-api关系，造成冗余数据关系，DUI平台用户权限将用户登陆后的都共有的权限配置为“系统公共权限”，加入团队后共有的权限配置为“团队公共权限”，项目组自定义角色权限拥有“游客权限+系统公共权限+团队公共权限”的角色组合，因此在功能配置时对于公共部分的菜单配置极大减少了配置和代码功能量。

具体包括：

步骤S101，接收当前用户登录信息中的用户身份标识信息及应用组信息；

步骤S102，根据所述用户身份标识信息及应用组信息，匹配预存的用户身份、应用组与API应用程序接口的对应信息，提取当前用户的API应用程序接口列表；