1. 需求描述

最近在梳理springboot前后端分离后的权限管理问题。前段时间，已经把shiro的实现和spring security 的实现进行了初步的了解。如果深入细节，一个篇幅怕是不够。本文仅对权限管理的一些通用原理进行探讨。

2. 权限分类

在前后端分离之后，对于权限方面，主要存在两方面的权限：
（1）前端页面访问权限
（2）后台接口访问权限。

下面分别以页面权限和接口权限两个方面展开讨论。

3. 页面权限管理

页面权限管理，即前端的不同页面需要不同的页面访问权限，比如，某一个页面A，需要超级管理员才能访问；某一个页面B，需要管理员才能访问；某一个页面C，普通注册用户就能访问；某一个页面D，不需要认证就能访问。从这里，我们可以抽象出几个最基本的概念。某一个用户，拥有若干角色；而某一个角色能够访问若干页面。在数据库层面，对应了几张表，即 用户表，用户角色表，角色表，角色菜单表，菜单表。
那么，如何实现呢？
在回答这个问题之前，可以参考以下几篇文章：
（1）Vue动态加载组件的两类方式（import和require）
（2）Vue动态路由的后端实现（基于AOP的思路）
（3）Vue动态路由的前端实现
从这几篇文章中，不难发现。页面可以通过动态路由的方式来渲染。再结合上权限，很自然的想到了解决方案。即某一个用户登录认证成功后，一方面会返回一个token作为后续访问的凭证，另一方面，同时查询数据库，返回该用户角色对应的菜单列表。不同的用户，拥有不同的菜单列表。
某个用户的菜单列表返回前端后，在前端完成渲染，从而达到了页面权限管理的作用。当然，再细粒度一点，也是可以做的，即在页面中，某一个组件的渲染，也采用动态渲染的方式，即把该组件对应的渲染权限保存在数据库中，用户登录的时候，随着user对象一同返回前端，完成渲染。不过，页面权限和页面内组件权限，通常是两个不同层面的解决方案。思想是相通的。如果某个页面，限制某个角色才能访问，通常，该页面也就不对页面内组件再进行角色权限分配了（虽然可以实现，但明显增加了复杂性）。因为如果对页面内组件进行角色权限分配，就没有必要再对该页面进行上一层的可访问性动态渲染控制。通常情况下，某一个具体的页面权限控制，是从该两种方案中二选一的关系。即要么进行该页面的动态渲染，某些用户角色可以访问该页面，某些用户角色不能够访问该页面。要么对该页面内的组件进行权限控制，某些用户角色能够访问该页面内的某些组件，某些用户角色不能够访问该页面内的某些组件。
如果只进行了页面权限控制，而对后台接口没有进行权限限制。那么，如果一个用户登录系统后，通过该用户凭证，就可以无限制的访问后台接口（因为后台接口仅需要完成认证），通过模拟的浏览器软件，进行接口操作，可能会给系统带来很大的安全隐患。
那么，就得对后台的接口进行权限控制，以下将展开讨论。

4. 接口权限管理

这里的接口权限管理，主要指springboot中的后台接口的授权访问权限。那么，如何实现呢？
某一个用户登录的时候，会携带该用户名（用户id）以及密码（或是验证码）在后台完成密码比对，或是验证码比对，确认身份成功后（即认证成功后）会返回一个token信息，作为该用户的一个凭证返回前台，前台保存该用户的token信息，以后访问接口，携带该token进行访问。
在后台，该用户登录完成认证后，系统会查询数据库，获取该用户的角色列表，以及该角色列表对应的可访问接口的权限列表。后台把该用户的角色列表，以及对应权限列表注入spring容器里面。具体管理角色权限方式，可以用shiro，当然，也可以用spring security。在此基础之上，某一个用户登录，系统中就会保存该用户的角色列表，以及对应的权限列表。
但是，后台的接口权限验证方式，通常并不是对所有的接口都进行权限验证，比如，登录就是对所有的用户都可以访问的接口。如果用集合A来表示所有的接口集，集合B来表示需要权限才能够访问的接口集。显然，集合B 是集合A的真子集。即在数据库中，需要保存一份集合B，即权限表。这里可以做这样一个假定，假定接口和权限存在 1:1的关系，事实上，他们也是一对一的关系，因为这里从定义就可以看出，这里研究的就是接口的权限，一个接口就有一个接口的权限。那么，在权限表（接口权限表）中，我们就可以把涉及到需要权限才能够访问的接口存在权限表中。
而仅有权限表也是不够的，我们还需要角色权限表，即某一个用户角色可以访问权限表中的一个子集C。另一个用户角色可以访问权限表中的另一个子集D。
回到刚才的话题，某一个用户登录，系统中就会保存该用户的角色列表，以及对应的权限列表。
那么，某一个用户登录认证成功后，再次访问其他接口的时候，如何判断该接口是需要授权才能够访问呢，还是不需要授权就可以访问。 在这里，有几种方案可供选择，这也是本文探讨的重点。主要有以下两种实现方式：
（1）在某一个接口上标明一个注解，表示该接口需要什么角色才能够访问，或者，该接口需要什么权限才能访问。那么，对于登录的用户，shiro或者spring security 会帮我们判断，该用户是否拥有该角色或是否拥有该权限，从而是通过该访问请求，还是拒绝该访问请求，当然，这个工作，也可以自己写一个切面去实现。
但是，这种方式存在一个缺点，就是接口的权限，无法一目了然的统一管理。即我们需要去翻阅代码，才知道哪个接口上标注了权限注解，哪个接口上没有标注权限注解。数据库中的权限表（接口权限表）中的权限，并不一定要全部标注在接口上。可能会有预留的情况。
（2）另一种方式是，接口上不添加注解。系统中保存一份需要权限访问的接口列表（从数据库查询）。即权限表中保存的是需要权限才能访问的所有接口列表。
从上得知，某一个用户登录，系统中就会保存该用户的角色列表，以及对应的权限列表。即保存了该用户对应的可以访问的接口权限列表。
那么，当该登录用户访问其他接口的时候，用aop拦截，判断该接口是否在需要权限才能访问的接口里面。如果不在，则通行；如果在，再判断该用户有没有该接口的权限。如果没有，则抛出没有权限的异常返回。如果有，则通行。
（3）当然，在这里还有另一种判断选择。同样接口上不添加注解。但在shiro或是spring security中注入的不是该用户拥有的接口权限，而是该用户被拒绝的接口权限。即在该用户登录的时候，在后台查询数据库，根据该用户拥有的权限接口，以及所有需要权限才能访问的接口，获取需要权限但该用户没有权限的接口，即该用户不能访问的权限接口。
在该用户访问其他接口的时候，在aop里面，判断该访问的接口是不是在拒绝权限的接口里面，如果是，则拒绝访问，否则，则通行。
以上三种方式，各有优缺点，在此不再展开。后续探讨后，再开篇幅进一步探讨权限相关的内容。