RBAC权限管理
在RBAC 中，许可Permissions （特权）就是允许对一个或多个客体执行的权力，角色就是许可的集合，如图1 所示。RBAC 的基本思想就是把整个访问过程分为两步：访问权限与角色关联，角色再与用户关联，从而实现了用户与访问权限的逻辑分离。
用户权限菜单树
用TreeView 控件动态实现用户权限菜单树的基本思想是：根据角色访问控制（RBAC ）的基本原理，给用户分配不同的角色，每个角色对应一些权限，然后根据用户ID 获取用户对应的角色集合，由角色集合获取对应的权限集合，再由权限集合利用TreeWiew 控件动态生成一棵由该用户对应的角色能访问的页面（模块）组成的权限树。这样，用户无权访问的页面在权限菜单树就不会出现，不同的用户进入的界面不同，实现了用户权限的统一管理。
用户管理模块分为：删除用户、浏览用户和角色分配三个子模块，主要负责各类用户的删除、合法性验证及为用户分配角色。用户管理模块中并没有增加用户子模块的功能，主要是由用户注册模块来实现的。
权限管理模块分为：角色管理和访问控制两个子模块。角色管理负责管理各类角色（增、删、改），为角色授予相应信息服务模块的使用权限，删除角色的某个模块的 使用权限等；访问控制是保证信息安全的关键，用户登录时经身份验证后，系统根据用户具有角色的信息服务模块的使用权限自动生成访问权限集，使得用户能够访 问授权的信息，拦截对没有授权信息服务的访问。
实体层的几个主要类及关键方法如下：
（1 ）用户类User ：
GetUserLogin(string sUserName,string sPassword) ：用户登录验证。
GetRoleByUser(int nUserID) ：由用户ID 返回该用户所有的角色集。
AddUserRole(int nUserID,int nRoleID):
为用户分配角色。
GetUserPermissionList( int userID ) ：得到用户的所有权限集。
（2 ）角色类RoleEntity ：
AddRoleModule(int nTreeID,int nRoleID) ：为角色分配权限。
DeleteRoleModule(int nRoleID) ：删除角色拥有的权限。
GetModuleByRole(int nRoleID) ：由角色ID 得到该角色的权限集。
（3 ）权限树类Tree ：
BindTree(TreeView treeView,int userID): 生成树目录。
CreateChildNode(TreeNode parentnode,DataTable dataTable) ：递归函数生成树结点。
GetTreesByUserID(int nUserID) ：由用户ID 得到用户权限集动态生成用户权限树。
（4 ）用户权限检查类CkeckAuthority ：
ChkPermission( int userID ) ：检查用户是否有访问权限。
IsInRole(int roleID) ：检查角色是否存在。
具体实现
在树型结构中，给角色授权时采取简单方式，每次授权时，将其对应的RoleID 、TreeID 及ParentID 存入RolePermissions 表中，见图5 。
===========================================================
设计基础：
用户、角色、权限三大核心表，加上用户角色、角色权限两个映射表(用于给用户表联系上权限表)。这样就可以通过登录的用户来获取权限列表，或判断是否拥有某个权限。
大致用到５张表：用户表（UserInfo）、角色表（RoleInfo）、菜单表（MenuInfo）、用户角色表（UserRole）、角色菜单表（RoleMenu）。
各表的大体表结构如下：
１、用户表（UserInfo）：Id、UserName、UserPwd
２、角色表（RoleInfo）：Id、RoleName
３、菜单表（MenuInfo）：Id、MenuName
４、用户角色表（UserRole）：Id、UserId、RoleId
５、角色菜单表（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 ur.UserId = u.Id and u.UserName = ‘Arthur’
任何权限的需求，都是为广义的用户分配角色，角色拥有广义的权限。角色是最重要的中枢，隐藏做幕后黑手，从不出现在业务代码里，用行话说就是解除了用户和权限的直接耦合。
角色把用户抽象化了，几百个用户变成成几个角色，用户->角色->权限写成通用判断权限的方法：currUser.IsHave(xx权限)。核心就是一个sql联表查询语句，查询条件为用户id。
例如：
部门权限：部门也是一种用户，建立 部门表、部门角色表。通用权限方法里加上 当前部门->部门所属角色->权限
职位权限：职位也是一种用户，建立职位表、职位角色表，同上
菜单：也是一种权限，建立 菜单表、角色菜单表，就把菜单纳入了权限管理。通用权限方法里加上 角色列表->权限、菜单
使用Microsoft SQL Server应用代码构建如下：
1、用户信息表：
create table employee
(
userid varchar(50) not null, --用户ID
username varchar(100), --用户名
userpassword varchar(100), --密码
…
…
…
…
)
alter table employee --主键
add constraint pk_employee_userid primary key (userid)
2、角色表：
create table role
(
roleid varchar(50) not null, --角色Id
rolename varchar(100), --角色名称
)
alter table tole --主键
add constraint pk_role_roleid primary key (roleid)
3、权限菜单表
create table popedom
(
popedomid int identity(1,1) not null, --权限Id
popedomname varchar(100), --权限名称
popedomfatherid int, --权限父ID
popedomurl varchar(100) --树的连接路径
…
…
）
er table popedom --主键
add constraint PK_popedom primary key (popedomid)
添加数据如
insert into popedom values(‘我的办公桌’,0,’’)
insert into popedom values(‘电子邮箱’,1,’…/mail/EmaiolManage.aspx’)
(添加数据的原则是一级接点的popedomfatherid 为0，如果是(我的办公桌)下面的接点，它们的popedomfatherid为(我的办公桌)的主键)
4、用户与角色关系表
create table user_role
(
connectionid int identity(1,1) not null, --关系ID
userid varchar(50) not null, --管理员表ID
roleid varchar(50) not null --角色Id
)
alter table user_role --主键
add constraint PK_admin_role primary key(connectionid)
5、角色与权限关系表
create table role_popedom --角色与权限表
(
connectionid int identity(1,1), --关系Id
roleid varchar(50) not null, --角色ID
popedomid int not null, --权限Id
popedom int --权限 （1为可用，2为不可用）
)
alter table role_popedom --主键
add constraint PK_role_popedom primary key(connectionid) --主键
6.五表之间的关联
================================
每个菜单我给其定义一个url，通过该url访问对应的菜单，将这个url和角色进行绑定，然后角色和用户进行绑定，属于同一角色下的用户也就拥有该角色下绑定的url
数据表
这里有五张表，也就是上面说的菜单表、角色表、用户表、角色菜单关联表和角色用户管理表
下面写的是关键字段，其它字段省略
菜单表-menu
| 字段 | 说明 |
|---|---|
| menu_id | 菜单记录id |
| menu_name | 菜单名称，也就是我们在系统里看到的菜单选项的名称 |
| menu_url | 菜单的访问url,通过该url才能访问菜单的内容 |
| parent_id | 父菜单id,如果是子菜单，则记录其父菜单id,否则，-1记录呗 |
| order | 菜单级别,对菜单分级进行记录，1级菜单，2级菜单。。。 |
角色表-role
| 字段 | 说明 |
|---|---|
| role_id | 角色id |
| role_name | 角色名称 |
用户表-user
| 字段 | 说明 |
|---|---|
| user_id | 用户id |
| user_name | 用户名 |
角色菜单表 role_menu
| 字段 | 说明 |
|---|---|
| role_menu_id | 角色菜单关联记录id |
| role_id | 角色id |
| menu_id | 菜单id |
角色用户表 role_user
| 字段 | 说明 |
|---|---|
| role_user_id | 角色用户id |
| role_id | 角色id |
| user_id | 用户id |
通过上面五张表的设计及其关联，可以在用户登录的时候，根据该用户所属的角色,在role_menu表里找出所有的菜单的实体集合，然后放在session里面，登录跳转后从Session里读出菜单集合，这样就可以实现动态菜单，每个角色下的菜单操作权限也就实现了。
具体的每个菜单下的小权限,比如按钮、下拉框、搜索框之类的权限操作，可以读取菜单的url的session后通过Js进行这些操作表单的隐藏或者显示，综上，动态菜单和菜单下内容的具体小权限操作都能实现
标签：菜单,角色,--,用户,id,权限,Extjs 来源： https://www.cnblogs.com/lhj1168/p/13903006.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。