API权限控制方法及装置与流程

本发明涉及分布式技术领域，尤其涉及一种应用程序接口(applicationprogramminginterface，api)权限控制方法及装置。

背景技术：

本部分旨在为权利要求书中陈述的本发明实施例提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。

近年来，随着微服务架构和前后端分离技术的不断发展，前后端分离的微服务架构已经成为门户网站或者管理系统架构中最为主流的技术架构之一。前端程序更加关注页面渲染和数据加载，而后台程序更多关注业务逻辑及返回数据的处理。后台api也由于前端渠道系统，如web端、移动端、小程序等的不断增加而增加，这样就导致针对不同访问渠道的接口权限控制变得越来越复杂。

目前api的权限控制，主要有如下两种方式：

①、通过硬编码的方式，限制api接口的访问的角色列表，缺点是不能做到灵活配置。例如，系统新增角色，需要改造程序，完成接口api的权限控制，耗时耗力。

②、通过大量配置用户和api映射关系，实现用户访问api接口的权限控制，但由于用户数量较大，且网站的api接口数据繁多，通过本种方式产生的配置文件可能会出现指数级的增长，配置参数的存储和检索都是特别大的考验。

技术实现要素：

本发明实施例提供一种api权限控制方法，用以在产生较少配置文件的基础上，实现灵活的api权限配置，该方法包括：

接收用户访问目标api路径的请求；

确定目标api路径的类别，所述类别包括白名单api、公共资源api和限定权限api，所述白名单api为任意用户可访问的api，所述公共资源api为任意登陆用户可访问的api，限定权限api为获得授权的登陆用户可访问的api；

如果目标api路径为限定权限api，则校验用户的登录信息是否正确；

如果登录信息正确，则根据登录信息确定用户对应的角色，以及角色对应的角色权限api，将角色及角色权限api的对应关系存储到redis缓存中；

将目标api路径与redis缓存中存储的角色权限api进行比对，如果角色权限api中包含目标api路径，则允许用户访问目标api路径。

本发明实施例还提供一种api权限控制装置，用以在产生较少配置文件的基础上，实现灵活的api权限配置，该装置包括：

通信模块，用于接收用户访问目标api路径的请求；

确定模块，用于确定目标api路径的类别，所述类别包括白名单api、公共资源api和限定权限api，所述白名单api为任意用户可访问的api，所述公共资源api为任意登陆用户可访问的api，限定权限api为获得授权的登陆用户可访问的api；

校验模块，用于当目标api路径为限定权限api时，校验用户的登录信息是否正确；

存储模块，用于当登录信息正确时，根据登录信息确定用户对应的角色，以及角色对应的角色权限api，将角色及角色权限api的对应关系存储到redis缓存中；

比对模块，用于将目标api路径与redis缓存中存储的角色权限api进行比对，如果角色权限api中包含目标api路径，则允许用户访问目标api路径。

本发明实施例还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述api权限控制方法。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述api权限控制方法的计算机程序。

本发明实施例中，基于rbac模型，使用了“用户-角色-资源”的模式，对用户分配角色，对角色配置了资源，也即对角色配置了每个角色可以访问的角色权限api，建立了用户与api的映射关系，从而实现了使用较少的数据存储以及较高的查询效率完成用户与api权限的访问控制。当用户访问限定权限api时，通过查询用户对应的角色，确定该角色可以访问的角色权限api，之后将角色权限api存储到redis缓存中，可以加快后续用户访问时的整体响应速度。此外，本发明实施例中，还将api划分为白名单api、公共资源api和限定权限api三种类别，不同类别api允许不同的用户访问，对于需要特定授权的限定权限api再校验用户是否具有访问权限，而用户访问白名单api和公共资源api时不进行繁琐的权限认定，提升了用户访问api对接资源的效率。

附图说明

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

图1为本发明实施例中一种api权限控制方法的流程图；

图2为本发明实施例中另一种api权限控制方法的流程图；

图3为本发明实施例中另一种api权限控制方法的流程图；

图4为本发明实施例中另一种api权限控制装置的结构示意图；

图5为本发明实施例中一种计算机设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚明白，下面结合附图对本发明实施例做进一步详细说明。在此，本发明的示意性实施例及其说明用于解释本发明，但并不作为对本发明的限定。

本发明实施例提供了一种api权限控制方法，如图1所示，该方法包括如下步骤101至步骤105：

步骤101、接收用户访问目标api路径的请求。

本发明实施例中，用户可以通过点击页面上的跳转连接，或者直接输入所要访问内容的网址等的方式触发访问目标api路径的请求。

需要说明的是，通过api访问资源，资源可以为渠道系统中的各级页面，或者各个渠道系统等。

步骤102、确定目标api路径的类别，类别包括白名单api、公共资源api和限定权限api。

其中，白名单api为任意用户可访问的api，公共资源api为任意登陆用户可访问的api，限定权限api为获得授权的登陆用户可访问的api。

也即，白名单api对应的资源对访问用户的身份没有任何限定，未注册登录用户、以注册登录用户都可以通过白名单api访问白名单api对接的资源。当确定目标api路径的类别为白名单api，则允许用户访问目标api路径。如果用户想要访问的不是白名单api中的api，则需要校验用户的身份，以确定用户是否被允许访问该目标api路径。

而公共资源api需要用户登录之后才能访问，未登录用户无法查看公共资源api对接的资源，因此，如果确定目标api路径为公共资源api，则校验用户的登录信息是否正确；如果登录信息正确，则允许用户访问目标api路径；如果登录信息不正确，则拒绝用户的本次访问。

需要说明的是，白名单api、公共资源api和限定权限api对接的资源可以由开发人员进行配置，当配置完成之后，还可以根据需求的变化随时进行修改。

步骤103、如果目标api路径为限定权限api，则校验用户的登录信息是否正确。

一般情况下，当用户输入登录信息后，登录信息会经过一定的规则之后转换为token，前端将token传递到后端，后端从token中解析出用户的登录名、密码等信息，将登录名、密码等信息与预留的登录信息进行比对，当比对结果为相同时，确定用户的登录信息正确；若比对结果为不相同，则确定用户的登录信息错误，可以提示用户登录名或密码错误，需要重新输入。

步骤104、如果登录信息正确，则根据登录信息确定用户对应的角色，以及角色对应的角色权限api，将角色及角色权限api的对应关系存储到redis缓存中。

用户及角色的对应关系、角色及角色权限api的对应关系已经预先配置好，根据用户的登录信息，以及预先配置的用户及角色的对应关系可以确定用户对应的角色，根据角色可以确定对应的角色权限api。

角色有多个，根据用户身份的不同，可以相应为其配置不同的角色，比如角色包含老板、领导和普通员工，为用户a、b、c、d分配普通员工的角色，用户e、f分配领导的角色，用户g分配领导的角色，其各自所能访问的资源不同，通过控制每个角色所能访问的api来控制通过api访问的资源。

本发明实施例中，考虑到用户可能访问多项资源，而如果每次都通过查找用户对应的角色、再查找角色对应的资源来判定用户是否具备目标api路径的访问权限，会较为繁琐，耗费用户较多时间，本发明实施例中，将查找到的用户对应角色、角色权限api存储至缓存中，这样在后续用户访问其他资源时，可以快速通过缓存中存储的角色权限api确定用户是否获得授权，从而加快了资源响应时间，为用户带来更加良好的体验。

步骤105、将目标api路径与redis缓存中存储的角色权限api进行比对，如果角色权限api中包含目标api路径，则允许用户访问目标api路径。

由于用户对应的角色、角色对应的角色权限api可能随时间会发生变化，比如说用户a升职成为部门主管，则需要为a配置“领导”这一角色，而领导可以访问的资源也可能增加或减少，此时，如图2所示，可以按照如下步骤201至步骤204对api权限进行修改：

步骤201、接收开发人员对api权限修改的更新数据。

步骤202、确定修改的类型。

其中，从更新数据中可以确定修改的类型，具体的，修改的类型包括对角色与角色权限api的对应关系的修改，以及对角色及用户的对应关系的修改。

步骤203、按照修改的类型，将更新数据添加到相应修改类型对应的消息队列中。

步骤204、按照先进先出的原则，从消息队列中取出更新数据修改相应的api权限。

考虑到多数情况下，当角色或者角色对应的资源发生变化后，往往也需要修改角色对应的用户，这样，在修改角色与角色权限api的对应关系之后，还需要再进行角色及用户关系的修改，也即需要执行两步操作，而对角色和用户对应关系的修改则只需执行一步操作，为了更加清楚对其进行区分，本发明实施例中，设置了不同的消息队列，将不同修改类型的更新数据存储至不同的消息队列中，并按照先进先出的顺序，从消息队列中提取出更新数据，逐个执行每一项修改。

同时，也由于角色与角色权限api调整后，相应的用户及角色的对应也需要调整，本发明实施例中，可以设定对角色与角色权限api的对应关系修改的消息队列中更新数据的处理优先级高于对角色及用户的对应关系修改的消息队列。这样，就不会出现先修改了用户及角色的对应关系，但后续又需要重新调整角色及用户的对应关系的“返工”的情况的出现，增加了处理的条理性，提升处理效率。

其中，如图3所示，步骤204从消息队列中取出更新数据修改相应的api权限，可以执行为如下步骤301至步骤303：

步骤301、从消息队列中取出对角色与角色权限api的对应关系的修改的更新数据。

步骤302、按照更新数据修改角色与角色权限api的对应关系后，生成新的更新数据，新的更新数据用于按照修改后的角色与角色权限api的对应关系，相应修改角色与用户的对应关系。

步骤303、将新的更新数据添加到对角色及用户的对应关系修改的消息队列中。

当对角色与角色权限api的对应关系进行调整之后，相应生成修改角色与用户的对应关系的更新数据，例如，将角色“领导”修改为“主管”，将原领导可访问的api迁移到主管对应的角色下，则为用户配置的领导角色也需要相应修改为主管角色，则在修改完角色及角色权限api对应关系之后，生成角色与用户对应关系的新的更新数据，将新的更新数据存入角色与用户对应关系的消息队列中，以便于后续按照顺序进行处理。

本发明实施例中，基于rbac模型，使用了“用户-角色-资源”的模式，对用户分配角色，对角色配置了资源，也即对角色配置了每个角色可以访问的角色权限api，建立了用户与api的映射关系，从而实现了使用较少的数据存储以及较高的查询效率完成用户与api权限的访问控制。当用户访问限定权限api时，通过查询用户对应的角色，确定该角色可以访问的角色权限api，之后将角色权限api存储到redis缓存中，可以加快后续用户访问时的整体响应速度。此外，本发明实施例中，还将api划分为白名单api、公共资源api和限定权限api三种类别，不同类别api允许不同的用户访问，对于需要特定授权的限定权限api再校验用户是否具有访问权限，而用户访问白名单api和公共资源api时不进行繁琐的权限认定，提升了用户访问api对接资源的效率。

本发明实施例中还提供了一种api权限控制装置，如下面的实施例所述。由于该装置解决问题的原理与api权限控制方法相似，因此该装置的实施可以参见api权限控制方法的实施，重复之处不再赘述。

如图4所示，该装置400包括通信模块401、确定模块402、校验模块403、存储模块404和比对模块405。

其中，通信模块401，用于接收用户访问目标api路径的请求；

确定模块402，用于确定目标api路径的类别，类别包括白名单api、公共资源api和限定权限api，白名单api为任意用户可访问的api，公共资源api为任意登陆用户可访问的api，限定权限api为获得授权的登陆用户可访问的api；

校验模块403，用于当目标api路径为限定权限api时，校验用户的登录信息是否正确；

存储模块404，用于当登录信息正确时，根据登录信息确定用户对应的角色，以及角色对应的角色权限api，将角色及角色权限api的对应关系存储到redis缓存中；

比对模块405，用于将目标api路径与redis缓存中存储的角色权限api进行比对，如果角色权限api中包含目标api路径，则允许用户访问目标api路径。

在本发明实施例的一种实现方式中，

通信模块401，还用于接收开发人员对api权限修改的更新数据；

确定模块402，还用于确定修改的类型，修改的类型包括对角色与角色权限api的对应关系的修改，以及对角色及用户的对应关系的修改；

队列管理模块406，还用于按照修改的类型，将更新数据添加到相应修改类型对应的消息队列中；

更新模块407，用于按照先进先出的原则，从消息队列中取出更新数据修改相应的api权限。

在本发明实施例的一种实现方式中，更新模块407，用于：

从消息队列中取出对角色与角色权限api的对应关系的修改的更新数据；

按照更新数据修改角色与角色权限api的对应关系后，生成新的更新数据，新的更新数据用于按照修改后的角色与角色权限api的对应关系，相应修改角色与用户的对应关系；

将新的更新数据添加到对角色及用户的对应关系修改的消息队列中。

在本发明实施例的一种实现方式中，对角色与角色权限api的对应关系修改的消息队列中更新数据的处理优先级高于对角色及用户的对应关系修改的消息队列。

在本发明实施例的一种实现方式中，

当确定模块402确定目标api路径为白名单api时，比对模块405允许用户访问目标api路径；或者，

当确定模块402确定目标api路径为公共资源api时，校验模块403校验用户的登录信息是否正确；比对模块405，用于当登录信息正确时，允许用户访问目标api路径。

本发明实施例中，基于rbac模型，使用了“用户-角色-资源”的模式，对用户分配角色，对角色配置了资源，也即对角色配置了每个角色可以访问的角色权限api，建立了用户与api的映射关系，从而实现了使用较少的数据存储以及较高的查询效率完成用户与api权限的访问控制。当用户访问限定权限api时，通过查询用户对应的角色，确定该角色可以访问的角色权限api，之后将角色权限api存储到redis缓存中，可以加快后续用户访问时的整体响应速度。此外，本发明实施例中，还将api划分为白名单api、公共资源api和限定权限api三种类别，不同类别api允许不同的用户访问，对于需要特定授权的限定权限api再校验用户是否具有访问权限，而用户访问白名单api和公共资源api时不进行繁琐的权限认定，提升了用户访问api对接资源的效率。

本发明实施例还提供一种计算机设备，图5为本发明实施例中计算机设备的示意图，该计算机设备能够实现上述实施例中的api权限控制方法中全部步骤，该计算机设备具体包括如下内容：

处理器(processor)501、存储器(memory)502、通信接口(communicationsinterface)503和通信总线504；

其中，所述处理器501、存储器502、通信接口503通过所述通信总线504完成相互间的通信；所述通信接口503用于实现相关设备之间的信息传输；

所述处理器501用于调用所述存储器502中的计算机程序，所述处理器执行所述计算机程序时实现上述实施例中的api权限控制。

本发明实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有执行上述api权限控制方法的计算机程序。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。