权限设计.doc

权限设计一、引言在权限系统的设计中，权限设计分为两大块，一块是功能权限，一块是资源权限。功能权限指的是针对某一个功能，某个用户是否可以使用。在界面上的表示形式则为该菜单用户是否可见（比如左侧的导航菜单，比如工具栏的一些添加，删除等功能按钮），以及在非法调用该功能API时是否会被拦截。资源权限指的是对于某一个资源（文档，项目表之类的东西），某个用户是否可以访问，以及是否可以搜索得到。本文的权限设计就从这两个点出发，进行设计。二、数据库设计2.1 功能权限在设计功能权限之前，首先需要明确的一点就是对于每一个功能（也就是程序里的对应方法），都有一个权限对应，而用户使用该功能的时候就需要验证该功能是否在用户的权限列表中。为此我们使用一种ACL的验证方式。将一个二进制的数字表示为一个功能的权限。比如读取用户的功能的权限是0x00000001，请注意，这个权限数字是针对具体模块有效的。然后A用户自身的权限集合是0x01010101011。那么验证A是否可以读取用户，可以使用功能的权限数字与用户的权限集合进行“与“运算。如果运算后的结果与功能的权限数字相等，则意味着具备该权限。此种方法具备速度快而且同时验证多个权限组合（验证权限组合的方法先将权限组合进行”并“运算，然后再与用户的权限列表进行”与“运算）。原理讲述完毕，下面进行数据库设计。首先需要设计一张模块表用来表示系统中的不同功能。2.1.1 模块表设计模块表用来存储系统中不同作用的大模块，用于对功能进行大粒度的区分模块表Id模块名称1用户模块2角色模块接下来是设计每一个模块下的各种权限所对应的权限数字。2.1.2 模块功能表设计模块功能表的作用是明确一个模块中存在多少权限。模块功能表Id模块名称权限数字11搜索用户0x0000000121增加用户0x0000001031删除用户0x0000010041更新用户0x0000100052搜索角色0x0000000162增加角色0x0000001072删除角色0x000001002.1.3 菜单表在功能权限中，很重要的是一个就是不具备对应权限的用户，界面上的资源是无法显示，一般来说，我们指的是菜单。所以需要设计一个菜单表来表明每一个菜单需要的模块中的权限。菜单表Id菜单名称父菜单id对应模块所需权限菜单位置菜单顺序1用户管理010x00000001左侧菜单02增加110x00000010工具栏菜单13删除110x00000100工具栏菜单24编辑110x00001000工具栏菜单35查看详细信息110x00010000工具栏46角色管理020x00000001左侧菜单17增加620x00000010工具栏28删除620x00000100工具栏3通过菜单位置的识别，可以判断出当前位置需要抽取的菜单列表。而通过父菜单id可以进行菜单树的生成，而菜单顺序则负责固定菜单的顺序（比如父菜单为0的显示在第一顺序）。通过菜单表就可以确定一个用户可以显示哪些菜单。2.1.4 角色模块权限表而每一个角色所拥有的权限则是通过角色模块权限表来确定的，也就是需要确定对于每一个模块，角色拥有什么样的权限。设计如下。角色模块权限表Id角色id模块id权限1110x00010101011120x0010101010通过角色模块权限表，就能完全确定角色的权限。那么如何为每一个角色进行权限信息的生成呢。可以在编辑角色的时候，使用一个树状菜单来表示所有可以编辑的权限。然后通过菜单传递权限表中的项的id过去即可。角色是由具备创建角色权限的用户创建的。那么该角色的角色权限不能超过创建者本身的权限。2.1.5 方法权限表方法对应的具体权限可以存储在数据库中，也可以直接以注解的形式写在方法上。如果是在数据库中，类似如下id方法名模块id权限数字1UserAction.get10x000000102UserAction.delete10x00000100在判断方法是否允许被用户调用的时候，使用方法自身需求的权限数字找到用户对应模块的权限数字，两者进行与操作以确定是否可以访问。2.2 资源权限在一些系统中存在资源权限的概念。比如A公司的老总可以查看该公司下的所有资料，而A公司下的B部门的部门经理只能查看B部门下的资料，而B部门下的C项目项目经理只能查看该项目的资料。还比如其他部门只能查看本部门的人事信息，而人事部门可以查看全公司的人事信息等等。在这些系统中均存在对资源可见性控制的要求。而资源权限就是为了处理资源可见性的问题。一般认为，子组织的资源对父组织是可见的。而不同的平行组织之间的信息是无法直接共享查看的。由此可见组织关系是很重要的。首先设计组织关系表。组织关系表Id组织名称父组织id1公司02开发部13设计部14人事部1然后组织间除了上下级关系外，还有一种管理或者可见性的管理。比如人事部门对全公司都具有人事信息可见性。所以还需要额外设计一个组织可见性表。组织可见性表Id组织id可见组织id141,2,3所以在某个组织下的用户的可见性就由组织的上下关系和组织可见性管理（特殊情况通过编码解决。比如人事部门具有全公司的相关资源可见性，就在编码时直接查询全公司就好，避免每次多一个部门就需要人事部的组织可见性更新）针对文档，通讯录，信息等，将其抽象认为是一种资源。那么这种资源应该存在对某一个组织的从属信息。因为某一个资源是属于某一个组织的。这里的资源表通过资源类型进行划分，但是在实际的设计中为了方便查询，可以将资源表设计很多份。不同类型的资源都各自设计一张表。Id资源名称父资源id所属组织id资源类型1Demo开发项目01项目2开发文档111文档3开发文档211文档4视觉设计项目01项目5设计文稿141文档6设计文稿241文档当用户创建一个资源的时候，该资源默认属于该用户所在的部门。如果需要更改，只可以更改为该用户所在部门的子部门。比如部门经理可以创建一个属于项目的文件，但是项目经理无法创建属于部门的文件。2.3 从属于组织的自定义角色在一般的系统中，角色和组织是没有关系的，整个大系统使用一套角色体系。在选择角色时，所有的角色都是可见的。但是也存在一种需要，每一个组织需要创建自己的角色。平行组织创建的角色互不可见。那么这个时候就需要一个组织和角色的对应表。并且最初的用户和最大的超管是系统中固有存在的。而具备创建角色权限的用户所创建的角色的权限不会超过该用户本身。此时角色也可以认为是资源，同样遵循子组织的角色父组织可见，平行关系组织之间角色不可见。角色组织表id角色id组织id111221三、代码设计3.1 权限信息存储权限信息存储有两种。第一，直接存储调用的url需要的权限；第二，存储调用的方法需要的权限。