3. 基于角色和操作的权限设计






如上图所示，我们在添加了Role，和RoleAction表，这样子就可以减少UserAction中的记录，并且使设计更灵活一点。

　　但是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。

4. 2,3组合的权限设计，其结构如下：






我们可以看到在上图中添加了UserAction表，使用此表来添加特殊用户的权限，改表中有一个字段HasPermission可以决定用户是否有某种操作的权限，改表中记录的权限的优先级要高于UserRole中记录的用户权限。这样在应用程序中我们就需要通过UserRole和 UserAction两张表中的记录判断权限。

　　到这儿呢并不算完，有可能用户还会给出这样的需求：对于某一种action所操作的对象某一些记录会有权限，而对于其他的记录没有权限，比如说一个内容管理系统，对于某一些频道某个用户有修改的权限，而对于另外一些频道没有修改的权限，这时候我们需要设计更复杂的权限机制。


5. 对于同一种实体（资源）用户可以对一部分记录有权限，而对于另外一些记录没有权限的权限设计：







对于这样的需求我们就需要对每一种不同的资源创建一张权限表，在上图中对Content和Channel两种资源分别创建了 UserActionContent和UserActionChannel表用来定义用户对某条记录是否有权限；这种设计是可以满足用户需求的但是不是很经济，UserActionChannel和UserActionContent中的记录会很多，而在实际的应用中并非需要记录所有的记录的权限信息，有时候可能只是一种规则，比如说对于根Channel什么级别的人有权限；这时候呢我们就可以定义些规则来判断用户权限，下面就是这种设计。


6. 涉及资源，权限和规则的权限设计





在这种设计下角色的概念已经没有了，只需要Rule在程序中的类中定义用户是否有操作某种对象的权限。


<转载文章，出处来源不明> 责任编辑：C/S框架网

---

扫一扫加微信