权限设计方案.doc

权限设计的方案 通用权限管理系统的模型设计 原来的权限管理，是将“模块权限”和“资源权限”直接分配给“用户”。 好处：易于实现，在“模块权限”和“资源权限”的控制上面，比较方便，容易。 坏处：用户类别多，用户数量大时，整个系统维护工作量大。 如果引入“角色”，如果将“用户”归到“角色”中，将“权限”分配到“角色”中，权限管理的维护工作将大大降低。同时，系统也方便实现，以下是基于“角色”的权限管理模型。 第一个版本 因为，这个“权限管理模型”不是单独一个系统使用，它是几个系统同时使用，所以在设计时，时刻需要注意，“权限”粒度的问题。以下为设计时，所需要注意的问题。 1．“用户”可以拥有多个“角色”，如果“用户”只有一个“角色”，的确是很方便实现，但是有以下的情况存在： 例如，某用户，在系统A中，分配的“权限”是可以查看和修改某类资源的“权限”，跟其他部分用户权限一样，而在系统B中，分配的“权限”是“管理员”的“权限”，但是其他部分用户的权限不是“管理员”的“权限”。 如果在“权限管理”中，分配一个“角色”，对应一个“用户”，对于以上的问题，将会有“角色”会彭胀，同时，无法“复用”已经分配好的“角色”。所以应该是，将权限分配到不同的“角色”上。“用户”同时分配几个不同的“角色”，注意，“角色”中不要有冲突。 例如：“角色A”拥有管理系统A模板A的“审核权限”，“角色A1”却只拥有查看系统A模板A的“查看权限”，将“角色A”和“角色A1”，同时分配给“用户1”，“用户1”登录系统A时，将无法判断，使用那一个角色。 2．“操作权限”，系统是由各种“模块”组成的，这里并不将模块先进行分类，然后再给予权限，这是因为每种类“模块”拥有权限控制也不一定相同， 例如，列表，在不同的模块下面，它拥有的权限也是不一样的。可能有，“删除”，“修改”，也可能只有“查看”功能。同时，编辑页面来讲，在类似论坛的这种系统上面，它可以有审核，修改，删除，置顶之类的操作，而在业务类的系统中，它无法置顶。 3.“权限”，系统中所拥有的细节“权限”，它只是用于标记，因为在分模块的团队开发中，在“权限”控制上面，各模块的开发者可能都会用自己的方言来定义各种“权限”标识，不利维护和统一维护。 4．“模块”，系统中所拥有的“模块”，包含用于“导航”并没有具体页面的模块，用于最后编辑修改的非导航的“模块”等。 5．“资源”，系统中所拥有的各种“资源”，一般是“表”，针对“表”的字段写条件表达式。 6．“系统”，子系统的集合。 这个“权限管理”解决了，维护工作量大的问题，而且在分配权限上面，相当的方便。 带来一个问题，在同一个系统中，同一个模块，同样的操作下，资源的受权不一样，如下表： 角色 模块 操作 资源 A A 修改，查看 {A},{A,B} B A 修改，查看 {A,B},{A,B} 表 不同角色相同操作不同资源 在这种细粒度下的分配资源，按以上方式，会不方便，不灵活。可见变化点其实在于资源的分配上面。借助于历史上各位前辈的思想，再给资源和角色之间，加一个间接层，如下图所示： 第二个版本 “资源角色”体现的就是“角色”在“模块”中“操作”受限的“资源”。在设计“资源角色”注意点。 1．“资源角色”是一个变化点，在维护资源的时候，“资源”在，“资源角色”在，“资源”删除，“资源角色”也需要删除。 2．“资源角色”需要体现“模块”，“操作”，“资源”的特性。可以看到此模型比较复杂，“资源角色”好像是占了“角色”的责任。 3．“模块”应该是一种，拥有“资源”的可“操作”的对象。这里好像，“资源”跟“模块”不在一起了。 第三版本 “模块”本来就应该拥有“操作”和“资源”，在现实中，它有一个隐含条件，要么是拥有一个“操作”，意味着，拥有了可以操作，跟此“操作”相关的所有资源的权限；要么是拥有一个“操作”，只有“操作”没有“资源”。 “资源”是，“模块”中的受控资源。 “资源规则”体现的是“模块”+“操作”+“资源”形式的规则。所以它跟三块都有关系。这里和“资源”分离，是因为，它可变性很大，而“资源”可变性小。 欢迎批评。