权限控制

    权限控制的方案很多，有复杂的有简单的。不是说越复杂的越是好的，还是要看实际的情况。

 

    下面要介绍的权限方案比较适合管理消息（文章、新闻、邮件、公告）权限控制，但整体的设计思路适合N多地方。

 

方案

@假设有4中操作等级

      

操作等级	操作	加权值
1	查看	1
2	添加、修改	2
3	删除	4
4	发布	8

 

 即4位二进制来表示

    例如： 0001 查看 、1000 发布

 

 @角色

 

    根据上面的表可以得到16中角色，权值在0-15之间

 

    例如：如果某个角色的权值为13，那些可以算出他所有的权限为：查看+删除+发布（1+4+8），可以看到这个角色就是我们所说“一般的管理员”

 

 @实际中的角色设计

 

   上面的16种角色并不都是“有用的”。我们要用的可能是下面的一些角色

  

    

角色	权值	权限	说明
游客	0	无	某些情况可能必须要登陆的-例如公司OA
登陆用户	1	查看
作者本人	7	查看+添加、修改+删除
一般管理员	13	查看+删除+发布	无添加、修改权
超级管理员	15	所有权

 

 

 @设计数据库表

 

  

   1.模块角色等级表

 

        模块角色等级Id---角色名称--权值

 

   2.用户表

  

        用户Id----角色Id

 

   3.角色权限表

  

        角色Id----模块Id---模块角色等级id

 

 

  @下面以Struts中使用上面的权限管理方案为例，来说明其有效性。

 

 

    1.创建角色并分配权限

 

        按照上面的设计，分配权限的工资就不应该是指定是否有查看、添加、修改、删除权限了，而是指定他的模块角色等级。例如为该角色指定为一般管理员，这样改角色就有了查看权，删除权，发表权。

  

    2.用户角色修改

 

        按照上面的设计，用户只能有一个角色。这里的角色就像是一个用户组一样，并将该用户组成员的权限都一样。

 

        所有角色修改也是相当简单的

 

   3.权限控制

 

        采用Sruts的Interceptor进行权限控制。

 

        --1、获取用户角色Id、模块Id，从数据库中相应的模块角色等级

        --2、获取该请求的操作等级

        --3、判断是否有权

 

    例如：

         某用户向服务器发送删除某篇文章的请求，Interceptor中获取用户角色、请求的actionName 从数据查库找到该用户日志模块的操作等级为4，即他是一个一般管理员；而按照上面的设计，一般管理员有删除文章的权限。所以Interceptor将对该请求“放行”.

 

  

 ---------------------

 

  上面的权限设计只是提供一种设计的思路！不必拘泥于我给出的设计方案。

 

   也许你想设定一个新的模块角色，比如：我想设定这样一个角色，他只有查看和修改这两种权限--哦他可能的职能是一个编辑，检查有没错别字、排一下版面....

 

   这样你也许可以想到，角色的创建完全可以细颗粒到指定操作，然后根据选择算出权值。然后给角色命名---啊哈一个新的角色诞生了

 

  甚至你想这样：我需要更多的操作，比如：推荐到主页（这样将产生另一个操作：审核是否应该放到主页）。

 

 

 一句话视情况而定！

 

------------------------

 

 写的很乱，请原谅！有错的地方，或者有其他的建议，请指教！