1.1.0.RELEASE 新概念剖析

老版本的缺点分析

在这个新版本中，我们摒弃了原有doAuth和checkLogin接口观念，主要是有多种弊端，作为一款易用框架，最主要的就是易用。

易用性上

之前采用doAuth，我们需要开发者自行完善鉴权逻辑，但是对于大多数情况来说，鉴权逻辑本身就是比较统一，换个意思来讲就是有固定模板的。

第二个就是AuthQueue，鉴权队列准确来说作用不大，并且有点逻辑漏洞，因为统一走完没必要，有点拦截器那种感觉了，而通常的业务可能会有不同的鉴权逻辑，所以我们在这个版本之后，引入了一个逻辑容器的概念

所以从之前的缺点有：

  • 用户配置复杂、冗余代码量大

  • 冗余设计

注解使用上

在之前，三个鉴权注解并不互斥，歧义性比较大，先后不明确，在1.1.0.RELEASE之后有了优先级

第二个缺点就是，鉴权过于单一，只有基于anyRole的鉴权，早期的mustRole也处于过期态，并且融入了anyRole中，在最新版本我们会还原any和must的区分，并且新增了权限码Permission鉴权

新版本概念

鉴权配置Bean

这里和老版本一样，只不过实现的接口变了，之前需要开发者自行实现doCheckLogin和doAuth两个方法，特别鸡肋

在最新的版本，我们默认直接将doCheckLogin和doAuth给实现了，开发者只需要实现返回负载拥有的角色列表和权限列表即可，前提是使用JWT作为Token，并且配置类继承于KaSecurityAuthUtil，否则你还需要实现DefaultKaSecurityAuthUtilInterface这个接口，当然你要自定义token解析，用这个也是可以的，但是我更建议还是新建一个类来实现，方便Util复用。

package cn.katool.security.demo.boot.simple.config;


import cn.katool.security.logic.KaToolSecurityAuthQueue;
import cn.katool.security.starter.utils.KaSecurityAuthUtil;

import org.springframework.context.annotation.Bean;
import org.springframework.stereotype.Component;
import cn.katool.security.logic.KaSecurityAuthLogic;
import java.util.List;


@Component
public class AuthConfig extends KaSecurityAuthUtil<User> implements KaSecurityAuthLogic<User>{


    @Override
    public List<String> getUserRoleList() {
        // 正常情况下建议用int或者枚举进行映射
        return this.getPayLoad().getUserRoles();
    }

    @Override
    public List<String> getUserPermissionCodeList() {
        // 正常情况下应该是有专门的权限服务或者读取配置来获取
        return this.getPayLoad().getUserPermissions();
    }


    @Bean
    @Override
    public void loadPlugin() {
        // 加载自定义插件
        KaToolSecurityAuthLogicContainer.insert(0,this);
    }
}

在这里面有一个loadPlugin，用作统一的Bean加载，并且放在逻辑容器中（KaToolSecurityAuthLogicContainer），这里强制写一个接口，主要是方便插件化鉴权时的Bean加载，当然，如果你觉得耦合度有点大的话，或者说你想要高内聚以下，你可以直接return，然后写个统一的@Bean

看到这里，可以发现，新版本中多了个概念——逻辑容器

逻辑容器——KaToolSecurityAuthLogicContainer

在1.1.0.RELEASE之后，我们删除了原来的KaToolSecurityAuthQueue，修改为了KaToolSecurityAuthLogicContainer

但是我们仍然保留了以前KaToolSecurityAuthQueue按照队列校验的特性，但是一般情况下不会开启（需要的话你可以手动打开，但是没啥用，用来走全部Bean，具体的操作可以看下文），那么逻辑容器有什么用？用于控制某个接口走特定的鉴权Bean，比如你有好几个业务接口，但是部分接口的鉴权方案需要重写，那么你可以给它指定一个或者多个KaToolSecurityAuthLogic的Bean来实现。

你把这个容器可以看成kv存储结构，k是index，v就是logic实例。

那么具体怎么用呢？就是结合各个注解用。

注解——@AuthControllerCheck/@AuthServiceCheck/@AuthCheck

这三个注解的具体用法在老版本中讲过，可以去看看。

但是在1.1.0.RELEASE之后，新增了注解隔离与注解优先级，其中Controller和Service注解是同级并且互斥的，另外@AuthCheck注解的优先级最大，如果类上有@AuthControllerCheck或者@AuthServiceCheck，同时，方法上有@AuthCheck注解，那么只会走@AuthCheck注解

下面对注解的几个参数来具体说一说：

Role和Permission

Role是角色，Permission是权限码

any和must

any是满足其中一个，must是全部满足

roleMode和permissionMode

分别用于控制anyRole和mustRole以及anyPermission和mustPermission，支持OR以及AND运算，默认都为AND运算

需要注意的是，role的判断逻辑和permission的判断逻辑是相互隔离的，其中一个满足就算通过，对于其他情况，比如：如果需要既满足role并且又要满足permission（或者其他更为复杂的鉴权逻辑），那么请重写doAuth接口即可

logicIndex

用于指定logic走向，填写bean在逻辑容器中的下标即可，默认为0，如果设置成Integer.MAX_INT，那么会将逻辑容器中的Bean都给走完。

以上就是主要的概念更新，下面是1.1.0.RELEASE主要做了那些更新，大家可以看一下：

版本更新内容：

目前的1.1.0版本的BETA阶段已经开发完毕，目前我们语句会在最终RELEASE的时候，对鉴权方案进行修改，主要是对Logic逻辑层进行接口修改，修改如下

  1. 在原有的rbac鉴权的基础上，新增对于权限码的鉴权
  2. 原本的logic层是一个接口，本次修改之后我们将会继承于DefaultKasecurityAuthUtil接口，所以如果直接实现logic，肯定会有方法没有重写，我们建议同时继承于KaSecurityAuthUtil类来解决这一问题
  3. 因为原有的checklogin和doauth这两种方法最实际的问题在于获取用户权限，具体的判断逻辑都是可以省略的，所以我们这次将这两种方法做了默认填补（原有的逻辑不必删除），后续不需要对这两种方法进行实现，用户只需要对getUserRoleList和getUserPermissionCodeList进行实现即可
  4. 对于AuthCheck系列注解，我们这次恢复在1.0.0版本种的mustRole，并且添加对权限码的控制，以及支持OR和AND两种运算法则给各位使用
  5. 原有的链式鉴权还是会保留，原有的按链式统一鉴权这块功能比较鸡肋，目前的优化思想：在注解中以index的方式来控制具体的逻辑走向
  6. 优化部分log以及报错信息提示
Last Updated:
Contributors: ZonglinWu