用户,角色,权限,菜单的关联关系设计

7哥 发布于 2015/06/04 17:50
阅读 12K+
收藏 5

用户,角色,权限,菜单的关联关系设计

现在的处理方式是:通过权限关联出菜单,但觉得这样有问题。

有人认为拥有了菜单就拥有的菜单下的各项操作权限,但我不这样认为

我想实现的是:菜单和菜单下的各项权限是分开的,即拥有了菜单未必拥有的菜单下的各项操作;

现在我想通过角色关联菜单,再通过角色关联权限,菜单和权限没有关联关系,一个角色只有同时拥有菜单和菜单下的权限才能有效

我想知道这样合理吗?

加载中
0
高山流水情
高山流水情

你可以参考这个开源项目的权限设计 http://www.pinhuba.com/three/101052.htm

包括菜单权限,以及菜单下面的功能(按钮)权限


0
我姓王丶
我姓王丶

当然,你现在的处理方式在某种情况下是可以的。

但是菜单只有一级吗?

如果菜单下还有菜单呢?

我明白你的思路,你是想把展现的功能和增删改都通过权限去拦截和区分粗来吧。

还是按照具体的业务来分吧。

我姓王丶
我姓王丶
@穿绿旗袍de女人 加我q吧,下班了。897858183
7哥
7哥
是两级
7哥
7哥
如果不按我说的,一般的处理方式是什么养的?菜单和权限是什么关系?
7哥
7哥
总算遇到明白人了,目前是只有一级
0
lieefu
lieefu
三层足以,把权限去掉,除非你的菜单有读写或者管理权限之分。
0
我姓王丶
我姓王丶

只有一级就好办了,所有的权限放入数据库中,项目跑起来时就全部加载出来。

如果是麻烦点的就是都区分开,比如:查看是是一个权限,增加是一个权限。。。如果没有查看权限自然没有页面,没有页面就没有增删改功能。

ps:可以分组,组在添加对应的用户。在给不同的组给不同的权限。

大概就是这样了,权限这里其实很复杂的,还是劝你先搞清楚需求。

0
魁拔
魁拔

9. Privilege

Privilege的定义是这9种AC元素的任意两两组合,两元中的一元是“主体”,一元是“客体”,主体负责感知客体。区分主客体就是为这两两组合定义了方向。一共是(9 * 8)/(2*1) = 36 + 9 = 45种结果。

Function级Privilege

在功能级权限的这45种组合中只有一种组合最关键:(Account,Function),主体是Account,客体是Function。其余44种组合的目的最终都是为了得出这个主体为Account客体为Function的组合。 每一个组合实例称作一个Privilege,Privilege也是9种AC元素的一员,有一种组合比较特殊,它是(Privilege,Privilege),这种组合目的是组成Privilege的继承链条,类似面向对象中的继承。另外上面的36+9中的9种是(Account,Account)、(Catalog,Catalog)、(Role,Role)、(Group,Group)、(Function,Function)、(Menu,Menu)、(AppSystem,AppSystem)、(ResourceType,ResourceType)、(Privilege,Privilege)。 功能级的权限是常驻内存的。
引自梁山开源权限引擎

魁拔
魁拔
菜单:https://github.com/anycmd/anycmd/wiki/elements#6-menu
0
愤怒哥
愤怒哥
菜单分成普通菜单和权限菜单两种,普通菜单可以分,不给权限菜单就可以了
0
maradona
maradona

俺觉得可以把操作独立出来一张表,配置与菜单关联,权限与角色关联,你可以做到控制到不同角色看到不同的按钮级别,当然操作最好也要有一对多的URL配置(比如某按钮弹出框,又有俩选项之类的),权限初始化的时候把角色对应的菜单权限URL和操作对应的URL加载起来,后台校验只校验URL,操作按钮的话,jsp展示就做一个自定义标签(当然俺是不知道其他后台语言是否有类似功能),这样页面展示和后台校验权限基本符合你的需求了

0
GITTODO
GITTODO

你管他有没有下拉还是其他的,每一个事件都是一个编号。有就可以操作,没有就没法操作。

0
花和尚鲁智深
花和尚鲁智深

大家一起界定一下各种AcElement组合的意思好不好?用户、角色、菜单、权限对应下面的带有它们的那些AcRecordType类型。这些组合每一个都有合适的意义,大家一起定义它们的意义好吗

public enum AcRecordType
    {
        Undefined,
        /// <summary>
        /// 主体是账户,客体也是账户。
        /// </summary>
        AccountAccount = 20,
        /// <summary>
        /// 主体是账户,客体是目录。
        /// </summary>
        AccountCatalog,
        AccountRole,
        AccountGroup,
        AccountFunction,
        AccountMenu,
        AccountAppSystem,
        AccountPrivilege,
        CatalogCatalog,
        CatalogRole,
        CatalogGroup,
        CatalogFunction,
        CatalogMenu,
        CatalogAppSystem,
        CatalogPrivilege,
        RoleRole,
        RoleGroup,
        RoleFunction,
        RoleMenu,
        RoleAppSystem,
        RolePrivilege,
        GroupGroup,
        GroupFunction,
        GroupMenu,
        GroupAppSystem,
        GroupPrivilege,
        FunctionFunction,
        FunctionMenu,
        FunctionAppSystem,
        FunctionPrivilege,
        MenuMenu,
        MenuAppSystem,
        MenuPrivilege,
        AppSystemAppSystem,
        AppSystemPrivilege,
        PrivilegePrivilege
    }



0
花和尚鲁智深
花和尚鲁智深
不止9种Ac元素。9种Ac元素都应是可以随意的两两组合的,每一种组合都应是有特定的意义的。比如(function1,menu1)可以定义为如果授予主体function1权限那么系统可以自动展示出相应的menu1而无需安全管理员再进行“菜单授权”。比如(role1,role2)的组合可以定义为role1继承role2,当然(role1,role3)表示role1集成role3,你看到了这就是RBAC的层级Role特性在Anycmd中的实现。比如(catalog1,group1)可以定义为把整个catalog1组织结构下的用户逻辑的加入group1工作组。就举这些例子吧,请注意:Anycmd的9类AC元素对象的任意两两组合都是有意义的。如果您感兴趣的话现在可以先观察Anycmd的源码,期待您为Anycmd提供帮助确保她走在正确的道路上。
返回顶部
顶部