权限表的设计

设计表：
Users 用户列表 场：userid,username,userpermission
Roles 角色表 场：roleid,rolename,rolepermission
UserInRole 对应表用户角色 场：userid,roleid
PermissionList 权限列表 字段：permissionid,permissionDescription,permissionGroup

权限设计：许可、禁止和未设置三种状态,Allow,Deny,Not Set

目标：
实现用户权限的定义。
首先定义角色权限，用户与角色间是多对多的关系。用户权限继承自角色权限。

情况一：用户所属的多个角色存在权限冲突时，取最小权限，即某权限角色A许可，角色B禁止。则该权限为禁止。
情况二：用户所属的角色均未对某权限进行设置时，即NotSet状状态，随着权限DENY
案例3：当一个用户属于许可证角色权限，权限可以单独设置的禁令。

功能：
设置用户权限：
默认情况下，，用户权限继承的角色的权限
您可以分别设置用户的权限
扩展权限
权限可以在任何时间被添加到限定，并能够组。

当添加权限，默认角色权限设置状态

时间： 2024-08-01 14:07:35

权限表的设计的相关文章

mysqsl--用户-角色-权限表的设计

设计一个灵活.通用.方便的权限管理系统. 在这个系统中,我们需要对系统的所有资源进行权限控制,那么系统中的资源包括哪些呢?我们可以把这些资源简单概括为静态资源(功能操作.数据列)和动态资源(数据),也分别称为对象资源和数据资源,后者是我们在系统设计与实现中的叫法. 系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制,比如应用系统的功能菜单.各个界面的按钮.数据显示的列以及各种行级数据进行权限的操控. 三．相关对象及其关系 大概理清了一下权限系统的相关概念,如下所示: 1.      

关于权限表的基本设计

对于一个系统,必须严格的控制权限,权限表的设计是基本的. 基本的权限表有五个,即用户表,角色表,权限表,用户角色表,角色权限表. 下面介绍下基本字段 用户表   user user_id user_name password 角色表   role role_id role_name 权限表   permission permission_id permission 用户角色表  user_role id user_id role_id 角色权限表   role_permission id rol

权限表设计之代码解析

在权限表设计中已经说了权限表的结构,在这里我说下代码 user表 </pre><pre name="code" class="html">@Entity @Table(name="user") public class User implements Serializable{ private static final long serialVersionUID = 6177417450707400228L; @Id @G

数据库权限表设计

最近项目的项目很奇怪,一个大项目(系统)里包含了很多小的子系统,而这些子系统中都有权限控制的部分,这件事情挺让我头痛的,记得一年前在沈阳,我曾经有一段时间也因因这个问题而疲于奔命,为什么说疲于奔命呢?由于当时项目进度不允许,导致最终系统权限模块草草了事,每个模块都是由读权限字符串来控制用户ACL,当用户无法访问时,提示权限不够.这么做对用户是很不负责任的,既然让用户看到了操作的方式和界面,为什么又告诉用户没有权限呢?我开始怀疑我们是否应该在底层就封杀用户的访问权限. 现在项目开展起来了,虽然目前

设计用户权限表

3张表 两个多对多,所以最后是5张表. 用户表:用户ID,用户名用户-角色表:ID,用户ID,角色ID角色表:角色ID,角色名角色-权限表:ID角色ID,权限ID权限表:权限ID,权限名

Activiti 工作流表单设计及开发

一.前言 Activiti 5对表单的支持目前还是比较弱的,表现在对表单的开发还需要写Freemark模板,并且它的模板还需要跟class文件一起打包发布.这使得流程的表单设计必须由开发人员来开发处理.因而,开发一套易用性强的流程表单功能就显得很有必要. 二.需求 用户一般都希望能有如Microsoft的Office套件中的InfoPath那样,可以自己进行设计,并且能与工作流程绑在一起进行流转处理.如下所示: 表单中每个字段有固定的数据类型,并由不同的数据控件展示,如日期.数字.单选或多选.下

简洁常用权限系统的设计与实现(一):构造权限菜单树的N(N&gt;=4)种方法

权限系统,Web开发常见标准子系统之一.结合自己的一些思考和实践,从本篇开始权限系统的设计与实现之路. 最近,重构了项目的权限菜单构造过程,向前端返回json格式的权限树. 这一篇,只是大致介绍下这个问题,并给出4种方法的整体思路,后续再分别详细介绍这4种方法,再往后介绍完整的权限系统的设计与实现. 权限表的结构: acl.parent_acl, 最重要的就是这2个字段,有了这2个字段,就可以构造一棵树了. 前端需要的json格式: "data":[{ "acl":

RBAC用户权限管理数据库设计

http://minjiechenjava.iteye.com/blog/1759482 RBAC用户权限管理数据库设计 博客分类: RBAC 权限设计 RBAC RBAC(Role-Based Access Control,基于角色的访问控制),就是用户通过角色与权限进行关联.简单地说,一个用户拥有若干角色,每一个角色拥有若干权限.这样,就构造成"用户-角色-权限"的授权模型.在这种模型中,用户与角色之间,角色与权限之间,一般者是多对多的关系.(如下图) 角色是什么?可以理解为一定数

关于权限的数据库设计

不管是在网站开发还是MIS系统开发中,涉及到多用户的软件系统都会遇到这个问题,如何比较优雅的解决这个问题也一直是大家经常探讨的热门话题,本文试着谈论一下自己的观点,希望和大家共同切磋. 方法一:    用户表:  T_UserInfo     id     name    对象表:  T_Object     id     name    权限表  T_Access     accessid     userid(外键,来自用户表)     objectid(外键,来自对象表)     acce