也学框架二 权限控制

。。上章说了，一些，继续

      目前java框架很多，太多。除了知名的，各培训机构使用的类似ssh之类的外，也有很多人自己做框架，或是为了自己 做练习，或是为了想留下点什么，或者是  要顺带做的，或者就是在开发过程中遇到一些问题，却没找到合适的现有方案，所以自己做。。。。

      各种起因，最后成就了一个个开源或不开源的。新框架。。。都说有轮子不要再造轮子，但现今社会，只要你需要你的几乎任何需要都有相应的现有的解决方案，就看你是否愿意出钱。。。废话。

      为了满足某种特殊需求，或者解决一些通用问题。。总之框架总要解决什么。。

我也打算做框架了，至于解决什么问题，我也不知道，总之，目前有很强的框架，但是别人的，也可能是公司其他部门的，但使用同样需要付费，觉得麻烦，并且现有的确实很强悍，好比牛刀，但只想杀鸡，很多用不到，所以就想自己项目组搞一个。。轻便的。好用的，方便定制，可完全拥有的。。。。

      先讨论下权限。

第一步：：：：

经典的大家都知道的，基于角色的权限控制。。。通过以下表

：资源表（标明项目内资源）--资源行为表（要被用来授权的客体）----权限表（关联资源行为和角色）---角色表---人员表。

细节一：比如画面是个资源，菜单是个资源，其他自定义的比如模块是个资源。。。然后对于画面可能有新增，修改，删除的行为，对菜单有浏览等。。。新增一张表：资源类型（标注资源的一个分类），再增一张表：类型默认行为表（标注某一分类的资源默认拥有的行为）。当新增一条某类型的资源时，同时会按 类型默认行为表新增 相应的资源行为信息。。。

根据需要，比如菜单拥有自己的菜单表，那只需要通过一个类似guid的字段关联菜单表 和资源表，保持同步。。

这样可满足常用的需求统一授权：开一个默认系统级角色：系统管理员，系统管理员的成员拥有类似administartor的权限，能够操作所有资源用户，权限信息。。。根据需要添加相应的角色组，然后把相关人员加到相关资源组即可。。。如现有角色组不满足，新增新的角色即可。

--------------------以上情况：

（0）任何用户都可新建角色，当新建一个角色时，该用户默认为角色的管理员。该角色管理员可维护该角色。（包含修改角色，删除角色，维护角色管理员，维护角色成员，维护角色资源）。

（1）角色管理员可新增的管理员或者成员从全部系统成员中选择。

（2）角色管理员可新增的资源，为当前管理员自身所拥有的可授权的资源{在权限表有一个字段用来标注，相应权限是否可继续再授权}。。PS：所拥有的可授权资源，是指它所在的角色所有权限的并集 中选出标注了可继续授权的资源。

（3）角色管理员，删除成员或者管理员，或者删除角色资源不受限制。

-------优点:很简单啦，大多数人稍讲解下都知道的。。。

---------几点不足（1）用户不限制，即每个管理员都可为角色新增 任何用户，

（2）角色不分级，即所有角色时平等的，平铺开的，没有上下高低之分

(3)角色不嵌套，即角色不设置父角色，比如。现有一个角色A，新增一个角色B归属于这个角色A，那么任何用户只要属于角色B,则同时拥有角色A和B的权限。不能嵌套，那么就需要把用户拉入A角色和B角色，或者把A所有资源拉入B角色。。(4)资源不分组，比如现有一堆资源属于同一类，可将资源分组，然后可将改组授给多个角色。授一次即可，如果资源不分组，那表示需要将一堆资源分别多次拉入角色。或可通过先加入一个角色，然后复制新增该角色内资源到其他角色。

第二步：

为了维护成员，限制角色管理员可管理的用户？（此处有个疑问，如果对可操作用户限制了，那么是不是如果角色管理员A不能管理用户B，不单新增角色用户时看不到B,而且不能将B从角色中删除？？疑问？。{暂定可见就可删，谁让人家是角色管理员呢}。）

新增部门信息。默认情况下每个用户都是归属于某一个部门的（或称组织机构）。。数据库初始化时，默认有一条不定部门 的记录，则当用户还不确定部门时可归属不定部门。部门设置部门管理员，部门管理员可管理该部门下的用户。

那么，角色管理员，通常同时是部门管理员，则可新增部门下的用户，如果角色管理员不是部门管理员，则不能新增角色用户。。但能删除用户，或者维护资源

----优点：解决了角色管理员限制用户的目的。。比如一些顶级用户是不希望 其他的用户能够看到自己或者随便把自己加到 某些角色的。 

----缺点：虽把用户分开了，但资源不分级。。比如有些用户可操作的资源，只能是其他一些用户的子集。。

第三步：

为了分级，在权限表再增一个字段，授权主体类型。。即除了为角色授权外，也可针对部门授权，但针对部门的授权，只用来做 分级授权使用，即子部门所能拥有的权限只能是父部门权限的子集。。

这样角色管理员，再新增角色资源时，他所拥有的可授权的资源。就不单来源于他所在的角色， 还有可能来自部门（当他是某一部门的管理员时，他就默认拥有了该部门的权限）。切记该部门的权限只用来授权使用，此处暂定不用来享有权限（也即，如果部门管理员没加入任何角色，则不拥有任何资源。只是当把他设为某一角色的管理员时，他可以为角色添加部门下的资源，以及挑选部门下的用户）

---优点：解决了资源分级，这样的话就可限制，某些角色管理员可见的资源。。比如，如果没有部门授权，那么当新增3个角色A,B，C并设置的相应 的角色管理员A1,B1，C1那么当A B C角色所能访问的资源有包含关系时，就需要再新建三角色来放置A1,B1，C1,这样A1,B1，C1就可访问不同资源。。相当于为角色管理员设置 角色管理员角色，来限制角色管理员可授权的资源。。

--=缺点：嵌套关系还没有

第四步：

权限嵌套，可发生在部门，比如部门A下有个角色，那么部门A下的子部门AA1，如果在AA1内挂角色，那么该角色默认拥有父部门A的角色所有的权限。

这样就可实现嵌套，那就加一张部门角色表。。也即当新增一个角色时，可以指定角色的部门（0至多个）。。如果指定了部门，则只是为了做权限嵌套使用。同一个角色可指定多个部门 包含父子或者平级的部门。。

只有角色管理员才能把他所管理的角色添加到 他所管理的部门下，也即 操作用户需要即是部门管理员，且是角色管理员，才可拖拉角色到部门

-------

综上。。暂定如此。。。 可能理解上稍有难度，主要纠结一些细节，比如角色挂在了部门下，但并不表示该角色的权限 是部门权限的子集。完全没关系，只是为了嵌套使用。。当为角色添加成员时，跟角色所在部门无关，只跟当前操作的角色管理员有关。

其实很多是操作方式是否方便，是否有重复操作等问题。。人为的不要去做一些 理论上可行，但没意义的操作即可。。

---

以上主要针对授权，更多的是查询权限，当获取登录用户id后，要查询他所拥有的权限，先查询它所在的角色，包括直属角色，以及角色父部门下的所有角色。等获取到角色的并集时，再去查询相应权限。。