在上手翰短的代铝闼楝我们可以发明有四个自定义的注解，@Group、@Permission、@UserId和@UserType。

• @Permission，即为每个API(接口办法)定义一个权限，请求有name(英文格局),label(中文格局)和description(权限描述)。
• @Group，即定义的权限归属哪个权限组，推敲到一个接口中包含很多个API，接口数量又比较多，那么我们可认为每个接口下的所有办法归为一个组。营业办事可自行定义权限组，也可以选择不定义，那么会归属到默认预定义的权限组中。
• @UserId，即营业办事须要在他们的API上参加用户ID的参数，当AOP切面拦截做权限验证时刻，用户ID是须要传入的须要参数。
• @UserType，即营业办事须要在他们的API上参加用户类型的参数，当AOP切面拦截做权限验证时刻，用户类型是须要传入的须要参数。用户类许可以让同一个营业办事支撑多个用户体系。

权限入库和拦截

当API权限制义好今后，我们在权限组件琅绫擎参加扫描权限入库和拦截的算法。采取Spring AutoProxy主动代劳的框架来实现我们的扫描算法。

实现Object invoke(MethodInvocation invocation)办法，获取注解值。

根据不合注解进行不合的切面拦截，实现对@Group，@Permission、@UserId和@UserType四个注解的权限拦截逻辑

创建PermissionAutoProxy.java，持续Spring的 org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator 类，步调如下：

• 在构造办法里设置好Interceptor通用代劳器(即实现了MethodInterceptor接口的拦截类PermissionInterceptor.java)
• shouldProxyTargetClass用来决定是接口代劳，照样类代劳。在权限制义的时刻，其实我们还支撑把注解加在实现类上，而不仅仅在接口上，如许灵活应用注解放置的方法。
• getAdvicesAndAdvisorsForBean是最核心的办法，用来决定哪个类、哪个办废喔赡注解要被扫描入库，也决定哪个类、哪个办法要被代劳。
• 如不雅我们做的加倍通用一点，那么可以抽象出三个办法，供getAdvicesAndAdvisorsForBean调用。
• // 返回拦截类，拦截类必须实现 MethodInterceptor 接口，即 PermissionInterceptor
• protected abstract Class getInterceptorClass();
• // 返回接口或者类的办法名上的注解，如不雅接口或者类中办法名上存在该注解，即认为该接口或者类须要被代劳
• protected abstract Class getMethodAnnotationClass();
• // 扫描到接口或者类的办法名上的注解后，所要做的处理
• protected abstract voidmethodAnnotationScanned(Class targetClass);
• 创建PermissionScanListener.java， 实现Spring的org.springframework.context.ApplicationListener.ApplicationListener接口，步调如下
• onApplicationEvent(ContextRefreshedEvent event)办法诚实现入库代码。
• 安营业办事的Spring容器启动的时刻，将主动触发权限数据入库的事宜。

经由过程上述阐述，我们就实现了权限的扫描入库和拦截，可以参照下面的流程图

API权限所对应的角色(Role)治理

角色是一组API权限的汇总，每个角色也将和微办事名挂钩。角色组的感化是为了汇总和治理浩瀚的角色。

角色治理须要人工在界面长进行操作，角色治理分为角色组增删改查，以及每个角色组下的角色增删改查。

存在的问题：

• 因为接入权限办事的营业微办事数量还不敷多，跟着后期接入数量的增长，可能会有更多问题裸露出来，比如高并发请求、低延迟请求等等。
• 营业权限的API上都要加User ID和User Type两个参数，给他们带来些许的不适，期望将来的版本能经由过程前置埋点的方法解决。

API权限所属角色和用户User的绑定

权限不克不及直接和用户绑定，必须经由过程角色作为中心桥梁进行接洽关系。那么我们要实现：

• 角色与权限的绑定，即一个角色和多个权限的接洽关系
• 用户铀浇猾的绑定，即一个用户和多个角色的接洽关系

权限体系验证方法