权限的表设计

合集下载

权限设计

权限设计

权限设计权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。

一、数据库设计权限表及相关内容大体可以用六个表来描述,如下:1角色表:包括四个字段:角色ID,角色名,对该角色的描述,创建时间;2用户表:包括八个字段:用户ID,账户名称,姓名,联系电话,邮箱,密码,备注,创建时间等;3用户-角色表:包括三个字段:ID(编号,自增,方便维护,查询),用户ID,角色ID。

该表记录用户与角色之间的对应关系,一个用户可以隶属于多个角色,一个角色也可以拥有多个用户;4角色-权限表:包括三个字段:ID(编号,自增,方便维护,查询),角色ID,权限ID。

该表记录角色与权限之间的对应关系,一个权限可以隶属于多个角色,一个角色也可以拥有多个权限。

特别说明:若用户所属于两个角色,取出对应角色中的所有权限,则用户的权限为分别继承两个角色的权限的并集,过滤掉相同的权限取其中一个。

5权限表:权限表包括六个字段:权限ID,资源路径,权限名,用户展示,创建时间,描述。

权限类型包括三种:菜单、页面元素、资源路径。

a菜单:包括一级菜单、二级菜单(子菜单,可扩展菜单)菜单表:包括三个字段菜单ID,菜单名称,父菜单IDb页面元素:设置权限到页面的级别,所有的人都可以访问一个页面,一部分可以进行添加操作,一部分人可以进行删除操作,一部分可以进行审核工作等。

即设置同一个页面的不同操作权限。

c资源路径:如上传文件,文件的修改删除操作,资源路径的访问等。

用户展示为前端展示给用户的文字或图标(包括没有对应路径的图标),可选择展示或隐藏,表设计如下:1角色表(mp_role)字段名称字段类型备注角色ID role_id varchar(50) pk, not null角色名roleName varchar(255) not null描述description varchar(255)创建时间createTime varchar(255)2用户表(mp_user)字段名称字段类型备注用户ID user_id varchar(50) pk, not null账户名称userName varchar(255) not null姓名realName varchar(255) not null联系电话phone varchar(255)密码password varchar(25)邮箱email varchar(255)描述description varchar(255)创建时间createTime varchar(255)3用户-角色表(mp_user_role)字段名称字段类型备注ID id varchar(50) pk, not null 角色ID role_id varchar(50) fk, not null 用户ID user_id varchar(50) fk, not null 4角色-权限表(mp_role_permission)字段名称字段类型备注ID id varchar(50) pk, not null 角色ID role_id varchar(50) fk, not null 权限ID permission_id varchar(50) fk, not null 5权限表(mp_permission)字段名称字段类型备注权限ID id varchar(50) pk, not null 资源路径resourcePath varchar(255)权限名称permissionName varchar(255)用户展示display varchar(255)描述description varchar(255)创建时间createTime varchar(255)6二、应用程序接口(API)设计界面设计1新建角色,实现:用户可以继承所属角色的部分权限,如某用户所属于A和B两个角色,但分别继承它们的部分权限,设计为取两个角色权限的交集。

权限系统设计五张表

权限系统设计五张表

权限系统设计五张表今天开始,做旅游⽹站的后台管理,众所周知,权限系统是每个系统⾥⾯必备的最基本的系统,然⽽权限系统设计有点挺⿇烦,现在整理了下,分享给正在开发此模块的朋友⼀个思路! 设计基础:⽤户、⾓⾊、权限三⼤核⼼表,加上⽤户⾓⾊、⾓⾊权限两个映射表(⽤于给⽤户表联系上权限表)。

这样就可以通过登录的⽤户来获取权限列表,或判断是否拥有某个权限。

⼤致⽤到5张表:⽤户表(UserInfo)、⾓⾊表(RoleInfo)、菜单表(MenuInfo)、⽤户⾓⾊表(UserRole)、⾓⾊菜单表(RoleMenu)。

各表的⼤体表结构如下: 1、⽤户表(UserInfo):Id、UserName、UserPwd 2、⾓⾊表(RoleInfo):Id、RoleName 3、菜单表(MenuInfo):Id、MenuName 4、⽤户⾓⾊表(UserRole):Id、UserId、RoleId 5、⾓⾊菜单表(RoleMenu):Id、RoleId、MenuId 最关键的地⽅是,某个⽤户登录时,如何查找该⽤户的菜单权限?其实⼀条语句即可搞定: 假如⽤户的⽤户名为Arthur,则他的菜单权限查询如下: Select m.Id,m.MenuName from MenuInfo m ,UserInfo u, UserRole ur, RoleMenu rm Where m.Id = rm.MenuId and ur.RoleId = rm.RoleId and erId = u.Id and erName = 'Arthur' 任何权限的需求,都是为⼴义的⽤户分配⾓⾊,⾓⾊拥有⼴义的权限。

⾓⾊是最重要的中枢,隐藏做幕后⿊⼿,从不出现在业务代码⾥,⽤⾏话说就是解除了⽤户和权限的直接耦合。

⾓⾊把⽤户抽象化了,⼏百个⽤户变成成⼏个⾓⾊,⽤户->⾓⾊->权限写成通⽤判断权限的⽅法:currUser.IsHave(xx权限)。

权限管理数据表设计

权限管理数据表设计

权限管理数据表设计
权限管理数据表是一种用于管理和控制系统中用户权限的数据结构。

它通常包含了用户、角色和权限之间的关系,以及对应关系的细节信息。

通过合理设计和使用权限管理数据表,系统管理员可以灵活地分配和撤销用户的权限,确保系统的安全性和稳定性。

在权限管理数据表的设计中,通常包含以下几个主要的数据表:
1. 用户表:用户表是权限管理数据表中的核心表格,它记录了系统中的所有用户信息,包括用户ID、用户名、密码等。

此外,用户表还可以包含一些额外的用户信息,如用户角色、所属部门等。

2. 角色表:角色表用于定义不同角色的权限集合,每个角色可以包含多个权限。

角色表中一般包含角色ID、角色名称和角色描述等字段。

3. 权限表:权限表用于存储系统中的所有权限信息,包括权限ID、权限名称和权限描述等字段。

权限可以是系统功能的访问权限,也可以是数据操作的权限。

4. 用户角色关系表:用户角色关系表用于记录用户和角色之间的关系。

该表通常包含用户ID和角色ID两个字段,用于表示用户与角色的对应关系。

5. 角色权限关系表:角色权限关系表用于记录角色和权限之间的关
系。

该表包含角色ID和权限ID两个字段,用于表示角色与权限的对应关系。

通过合理设计上述数据表,可以实现灵活的权限管理。

系统管理员可以根据实际需求,为不同的用户分配不同的角色和权限,从而实现对系统资源的合理控制和管理。

权限管理数据表设计是一个重要且复杂的任务。

只有合理设计和使用权限管理数据表,才能确保系统的安全性和稳定性。

通过灵活的权限管理,可以满足不同用户的需求,提高系统的可用性和用户体验。

权限设计方案范本

权限设计方案范本

权限设计方案权限管理设计一•博客分类:•设计设计模式数据结构应用程序权限设计我们在开发系统的时候,经常会遇到系统需要权限控制,而权限的控制程度不同有不同的设计方案。

1. 基于角色的权限设计这种方案是最常见也是比较简单的方案,不过一般有这种设计已经够了,因此微软就设计出这种方案的通用做法,这种方案对于每一个操作不做控制,只是在程序中根据角色对是否具有操作的权限进行控制;这里我们就不做详述2. 基于操作的权限设计这种模式下每一个操作都在数据库中有记录,用户是否拥有该操作的权限也在数据库中有记录,结构如下:可是如果直接使用上面的设计,会导致数据库中的UserAction 这张表数据量非常大,因此我们需要进一步设计提高效率,请看方案33. 基于角色和操作的权限设计如上图所示,我们在添加了Role,和RoleAction表,这样子就能够减少UserAction中的记录,而且使设计更灵活一点。

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

4. 2,3组合的权限设计,其结构如下:我们能够看到在上图中添加了UserAction表,使用此表来添加特殊用户的权限,改表中有一个字段HasPermission能够决定用户是否有某种操作的权限,改表中记录的权限的优先级要高于UserRole中记录的用户权限。

这样在应用程序中我们就需要经过UserRole和UserAction两张表中的记录判断权限。

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

集团公司权限一览表 模版

集团公司权限一览表 模版















1
√ √ √
②报董事 会

②报董事 会

②报董事
√ √

②报董事 会
√ √
集团公司权限一览表
权限 类别
事项
集团
转正定薪 子公司
集团
子公司内部 员工平行调

跨公司调配
集团
人力 资源 管理

薪酬调整
子公司
权限图示 子事项
①②③④⑤⑥表示对输出文件的审核顺序;相同数字表示同步审核;“△”表示“审核”;“○”表示“备案”; “√”表示“审批” ;“◇”表示“受理”
5千元以下(含) 集团 1万-25万元(含)




公司固定资 1万元以下(含) 产采购 子公司


2.5万元-25万元(含)



2.5万元以下(含)

集团
1千元-2.5万元(含)



资产处置权 1千元以下(含) 限 子公司
5千元-2.5万元(含)




6
集团公司权限一览表
资产处置权
权限 类别
2千元以下(含)

集团
5
集团公司权限一览表
财务
管理

权限图示 ①②③④⑤⑥表示对输出文件的审核顺序;相同数字表示同步审核;“△”表示“审核”;“○”表示“备案”; “√”表示“审批” ;“◇”表示“受理”
权限 类别
事项
子事项 1千元-3万元(含)

系统权限设计

系统权限设计

系统权限设计需求陈述•不同职责的人员,对于系统操作的权限应该是不同的。

可以对“组”进行权限分配。

•对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。

所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。

•权限管理系统应该是可扩展的。

它应该可以加入到任何带有权限管理功能的系统中。

就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。

•满足业务系统中的功能权限。

传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能(以后可以加入权限分配管理的功能,目前暂不考虑)首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。

如下图:首先,action表(以下简称为“权限表”),gorupmanager 表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。

如下图:这三个表之间的关系是多对多的,一个权限可能同时属于多个管理组,一个管理组中也可能同时包含多个权限。

同样的道理,一个人员可能同时属于多个管理组,而一个管理组中也可能同时包含多个人员。

如下图:由于这三张表之间存在着多对多的关系,那么它们之间的交互,最好使用另外两张表来完成。

而这两张表起着映射的作用,分别是“actiongroup”表(以下简称“权限映射表”)和“mastergroup”表(以下简称“人员映射表”),前者映射了权限表与管理组表之间的交互。

后者映射了人员表与管理组表之间的交互。

权限系统设计五张表

权限系统设计五张表

权限系统设计五张表在进行权限系统设计时,一项十分重要的任务是设计适当的数据库表结构。

数据库表的设计决定了系统的灵活性、效率和数据的完整性。

本文将介绍一个权限系统的设计,包括五张表的设计和结构。

表一:用户表(User)该表用于存储系统中的用户信息。

它包含以下字段:1. 用户ID(UserID):用于唯一标识每个用户的ID。

2. 用户名(Username):用户的登录名。

3. 密码(Password):用户的密码,需要进行加密存储。

4. 姓名(Name):用户的真实姓名。

5. 邮箱(Email):用户的电子邮箱地址。

6. 手机号码(PhoneNumber):用户的手机号码。

表二:角色表(Role)角色表用于存储系统中的角色信息,该表包含以下字段:1. 角色ID(RoleID):用于唯一标识每个角色的ID。

2. 角色名称(RoleName):角色的名称,如管理员、普通用户等。

3. 角色描述(RoleDescription):对角色进行详细描述。

表三:权限表(Permission)权限表用于存储系统中的权限信息,该表包含以下字段:1. 权限ID(PermissionID):用于唯一标识每个权限的ID。

2. 权限名称(PermissionName):权限的名称,如查看、编辑等。

3. 权限描述(PermissionDescription):对权限进行详细描述。

表四:角色-权限关联表(RolePermission)角色-权限关联表用于记录角色和权限之间的关系,该表包含以下字段:1. 关联ID(ID):用于唯一标识每个角色-权限关联的ID。

2. 角色ID(RoleID):与角色表中的角色ID关联。

3. 权限ID(PermissionID):与权限表中的权限ID关联。

表五:用户-角色关联表(UserRole)用户-角色关联表用于记录用户和角色之间的关系,该表包含以下字段:1. 关联ID(ID):用于唯一标识每个用户-角色关联的ID。

安全(权限)管理数据库表设计

安全(权限)管理数据库表设计
长度
NULL
字段说明
备注
PowerID
int
×
权限标识
PK
PowerName
nvarchar
50
×
权限名称
UQ
角色-权限AQRolesPowers
字段名称
字段类型
长度
NULL字Leabharlann 说明备注RoleID
int
×
角色标识
FK
PowerID
int
×
权限标识
FK
功能AQFunctions
字段名称
字段类型
长度
NULL
FK
Telephone
nvarchar
50
电话
Mobile
nvarchar
50
手机
Email
nvarchar
50
电子邮件信箱
角色AQRoles
字段名称
字段类型
长度
NULL
字段说明
备注
RoleID
int
×
角色标识
PK
RoleName
nvarchar
50
×
角色名称
UQ
权限AQPowers
字段名称
字段类型
int
×
操作员标识
PK
LoginName
nvarchar
50
×
操作员登录名
UQ
UserName
nvarchar
50
×
操作员姓名
Password
varbinary
128
×
操作员密码
gongdqbs
int
×
供电区标识

权限系统设计

权限系统设计

权限系统设计权限管理就是管理⽤户对于资源的操作,CRM(客户管理软件)基于⾓⾊操作权限来实现的,就是⽤户通过⾓⾊和权限来实现的。

⼀共涉及5张表三张主表user表(⽤户表)role表(⾓⾊表)module表(模块表,资源表)两张中间表user_role表(user,role中间表)role_module表(role,module中间表)1--创建⽤户表2create table users(3--主键4 id number(10) primary key,5--⽤户名6 username varchar2(100),7--密码8 password varchar2(100),9--地址10 address varchar2(100)11 );12--创建⾓⾊表13create table role(14--主键15 id number(10) primary key,16--⾓⾊名称17 name varchar2(100)18 );19--创建模块表20create table module(21--主键22 id number(10) primary key,23--模块名称24 name varchar2(100),25--模块级别26 level_ number(3),27--⽗模块id28 pid number(10),29--模块路径30 url varchar2(100)31 );32--创建⽤户⾓⾊中间表33create table user_role(34--⽤户表外键35 u_id number(10),36--⾓⾊表外键37 r_id number(10)38 );39--创建⾓⾊模块中间表40create table role_module(41--⾓⾊表外键42 r_id number(10),43--模块表外键44 m_id number(10)45 );46--往⽤户表插⼊数据47insert into users values(1,'zhangsan','123456','郑州');48insert into users values(2,'lisi','123456','郑州');49--往⾓⾊表插⼊数据50insert into role values(1,'普通⽤户');51insert into role values(2,'管理员');52--往模块表插⼊数据53insert into module values(1,'系统管理',1,null,null);54insert into module values(2,'订单管理',1,null,null);55insert into module values(3,'⽤户管理',2,1,'user/list.do');56insert into module values(4,'⾓⾊管理',2,1,'role/list.do');57insert into module values(5,'模块管理',2,1,'mod/list.do');58insert into module values(6,'出库单管理',2,2,'ckd/list.do');59insert into module values(7,'⼊库单管理',2,2,'rkd/list.do');60--为张三⽤户赋予管理员的⾓⾊,为李四赋予普通⽤户的⾓⾊61insert into user_role values(1,2);62insert into user_role values(2,1);63--让管理员可以看到所有的菜单普通⽤户只能看到订单管理下所有的菜单64insert into role_module values(2,1);65insert into role_module values(2,2);66insert into role_module values(2,3);67insert into role_module values(2,4);68insert into role_module values(2,5);69insert into role_module values(2,6);70insert into role_module values(2,7);71insert into role_module values(1,2);72insert into role_module values(1,6);73insert into role_module values(1,7);74select*from users;75select*from role;76select*from user_role;77select*from module;78select*from role_module;三、权限管理的步骤第⼀步,⽤户登陆成功之后,根据⽤户的id查询出⽤户所能操作的模块,模块⼀般包含两级。

用户权限管理设计方案【精选文档】

用户权限管理设计方案【精选文档】

用户权限管理设计方案用户认证管理设计方案1 设计思路为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。

1。

1 用户用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。

用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。

用户通常具有以下属性:✓编号,在系统中唯一。

✓名称,在系统中唯一。

✓用户口令.✓注释,描述用户或角色的信息。

1.2 角色角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性:✓编号,在系统中唯一。

✓名称,在系统中唯一。

✓注释,描述角色信息1.3 权限权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属性:✓编号,在系统中唯一。

✓名称,在系统中唯一。

✓注释,描述权限信息1。

4 用户与角色的关系一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。

用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如●用户(User):UserID UserName UserPwd1 张三 xxxxxx2 李四 xxxxxx……●角色(Role):RoleID RoleName RoleNote01 系统管理员监控系统维护管理员02 监控人员在线监控人员03 调度人员调度工作人员04 一般工作人员工作人员……●用户角色(User_Role):UserRoleID UserID RoleID UserRoleNote1 1 01 用户“张三”被分配到角色“系统管理员"2 2 02 用户“李四”被分配到角色“监控人员”3 2 03 用户“李四”被分配到角色“调度人员”……从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。

权限 数据库 表结构

权限 数据库 表结构

权限数据库表结构全文共四篇示例,供读者参考第一篇示例:权限数据库表结构是指在数据库中存储权限信息的表的结构,用来管理用户的访问权限和操作权限。

权限数据库是一个非常重要的数据库,它负责管理系统中所有用户的权限信息,包括用户的角色、组织结构、权限分配等信息。

一个完善的权限数据库表结构能够提供灵活、安全的权限管理功能,保证系统的安全性和稳定性。

一个权限数据库通常包括多张表,每张表存储不同的权限信息。

下面我们来介绍一个典型的权限数据库表结构,包括用户表、角色表、权限表和用户角色关联表等表。

1. 用户表:用户表存储系统中所有用户的基本信息,包括用户ID、用户名、密码、邮箱等信息。

用户表是权限数据库的基础表之一,用来标识系统中的所有用户。

用户表的表结构如下:CREATE TABLE role (roleid INT PRIMARY KEY,rolename VARCHAR(50) NOT NULL,roledesc VARCHAR(100));4. 用户角色关联表:用户角色关联表用来存储用户和角色之间的关联关系,一个用户可以拥有多个角色。

用户角色关联表的表结构如下:CREATE TABLE role_permission (roleid INT,permissionid INT,PRIMARY KEY(roleid, permissionid),FOREIGN KEY(roleid) REFERENCES role(roleid),FOREIGN KEY(permissionid) REFERENCES permission(permissionid));第二篇示例:权限数据库是一个用于存储和管理权限信息的数据库,通常在权限管理系统中使用。

在权限管理系统中,权限数据库表结构的设计至关重要,不仅能够有效地存储权限信息,还能够提供高效的权限管理功能。

一个合理的权限数据库表结构设计将会使权限管理系统更加稳定、高效。

权限表设计和实现

权限表设计和实现

权限表设计和实现设计一个权限表涉及到多个步骤,需要明确哪些角色和用户具有哪些权限。

以下是一个简单的权限表设计和实现过程:1. 确定需求:首先,你需要明确你的应用程序或系统需要哪些类型的权限。

例如,你可能需要读取、写入、修改或删除的权限。

此外,还需要确定系统中有哪些角色或用户可能需要这些权限。

2. 创建数据库表:接下来,你需要创建一个数据库表来存储权限信息。

这个表通常会有以下几个字段:`id`:唯一标识符`role_id` 或 `user_id`:标识角色或用户的ID`permission_name`:表示权限名称,例如“读取”、“写入”等3. 关联角色和用户:如果系统中存在角色和用户,你需要创建一个关联表来存储角色和用户之间的关系。

这个关联表通常会有以下几个字段:`id`:唯一标识符`role_id` 或 `user_id`:标识角色或用户的ID`permission_id`:标识权限的ID4. 实现权限检查:在应用程序中,你需要实现一个权限检查的逻辑。

当用户尝试执行某个操作时,系统会检查该用户是否具有执行该操作的权限。

这通常涉及到查询数据库,查看用户的角色或用户是否具有执行该操作的权限。

5. 安全考虑:在设计权限表时,还需要考虑安全性问题。

例如,应该避免使用硬编码的密码或凭据,而应该使用加密的密码存储方法。

此外,还需要确保只有授权的用户才能访问和修改权限表。

6. 扩展性:随着应用程序或系统的增长,可能需要添加更多的权限和角色。

因此,设计权限表时应该考虑到未来的扩展性。

例如,可以使用面向对象的设计方法,将权限、角色和用户抽象为类和对象,以便更容易地添加新的权限和角色。

请注意,这只是一个简单的示例,实际的权限表设计和实现可能会更复杂。

具体的设计和实现方式取决于你的应用程序或系统的需求和规模。

管理员后台权限的设计和配置

管理员后台权限的设计和配置

管理员后台权限的设计和配置一、设计在PRolePermissionAction表中通过当前用户所具有的角色ID找到用户所对应的角色所具有的操作权限列表,通过当前所请求的页面的URL在用户的角色所对应的操作权限列表中是否存在,来判断当前用户对该页面所具有的权限,该方法控制到页面级是完全可以的但是要想具体到操作级别除非页面的Action跟页面不是同一个页面才可以(此设计的不足之处在于要想控制到操作级别Action和Page不能是同一个页面,还有就是每个菜单必须首先要配一个浏览的操作)。

管理员后台跟权限有关的表有以下几个:3. PModule:模块表(此表需要手动去维护,左侧的菜单来源于这个表,每新增加一个模块,需要把模块的信息维护到这个表中)4. PermissionAction:模块操作表(每个模块下的操作的拆分,此表需要手动维护,每新增加一个模块,需要把模块下的所有操作拆分开来,然漂友会后维护到这个表中,以便角色管理时给对应的角色分配相应的操作权限)5. PRolePermissionAction:角色权限表(给每个角色分配不同的操作权限,这个表通过角色管理来维护)二、配置(拿公共类管理里的角色管理举例)1.在PModule中手动维护角色管理的信息如下图:目前只支持到三级菜单,父级菜单无需配置ModuleUrl,最后一级菜单才需要ModuleUrl。

配置好后左侧菜单就会出现角色管理那一项。

如果是超级管理员的话就可以访问角色管理的页面了。

2.将角色管理页面上的操作拆分,并维护PermissionAction表,如下图:每一个的菜单所对应的页面,必须配置一个浏览操作,如果不配置的话普通管理员是访问不了该页面的,如上图所示将角色管理拆分出来了三个操作,配置完后角色管理的添加和修改操作中就可以看到刚才配置的信息了,如下图:2.给相应的角色配置角色管理的操作权限:选中需要的操作,点确定即可,这样就在PRolePermissionAction表中保存了该角色所具有的操作权限了。

权限管理表设计

权限管理表设计

权限管理表设计权限管理表主要记录用户的权限信息,包括用户的角色、菜单、操作和资源等。

具体的表设计如下:用户表(user)- 用户ID(user_id):主键,用户的唯一标识- 用户名(username):用户的登录名- 密码(password):用户登录的密码- 姓名(name):用户的真实姓名- 手机号(phone):用户的联系电话- 邮箱(email):用户的邮箱地址角色表(role)- 角色ID(role_id):主键,角色的唯一标识- 角色名称(role_name):角色的名称- 角色描述(role_description):角色的描述信息用户角色关系表(user_role)- 用户角色关系ID(user_role_id):主键,用户角色关系的唯一标识- 用户ID(user_id):外键,关联到用户表的用户ID- 角色ID(role_id):外键,关联到角色表的角色ID菜单表(menu)- 菜单ID(menu_id):主键,菜单的唯一标识- 菜单名称(menu_name):菜单的名称- 菜单路径(menu_path):菜单的访问路径角色菜单关系表(role_menu)- 角色菜单关系ID(role_menu_id):主键,角色菜单关系的唯一标识- 角色ID(role_id):外键,关联到角色表的角色ID- 菜单ID(menu_id):外键,关联到菜单表的菜单ID操作表(operation)- 操作ID(operation_id):主键,操作的唯一标识- 操作名称(operation_name):操作的名称菜单操作关系表(menu_operation)- 菜单操作关系ID(menu_operation_id):主键,菜单操作关系的唯一标识- 菜单ID(menu_id):外键,关联到菜单表的菜单ID- 操作ID(operation_id):外键,关联到操作表的操作ID资源表(resource)- 资源ID(resource_id):主键,资源的唯一标识- 资源名称(resource_name):资源的名称- 资源路径(resource_path):资源的访问路径角色资源关系表(role_resource)- 角色资源关系ID(role_resource_id):主键,角色资源关系的唯一标识- 角色ID(role_id):外键,关联到角色表的角色ID- 资源ID(resource_id):外键,关联到资源表的资源ID通过以上表的设计,可以实现对用户权限的管理。

用户权限管理设计方案

用户权限管理设计方案

用户权限管理设计方案用户认证管理设计方案1 设计思路为了设计一套具有较强可扩展性的用户认证管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。

1.1 用户用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。

用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。

用户通常具有以下属性:✓编号,在系统中唯一。

✓名称,在系统中唯一。

✓用户口令。

✓注释,描述用户或角色的信息。

1.2 角色角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性:✓编号,在系统中唯一。

✓名称,在系统中唯一。

✓注释,描述角色信息1.3 权限权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属性:✓编号,在系统中唯一。

✓名称,在系统中唯一。

✓注释,描述权限信息1.4 用户与角色的关系一个用户(User)可以隶属于多个角色(Role),一个角色组也可拥有多个用户,用户角色就是用来描述他们之间隶属关系的对象。

用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如●用户(User):UserID UserName UserPwd1 张三xxxxxx2 李四xxxxxx……●角色(Role):RoleID RoleName RoleNote01 系统管理员监控系统维护管理员02 监控人员在线监控人员03 调度人员调度工作人员04 一般工作人员工作人员……●用户角色(User_Role):UserRoleID UserID RoleID UserRoleNote1 1 01 用户“张三”被分配到角色“系统管理员”2 2 02 用户“李四”被分配到角色“监控人员”3 2 03 用户“李四”被分配到角色“调度人员”……从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。

1.5 权限与角色的关系一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。

关于C#的权限管理设计方案

关于C#的权限管理设计方案

……
l 角色(Role):
RoleID RoleName RoleNote
01 系统管理员 监控系统维护管理员
02 监控人员 在线监控人员
第三步用户(User)使用Administrator分配给的权限去使用各个系统模块。利用存储过程GetUserRole(@UserID, @UserRoleID output),GetRolePermission(@RoleID,@Role-
-PermissinID output)获得用户对模块的使用权限。
1 1 01 用户“张三”被分配到角色“系统管理员”
2 2 02 用户“李四”被分配到角色“监控人员”
RoleName
角色名称
varchar(20)
RoleNote
角色信息描述
varchar(20)
2.2.3 用户-角色表(Static_User_Role)
Static_User_Role
Static_User字段名
0004 察看监控信息 允许察看监控对象
……
l 角色权限(Role_Permission):
RolePermissionID RoleID PermissionID RolePermissionNote
1 01 0001 角色“系统管理员”具有权限“增加监控”
权限管理设计方案
--董帅
1 设计思路
为了设计一套具有较强可扩展性的权限管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下。
1.1 用户
用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。

基本的rbac表设计

基本的rbac表设计

基本的rbac表设计第一:基于角色的访问控制(RBAC)是一种广泛应用于信息系统的权限管理模型。

在RBAC中,通过定义角色、权限和用户之间的关系,实现对系统资源的灵活管理。

本文将详细介绍基本的RBAC表设计,包括角色表、权限表、用户表以及关联表等,帮助读者理解和应用RBAC模型。

第二:RBAC基本表设计1.角色表(Role):–用于存储系统中定义的各种角色信息。

sqlCREATE TABLE role(role_id INT PRIMARY KEY,role_name VARCHAR(255) NOT NULL,description TEXT);2.权限表(Permission):–用于存储系统中各种权限的信息。

sqlCREATE TABLE permission (permission_id INT PRIMARY KEY,permission_name VARCHAR(255) NOT NULL,description TEXT);3.用户表(User):–用于存储系统用户的基本信息。

sqlCREATE TABLE user(user_id INT PRIMARY KEY,username VARCHAR(255) NOT NULL,password VARCHAR(255) NOT NULL,email VARCHAR(255),-- 其他用户信息字段);4.用户角色关联表(User_Role):–用于建立用户和角色之间的多对多关系。

sqlCREATE TABLE user_role (user_id INT,role_id INT,PRIMARY KEY(user_id, role_id),FOREIGN KEY(user_id) REFERENCES user(user_id),FOREIGN KEY(role_id) REFERENCES role(role_id));5.角色权限关联表(Role_Permission):–用于建立角色和权限之间的多对多关系。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

基于RBAC的权限分配:在做权限分配时:首先需要几张表。

见下图用户表角色表:用户角色表:角色权限表:struts2 角色权限filter(过滤器)和interceptor(拦截器)分类:mvc框架-struts22012-12-23 11:27 358人阅读评论(0) 收藏举报Struts2项目通过使用Struts的if标签进行了session判断,使得未登录的用户不能看到页面,但是这种现仅仅在view层进行,如果未登录用户直接在地址栏输入登录用户才能访问的地址,那么相应的action还是会执行,仅仅是不让用户看到罢了。

这样显然是不好的,所以研究了一下Struts2的权限验证。

权限最核心的是业务逻辑,具体用什么技术来实现就简单得多。

通常:用户与角色建立多对多关系,角色与业务模块构成多对多关系,权限管理在后者关系中。

对权限的拦截,如果系统请求量大,可以用Struts2拦截器来做,请求量小可以放在filter中。

但一般单级拦截还不够,要做到更细粒度的权限控制,还需要多级拦截。

不大理解filter(过滤器)和interceptor(拦截器)的区别,遂google之。

博文中有介绍:1、拦截器是基于java的反射机制的,而过滤器是基于函数回调。

2、过滤器依赖与servlet容器,而拦截器不依赖与servlet容器。

3、拦截器只能对action请求起作用,而过滤器则可以对几乎所有的请求起作用。

4、拦截器可以访问action上下文、值栈里的对象,而过滤器不能。

5、在action的生命周期中,拦截器可以多次被调用,而过滤器只能在容器初始化时被调用一次。

为了学习决定把两种实现方式都试一下,然后再决定使用哪个。

权限验证的Filter实现:web.xml代码片段1<!-- authority filter 最好加在Struts2的Filter前面-->2<filter>3<filter-name>SessionInvalidate</filter-name>4<filter-class>filter.SessionCheckFilter</filter-class>5<init-param>6<param-name>checkSessionKey</param-name>7<param-value>loginName</param-value>8</init-param>9<init-param>10<param-name>redirectURL</param-name>11<param-value>/entpLogin.jsp</param-value>12</init-param>13<init-param>14<param-name>notCheckURLList</param-name>15<param-value>/entpLogin.jsp,/rois/loginEntp.action,/entpRegister.jsp,/test.jsp,/ rois/registerEntp.action</param-value>16</init-param>17</filter>18<!--过滤/rois命名空间下所有action -->19<filter-mapping>20<filter-name>SessionInvalidate</filter-name>21<url-pattern>/rois/*</url-pattern>22</filter-mapping>23<!--过滤/jsp文件夹下所有jsp -->24<filter-mapping>25<filter-name>SessionInvalidate</filter-name>26<url-pattern>/jsp/*</url-pattern>27</filter-mapping>SessionCheckFilter.java代码28package filter;29import java.io.IOException;30import java.util.HashSet;31import java.util.Set;32import javax.servlet.Filter;33import javax.servlet.FilterChain;34import javax.servlet.FilterConfig;35import javax.servlet.ServletException;36import javax.servlet.ServletRequest;37import javax.servlet.ServletResponse;38import javax.servlet.http.HttpServletRequest;39import javax.servlet.http.HttpServletResponse;40import javax.servlet.http.HttpSession;41/**42 * 用于检测用户是否登陆的过滤器,如果未登录,则重定向到指的登录页面配置参数checkSessionKey 需检查的在 Session 中保存的关键字43 * redirectURL 如果用户未登录,则重定向到指定的页面,URL不包括 ContextPathnotCheckURLList44 * 不做检查的URL列表,以分号分开,并且 URL 中不包括 ContextPath45 */46public class SessionCheckFilter implements Filter {47protected FilterConfig filterConfig = null;48private String redirectURL = null;49private Set<String> notCheckURLList = new HashSet<String>();50private String sessionKey = null;51@Override52public void destroy() {53 notCheckURLList.clear();54 }55@Override56public void doFilter(ServletRequest servletRequest,57 ServletResponse servletResponse, FilterChain filterChain)58throws IOException, ServletException {59 HttpServletRequest request = (HttpServletRequest) servletRequest;60 HttpServletResponse response = (HttpServletResponse) servletResponse;61 HttpSession session = request.getSession();62if (sessionKey == null) {63 filterChain.doFilter(request, response);64return;65 }66if ((!checkRequestURIIntNotFilterList(request))67 && session.getAttribute(sessionKey) == null) {68 response.sendRedirect(request.getContextPath() + redirectURL);69return;70 }71 filterChain.doFilter(servletRequest, servletResponse);72 }73private boolean checkRequestURIIntNotFilterList(HttpServletRequest request) {74 String uri = request.getServletPath()75 + (request.getPathInfo() == null ? "" : request.getPathInfo());76 String temp = request.getRequestURI();77 temp = temp.substring(request.getContextPath().length() + 1);78// System.out.println("是否包括:"+uri+";"+notCheckURLList+"=="+notCheckURLList.contains(uri));79return notCheckURLList.contains(uri);80 }81@Override82public void init(FilterConfig filterConfig) throws ServletException {83this.filterConfig = filterConfig;84 redirectURL = filterConfig.getInitParameter("redirectURL");85 sessionKey = filterConfig.getInitParameter("checkSessionKey");86 String notCheckURLListStr = filterConfig87 .getInitParameter("notCheckURLList");88if (notCheckURLListStr != null) {89 System.out.println(notCheckURLListStr);90 String[] params = notCheckURLListStr.split(",");91for (int i = 0; i < params.length; i++) {92 notCheckURLList.add(params[i].trim());93 }94 }95 }96}权限验证的Interceptor实现:使用Interceptor不需要更改web.xml,只需要对struts.xml进行配置struts.xml片段97<!-- 用户拦截器定义在该元素下 -->98<interceptors>99<!-- 定义了一个名为authority的拦截器 -->100<interceptor name="authenticationInterceptor"class="interceptor.AuthInterceptor"/>101<interceptor-stack name="defualtSecurityStackWithAuthentication">102<interceptor-ref name="defaultStack"/>103<interceptor-ref name="authenticationInterceptor"/>104</interceptor-stack>105</interceptors>106<default-interceptor-ref name="defualtSecurityStackWithAuthentication"/> 107<!-- 全局Result -->108<global-results>109<result name="error">/error.jsp</result>110<result name="login">/Login.jsp</result>111</global-results>112<action name="login"class="action.LoginAction">113<param name="withoutAuthentication">true</param>114<result name="success">/WEB-INF/jsp/welcome.jsp</result>115<result name="input">/Login.jsp</result>116</action>117<action name="viewBook"class="action.ViewBookAction">118<result name="sucess">/WEB-INF/viewBook.jsp</result>119</action>AuthInterceptor.java代码120package interceptor;121import java.util.Map;122import com.opensymphony.xwork2.Action;123import com.opensymphony.xwork2.ActionContext;124import com.opensymphony.xwork2.ActionInvocation;125import com.opensymphony.xwork2.interceptor.AbstractInterceptor;126public class AuthInterceptor extends AbstractInterceptor {127private static final long serialVersionUID = -5114658085937727056L;128private String sessionKey="loginName";129private String parmKey="withoutAuthentication";130private boolean excluded;131@Override132public String intercept(ActionInvocation invocation) throws Exception { 133134 ActionContext ac=invocation.getInvocationContext();135 Map<?, ?> session =ac.getSession();136 String parm=(String) ac.getParameters().get(parmKey);137138if(parm!=null){139 excluded=parm.toUpperCase().equals("TRUE");140 }141142 String user=(String)session.get(sessionKey);143if(excluded || user!=null){144return invocation.invoke();145 }146 ac.put("tip", "您还没有登录!");147//直接返回 login 的逻辑视图148return Action.LOGIN;149 }150}使用自定义的default-interceptor的话有需要注意几点:1.一定要引用一下Sturts2自带defaultStack。

相关文档
最新文档