001-权限框架介绍及设计

一、为什么要自己写一个权限框架

笔者待过的多家公司内部的权限框架，大部分配置菜单/权限的功能都是先在页面上添加好，然后每个菜单/权限的判断又得单独写代码来实现，这样显示十分的麻烦。此时笔者就想着能否利用注解实现一个自动化生成菜单/权限的功能，并且能根据自定义注解判断当前用户是否有某个菜单/权限的操作。而且目前大部分的公司都用上了微服务，如果能实现统一权限管理，岂不是节省了很多时间~

二、数据库简单设计

传统的权限设计五张表：用户表、用户关联角色表、角色表、角色关联资源表、资源表；当然更细的还能带上用户关联资源表，并且有的还带上什么公司域、组织域等等，只有更复杂，没有最复杂。这里就用最简单的来展示。下面附上数据库设计图

• 资源表是这几张表中最重要的，其中笔者设计了applicationKey和systemKey，用于满足多项目，多系统的需求。
• 资源表的菜单key的设计规则是：项目英文缩写+系统资源缩写+具体模块。例如商场项目，会员系统、积分菜单可以设计为：mail.member.Integral。
• 资源表的权限key的设计规则是：项目英文缩写+系统资源缩写+具体模块+具体功能。例如商场项目，会员系统、积分模块、积分列表功能可以设计为：mail.member.Integral.list。

三、注解设计

一般系统里面的权限可以分为菜单权限、按钮权限、数据权限。菜单权限和按钮权限可以通过一套固定的规则生成，数据权限一般都是领导定制化开发，所有这里只涉及菜单权限和按钮权限。

在系统中，某个请求一般可分为无需登录即可操作，登录后即可操作，需要权限才可操作。因此笔者设计了两个注解来满足以上功能。

• NoLogin顾名思义就是无需登录即可操作。
• SourceAuth则是资源权限，其中menuKeys、authKeys设计成多个的原因是在项目中，经常某个接口需要再多个页面中使用，或者某个接口只需要众多权限中的一个即可。authName则是显示在页面上给用户看的中文名称。

四、菜单JSON设计

{
  "systemKey": "blog",
  "applicationKey": "member",
  "menus": [
    {
      "menuKey": "member",
      "menuName": "客户管理",
      "path": "#",
      "sort": 1,
      "childMenu": [
        {
          "menuKey": "member.member",
          "menuName": "客户列表",
          "path": "/member/list",
          "sort": 1
        },
        {
          "menuKey": "member.tag",
          "menuName": "客户标签管理",
          "path": "/member/tag",
          "sort": 2
        },
        {
          "menuKey": "member.integral",
          "menuName": "客户标签管理",
          "path": "/member/integral",
          "sort": 3
        }
      ]
    },
    {
      "menuKey": "system",
      "menuName": "系统管理",
      "path": "#",
      "sort": 1,
      "childMenu": [
        {
          "menuKey": "system.operateLog",
          "menuName": "系统操作日志",
          "path": "/system/operateLog",
          "sort": 2
        }
      ]
    }
  ]
}

• 其中childMenu可以无限层级写下去。
• 下层级的menuKey是上层级的menuKey加上一个.，再加上本身的key