钓鱼网站查询系统,艺客网站首页,福永响应式网站多少钱,海淀网站建设联系方式权限设计#xff08;初稿#xff09; 1. 前言#xff1a; 权限管理往往是一个极其复杂的问题#xff0c;但也可简单表述为这样的逻辑表达式#xff1a;判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用#xff0c;需要根据项目的实… 权限设计初稿 1. 前言 权限管理往往是一个极其复杂的问题但也可简单表述为这样的逻辑表达式判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用需要根据项目的实际情况和具体架构在维护性、灵活性、完整性等N多个方案之间比较权衡选择符合的方案。 2. 目标 直观因为系统最终会由最终用户来维护权限分配的直观和容易理解显得比较重要简单包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。 3. 现状 对于在企业环境中的访问控制方法一般有三种 1.自主型访问控制方法目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。 2.强制型访问控制方法用于多层次安全级别的军事应用。 3.基于角色的访问控制方法RBAC是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是1.减小授权管理的复杂性降低管理开销。2.灵活地支持企业的安全策略并对企业的变化有很大的伸缩性。 4. 名词 粗粒度表示类别级即仅考虑对象的类别(the type of object)不考虑对象的某个特定实例。比如用户管理中创建、删除对所有的用户都一视同仁并不区分操作的具体对象实例。 细粒度表示实例级即需要考虑具体对象的实例(the instance of object)当然细粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如合同管理中列表、删除需要区分该合同实例是否为当前用户所创建。 5. 原则 权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义它们也能被理解为是“业务逻辑”的一部分。比如要求“合同资源只能被它的创建者删除与创建者同组的用户可以修改所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题在整个权限系统的架构设计之中不予过多考虑。当然权限系统的架构也必须要能支持这样的控制判断。或者说系统提供足够多但不是完全的控制能力。即设计原则归结为“系统只提供粗粒度的权限细粒度的权限被认为是业务逻辑的职责”。 权限公式WhoWhat(Which)How 的问题在这里我们实现What和部分Which的权限问题(粗粒度和细粒度相合到一定的程度)其他的权限问题留给业务逻辑解决 6. 概念 Who权限的拥用者或主体Principal(负责人)、User、Group、Role、Actor等等 What权限针对的对象或资源Resource、Class。 How具体的权限Privilege, 正向授权与负向授权。 Role是角色拥有一定数量的权限。 Operator操作。表明对What的How 操作。 7. 解释 User与 Role 相关用户仅仅是纯粹的用户权限是被分离出去了的。User是不能与 Privilege 直接相关的User 要拥有对某种资源的权限必须通过Role去关联。解决 Who 的问题。 Resource就是系统的资源比如部门新闻文档等各种可以被提供给用户访问的对象。 Privilege是Resource Related的权限。就是指这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限叫做部门新闻发布权限。这就表明该Privilege是一个发布权限而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。Privilege 如删除 是一个抽象的名词当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。拿新闻发布来说发布是一种权限但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时才会产生真正的 Privilege。这就是 Privilege Instance。 Role是粗粒度和细粒度(业务逻辑)的接口一个基于粗粒度控制的权限框架软件对外的接口应该是Role具体业务实现可以直接继承或拓展丰富Role的内容Role不是如同User或Group的具体实体它是接口概念抽象的通称。 Operator的定义包括了Resource Type和Method概念。即What和How的概念。之所以将What和How绑定在一起作为一个Operator概念而不是分开建模再建立关联这是因为很多的How对于某What才有意义。比如发布操作对新闻对象才有意义对用户对象则没有意义。 8. 思想 权限系统的核心由以下三部分构成1.创造权限2.分配权限3.使用权限然后系统各部分的主要参与者对照如下1.创造权限 - Creator创造2.分配权限 - Administrator 分配3.使用权限 - User 1. Creator 创造 Privilege Creator 在设计和实现系统时会划分一个子系统或称为模块应该有哪些权限。这里完成的是 Privilege 与 Resource 的对象声明并没有真正将 Privilege 与具体Resource 实例联系在一起形成Operator。 2. Administrator 指定 Privilege 与 Resource Instance 的关联。在这一步 权限真正与资源实例联系到了一起 产生了OperatorPrivilege Instance。Administrator利用Operator这个基本元素来创造他理想中的权限模型。如创建角色创建用户组给用户组分配用户将用户组与角色关联等等...这些操作都是由 Administrator 来完成的。 3. User 使用 Administrator 分配给的权限去使用各个子系统。Administrator 是用户在他的心目中有一个比较适合他管理和维护的权限模型。于是程序员只要回答一个问题就是什么权限可以访问什么资源也就是前面说的 Operator。程序员提供 Operator 就意味着给系统穿上了盔甲。Administrator 就可以按照他的意愿来建立他所希望的权限框架可以自行增加删除管理Resource和Privilege之间关系。可以自行设定用户User和角色Role的对应关系。(如果将 Creator看作是 Basic 的发明者 Administrator 就是 Basic 的使用者他可以做一些脚本式的编程) Operator是这个系统中最关键的部分它是一个纽带一个系在ProgrammerAdministratorUser之间的纽带。 但凡涉及多用户不同权限的网络或者单机程序都会有权限管理的问题比较突出的是MIS系统。 下面我要说的是MIS系统权限管理的数据库设计及实现当然这些思路也可以推广开来应用比如说在BBS中用来管理不同级别的用户权限。 权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。 这三个部分相互依存密不可分要实现完善的权限管理体系必须考虑到每一个环节可行性与复杂程度甚至执行效率。 我们将权限分类首先是针对数据存取的权限通常有录入、浏览、修改、删除四种其次是功能它可以包括例如统计等所有非直接数据存取操作另外我们还可能对一些关键数据表某些字段的存取进行限制。除此我想不出还有另外种类的权限类别。 完善的权限设计应该具有充分的可扩展性也就是说系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化要达到这个目的首先是数据库设计合理其次是应用程序接口规范。 我们先讨论数据库设计。通常我们使用关系数据库这里不讨论基于Lotus产品的权限管理。 权限表及相关内容大体可以用六个表来描述如下 1 角色即用户组表包括三个字段ID角色名对该角色的描述 2 用户表包括三个或以上字段ID用户名对该用户的描述其它如地址、电话等信息 3 角色-用户对应表该表记录用户与角色之间的对应关系一个用户可以隶属于多个角色一个角色组也可拥有多个用户。包括三个字段ID角色ID用户ID 4 限制内容列表该表记录所有需要加以权限区分限制的数据表、功能和字段等内容及其描述包括三个字段ID名称描述 5 权限列表该表记录所有要加以控制的权限如录入、修改、删除、执行等也包括三个字段ID名称描述 6 权限-角色-用户对应表一般情况下我们对角色/用户所拥有的权限做如下规定角色拥有明令允许的权限其它一律禁止用户继承所属角色的全部权限在此范围内的权限除明令禁止外全部允许范围外权限除明令允许外全部禁止。该表的设计是权限管理的重点设计的思路也很多可以说各有千秋不能生搬硬套说某种方法好。对此我的看法是就个人情况找自己觉得合适能解决问题的用。 先说第一种也是最容易理解的方法设计五个字段ID限制内容ID权限ID角色/用户类型布尔型字段用来描述一条记录记录的是角色权限还是用户权限角色/用户ID权限类型布尔型字段用来描述一条记录表示允许还是禁止 好了有这六个表根据表六我们就可以知道某个角色/用户到底拥有/禁止某种权限。 或者说这么设计已经足够了我们完全实现了所需要的功能可以对角色和用户分别进行权限定制也具有相当的可扩展性比如说增加了新功能我们只需要添加一条或者几条记录就可以同时应用程序接口也无须改动具有相当的可行性。但是在程序实现的过程中我们发现使用这种方法并不是十分科学例如浏览某个用户所拥有的权限时需要对数据库进行多次甚至是递归查询极不方便。于是我们需要想其它的办法。使用过Unix系统的人们都知道Unix文件系统将对文件的操作权限分为三种读、写和执行分别用1、2、4三个代码标识对用户同时具有读写权限的文件被记录为3即12。我们也可以用类似的办法来解决这个问题。初步的想法是修改权限列表加入一个字段标识码例如我们可以将录入权限标识为1浏览权限标识为2修改权限标识为4删除权限标识为8执行权限标识为16这样我们通过权限累加的办法就可以轻易的将原本要分为几条记录描述的权限放在一起了例如假定某用户ID为1库存表对应的限制内容ID为2同时规定角色类型为0、用户类型为1我们就可以将该用户具有录入、浏览、修改、删除库存表的权限描述为2,15,1,1。 确实很简单不是吗甚至还有更过激的办法将限制内容列表也加上一列定义好标识码这样我们甚至可以用简单的一条记录描述某个用户具有的对全部内容所具有的全部权限了。当然这样做的前提是限制内容数量比较小不然呵呵2的n次方递增起来可是数量惊人不容易解析的。 从表面上看上述方法足以达到实现功能、简化数据库设计及实现的复杂度这个目的但这样做有个弊端我们所涉及的权限列表不是相互独立而是互相依赖的比如说修改权限其实是包含浏览权限的例如我们可能只是简单的设置用户对库存表存取的权限值为录入修改删除14813),但事实上该用户具有(124815的权限也就是说在这种方案中1315。于是当我们调用API询问某用户是否具有浏览权限时就必须判断该用户是否具有对该数据表的修改权限因此如果不能在程序中固化权限之间的包含关系就不能利用应用程序接口简单的做出判断。但这与我们的目的“充分的可扩展性”矛盾。 这个问题如何解决我想到了另外一种设置标识码的方法那就是利用素数。我们不妨将录入、浏览、修改、删除、执行的基本标志码定为2,3,5,7,11当遇到权限互相包含的时候我们将它的标识码设定为两个或多个基本标志码的乘积例如可以将“修改”功能的标志码定为3*515然后将所有的权限相乘就得到了我们需要的最终权限标识值。这样我们在询问用户是否具有某项权限的时候只需要将最终的值分解成质因子例如我们可以定义一个用户具有录入修改删除库存表的权限为 2*15*72*3*5*7即表示该用户具有了对库存表录入浏览修改删除权限。 当然对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂否则光是解析权限代码就要机器忽悠半宿 通用权限管理设计篇 http://sxiaomais.blog.163.com/blog/static/31741203200811102630406/ 一引言 因为做过的一些系统的权限管理的功能虽然在逐步完善但总有些不尽人意的地方总想抽个时间来更好的思考一下权限系统的设计。 权限系统一直以来是我们应用系统不可缺少的一个部分若每个应用系统都重新对系统的权限进行设计以满足不同系统用户的需求将会浪费我们不少宝贵时间所以花时间来设计一个相对通用的权限系统是很有意义的。 二设计目标 设计一个灵活、通用、方便的权限管理系统。 在这个系统中我们需要对系统的所有资源进行权限控制那么系统中的资源包括哪些呢我们可以把这些资源简单概括为静态资源功能操作、数据列和动态资源数据也分别称为对象资源和数据资源后者是我们在系统设计与实现中的叫法。 系统的目标就是对应用系统的所有对象资源和数据资源进行权限控制比如应用系统的功能菜单、各个界面的按钮、数据显示的列以及各种行级数据进行权限的操控。 三相关对象及其关系 大概理清了一下权限系统的相关概念如下所示 1. 权限 系统的所有权限信息。权限具有上下级关系是一个树状的结构。下面来看一个例子 系统管理 用户管理 查看用户 新增用户 修改用户 删除用户 对于上面的每个权限又存在两种情况一个是只是可访问另一种是可授权例如对于“查看用户”这个权限如果用户只被授予“可访问”那么他就不能将他所具有的这个权限分配给其他人。 2. 用户 应用系统的具体操作者用户可以自己拥有权限信息可以归属于0n个角色可属于0n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。 3. 角色 为了对许多拥有相似权限的用户进行分类管理定义了角色的概念例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系可以形成树状视图父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。 4. 组 为了更好地管理用户对用户进行分组归类简称为用户分组。组也具有上下级关系可以形成树状视图。在实际情况中我们知道组也可以具有自己的角色信息、权限信息。这让我想到我们的QQ用户群一个群可以有多个用户一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有自己的角色信息例如普通群、高级群等。 针对上面提出的四种类型的对象让我们通过图来看看他们之间的关系。 有上图中可以看出这四者的关系很复杂而实际的情况比这个图还要复杂权限、角色、组都具有上下级关系权限管理是应用系统中比较棘手的问题要设计一个通用的权限管理系统工作量也着实不小。 当然对于有些项目权限问题并不是那么复杂。有的只需要牵涉到权限和用户两种类型的对象只需要给用户分配权限即可。 在另一些情况中引入了角色对象例如基于角色的权限系统 只需要给角色分配权限用户都隶属于角色不需要单独为用户分配角色信息。 通用权限管理设计篇二——数据库设计 国庆前整的通用权限设计的数据库初步设计部分现在贴上来。 理清了对象关系之后让我们接着来进行数据库的设计。在数据库建模时对于N对N的 关系一般需要加入一个关联表来表示关联的两者的关系。初步估计一下本系统至少需要十张表分别为权限表、用户表、角色表、组表、用户权限关联表、用 户角色关联表、角色权限关联表、组权限关联表、组角色关联表、用户属组关联表。当然还可能引出一些相关的表。下面让我们在PowerDesigner中画出各表吧。 各表及其关系如下 1. 用户表 用户表TUser 字段名称 字段 类型 备注 记录标识 tu_id bigint pk, not null 所属组织 to_id bigint fk, not null 登录帐号 login_name varchar(64) not null 用户密码 password varchar(64) not null 用户姓名 vsername varchar(64) not null 手机号 mobile varchar(20) 电子邮箱 email varchar(64) 创建时间 gen_time datetime not null 登录时间 login_time datetime 上次登录时间 last_login_time datetime 登录次数 count bigint not null 2. 角色表 角色表TRole 字段名称 字段 类型 备注 角色ID tr_id bigint pk, not null 父级角色ID parent_tr_id bigint not null 角色名称 role_name varchar(64) not null 创建时间 gen_time datetime not null 角色描述 description varchar(200) 3. 权限表 权限表TRight 字段名称 字段 类型 备注 权限ID tr_id bigint pk, not null 父权限 parent_tr_id bigint not null 权限名称 right_name varchar(64) not null 权限描述 description varchar(200) 4. 组表 组表TGroup 字段名称 字段 类型 备注 组ID tg_id bigint pk, not null 组名称 group_name varchar(64) not null 父组 parent_tg_id bigint not null 创建时间 gen_time datetime not null 组描述 description varchar(200) 5. 角色权限表 角色权限表TRoleRightRelation 字段名称 字段 类型 备注 记录标识 trr_id bigint pk, not null 角色 Role_id bigint fk, not null 权限 right_id bigint fk, not null 权限类型 right_type int not null0:可访问1:可授权 6. 组权限表 组权限表TGroupRightRelation 字段名称 字段 类型 备注 记录标识 tgr_id bigint pk, not null 组 tg_id bigint fk, not null 权限 tr_id bigint fk, not null 权限类型 right_type int not null0:可访问1:可授权 7. 组角色表 组角色表TGroupRoleRelation 字段名称 字段 类型 备注 记录标识 tgr_id bigint pk, not null 组 tg_id bigint fk, not null 角色 tr_id bigint pk, not null 8. 用户权限表 用户权限表TUserRightRelation 字段名称 字段 类型 备注 记录标识 tur_id bigint pk, not null 用户 tu_id bigint fk, not null 权限 tr_id bigint fk, not null 权限类型 right_type int not null0:可访问1:可授权 9. 用户角色表 用户角色表TUserRoleRelation 字段名称 字段 类型 备注 记录标识 tur_id bigint pk, not null 用户 tu_id bigint fk, not null 角色 tr_id bigint fk, not null 10. 用户组表 用户组表TUserGroupRelation 字段名称 字段 类型 备注 记录标识 tug_id bigint pk, not null 用户 tu_id bigint fk, not null 组 tg_id bigint fk, not null 11. 组织表 组织表TOrganization 字段名称 字段 类型 备注 组织id to_id bigint pk, not null 父组 parent_to_id bigint not null 组织名称 org_name varchar(64) not null 创建时间 gen_time datetime not null 组织描述 description varchar(200) 12. 操作日志表 操作日志表TLog 字段名称 字段 类型 备注 日志ID log_id bigint pk, not null 操作类型 op_type int not null 操作内容 content varchar(200) not null 操作人 tu_id bigint fk, not null 操作时间 gen_time datetime not null 通用权限管理系统设计篇三——概要设计说明书 在前两篇文章中不少朋友对我的设计提出了异议认为过于复杂当然在实际的各种系统的权限管理模块中并不像这里设计得那么复杂我以前所做的系统中 由只有用户和权限的有只有用户、权限和角色的还有一个系统用到了用户、权限、角色、组概念这个系统是我在思考以前所做系统的权限管理部分中找到的一 些共性而想到的一个设计方案当然还会有不少设计不到位的地方在设计开发过程中会慢慢改进这个系统权当学习只用各位朋友的好的建议我都会考虑到设计 中感谢各位朋友的支持。 今天抽时间整了一份概念设计出来还有一些地方尚未考虑清楚贴出1.0版希望各位朋友提出宝贵建议。 大家也可以点击此处《通用权限管理概要设计说明书》自行下载这是1.0版本有些地方可能还会进行部分修改有兴趣的朋友请关注我的blog。 1. 引言 1.1 编写目的 本文档对通用权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。 1.2 背景 a、 软件系统的名称通用权限管理系统 b、 任务提出者、开发者谢星星 c、 在J2EE的web系统中需要使用权限管理的系统。 1.3 术语 本系统通用权限管理系统 SSH英文全称是Secure Shell。 1.4 预期读者与阅读建议 预期读者 阅读重点 开发人员 总体设计、接口设计、数据结构设计、界面总体设计、系统出错处理设计 设计人员 总体设计、接口设计、数据结构设计、系统安全设计 1.5 参考资料 《通用权限管理系统需求规格说明书》 《通用权限管理系统数据库设计说明书》 2. 总体设计 2.1 设计目标 权限系统一直以来是我们应用系统不可缺少的一个部分若每个应用系统都重新对系统的权限进行设计以满足不同系统用户的需求将会浪费我们不少宝贵时间所以花时间来设计一个相对通用的权限系统是很有意义的。 本系统的设计目标是对应用系统的所有资源进行权限控制比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。 2.2 运行环境 操作系统Windows系统操作系统和Linux系列操作系统。 2.3 网络结构 通用权限管理系统可采用Java Swing实现可以在桌面应用和Web应用系统中进行调用。如果需要要适应所有开发语言可以将其API发布到WEB Service上。暂时用Java Swing实现。 2.4 总体设计思路和处理流程 在说明总体设计思路前我们先说明本系统的相关概念 1. 权限资源 系统的所有权限信息。权限具有上下级关系是一个树状的结构。下面来看一个例子 系统管理 用户管理 查看用户 新增用户 修改用户 删除用户 对于上面的每个权限又存在两种情况一个是只是可访问另一种是可授权例如对于“查看用户”这个权限如果用户只被授予“可访问”那么他就不能将他所具有的这个权限分配给其他人。 2. 用户 应用系统的具体操作者用户可以自己拥有权限信息可以归属于0n个角色可属于0n个组。他的权限集是自身具有的权限、所属的各角色具有的权限、所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。 3. 角色 为了对许多拥有相似权限的用户进行分类管理定义了角色的概念例如系统管理员、管理员、用户、访客等角色。角色具有上下级关系可以形成树状视图父级角色的权限是自身及它的所有子角色的权限的综合。父级角色的用户、父级角色的组同理可推。 4. 组 为 了更好地管理用户对用户进行分组归类简称为用户分组。组也具有上下级关系可以形成树状视图。在实际情况中我们知道组也可以具有自己的角色信息、 权限信息。这让我想到我们的QQ用户群一个群可以有多个用户一个用户也可以加入多个群。每个群具有自己的权限信息。例如查看群共享。QQ群也可以具有 自己的角色信息例如普通群、高级群等。 针对如上提出的四种对象我们可以整理得出它们之间的关系图如下所示 总体设计思路是将系统分为组权限管理、角色权限管理、用户权限管理、组织管理和操作日志管理五部分。 其中组权限管理包括包含用户、所属角色、组权限资源和组总权限资源四部分某个组的权限信息可用公式表示组权限 所属角色的权限合集 组自身的权限。 角色权限管理包括包含用户、包含组和角色权限三部分某个角色的权限的计算公式为角色权限 角色自身权限。 用户权限管理包括所属角色、所属组、用户权限、用户总权限资源和组织管理五部分。某个用户总的权限信息存在如下计算公式用户权限 所属角色权限合集 所属组权限合集 用户自身权限。 组织管理即对用户所属的组织进行管理组织以树形结构展示组织管理具有组织的增、删、改、查功能。 操作日志管理用于管理本系统的操作日志。 注意因为组和角色都具有上下级关系所以下级的组或角色的权限只能在自己的直属上级的权限中选择下级的组或者角色的总的权限都不能大于直属上级的总权限。 2.5 模块结构设计 本系统的具有的功能模块结构如下图所示 2.6 尚未解决的问题 无。 3. 接口设计暂略 3.1 用户接口暂略 3.2 外部接口暂略 3.3 内部接口暂略 4. 界面总体设计 本节将阐述用户界面的实现在此之前对页面元素做如下约定 序号 页面元素 约定 1 按钮 未选中时[按钮名称] 选中时[按钮名称] 2 单选框 ○ 选项 3 复选框 □ 选项 4 下拉框 [选项,…,] ▽ 5 文本框 |________| 6 TextArea |…………| 7 页签 未选中时选项名称 选中时选项名称 8 未选中链接 链接文字 9 选中链接 链接文字 10 说明信息 说明信息 4.1 组权限管理 4.1.1包含用户 组信息 组1 组11 组12 组… 组2 组21 组22 组… 所选择组组1 [包含用户] [所属角色] [组权限] [总权限] [修改] 用户名 姓名 手机号 最近登录时间 登录次数 阿蜜果 谢星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… 当用户选择“修改”按钮时弹出用户列表操作人可以通过勾选或取消勾选来修改该组所包含的用户。 4.1.2所属角色 组信息 组1 组11 组12 组… 组2 组21 组22 组… 所选择组组1 [包含用户] [所属角色] [组权限] [总权限] [修改] 角色ID 角色名称 角色描述 1 访客 -- 2 初级用户 -- 当用户选择“修改”按钮时弹出角色树形结构操作人可以通过勾选或取消勾选来修改该组所属的角色。 4.1.3组权限 组信息 组1 组11 组12 组… 组2 组21 组22 组… 所选择组组1 [包含用户] [所属角色] [组权限] [总权限] [保存] [取消] 4.1.4总权限 组信息 组1 组11 组12 组… 组2 组21 组22 组… 所选择组组1 [包含用户] [所属角色] [组权限] [总权限] [保存] [取消] 通过对已具有的权限取消勾选或为某权限添加勾选来修改组的权限信息点击“保存”按钮保存修改信息。 4.1.5组管理 在下图中选中组1的时候右键点击可弹出组的操作列表包括添加、删除和修改按钮从而完成在该组下添加子组删除该组以及修改该组的功能。 组信息 组1 组11 组12 组… 组2 组21 组22 组… 所选择组组1 [包含用户] [所属角色] [组权限] [总权限] [修改] 用户名 姓名 手机号 最近登录时间 登录次数 阿蜜果 谢星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… 4.2 角色权限管理 4.2.1包含用户 角色信息 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色… 所选择角色角色1 [包含用户] [包含组] [角色权限] [修改] 用户名 姓名 手机号 最近登录时间 登录次数 阿蜜果 谢星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… 当用户选择“修改”按钮时弹出用户列表操作人可以通过勾选或取消勾选来修改该角色所包含的用户。 4.2.2包含组 角色信息 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色… 所选择角色角色1 [包含用户] [包含组] [角色权限] [修改] 组ID 组名称 组描述 1 xxx1 -- 2 xxx2 -- …… 当用户选择“修改”按钮时弹出用户列表操作人可以通过勾选或取消勾选来修改该角色所包含的组。 4.2.3角色权限 角色信息 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色… 所选择角色角色1 [包含用户] [包含组] [角色权限] [保存] [取消] 通过对已具有的权限取消勾选或为某权限添加勾选来修改角色的权限信息点击“保存”按钮保存修改信息。 4.2.4管理角色 在下图中选中组1的时候右键点击可弹出组的操作列表包括添加、删除和修改按钮从而完成在该组下添加子组删除该组以及修改该组的功能。 角色信息 角色1 角色11 角色12 角色… 角色2 角色21 角色22 角色… 所选择角色角色1 [包含用户] [包含组] [角色权限] [修改] 用户名 姓名 手机号 最近登录时间 登录次数 阿蜜果 谢星星 13666666666 2007-10-8 66 sterning xxx 13555555555 2007-10-8 10 …… 4.3 用户权限管理 4.3.1所属角色 用户权限信息 xx公司 广州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… 所选择用户阿蜜果 [所属角色] [所属组] [用户权限] [总权限] [修改] 角色ID 角色名称 角色描述 1 访客 -- 2 初级用户 -- … 当用户选择“修改”按钮时弹出角色树形结构操作人可以通过勾选或取消勾选来修改该用户所属的角色。 4.3.2所属组 用户信息 xx公司 广州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… 所选择用户阿蜜果 [所属角色] [所属组] [用户权限] [总权限] [修改] 组ID 组名称 组描述 1 组1 -- 2 组2 -- … 当用户选择“修改”按钮时弹出组的树形结构操作人可以通过勾选或取消勾选来修改该用户所属的组。 4.3.3用户权限 用户信息 xx公司 广州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… 所选择用户阿蜜果 [所属角色] [所属组] [用户权限] [总权限] [保存] [取消] 通过对已具有的权限取消勾选或为某权限添加勾选来修改用户的权限信息点击“保存”按钮保存修改信息。 4.3.4总权限 用户信息 xx公司 广州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… 所选择用户阿蜜果 [所属角色] [所属组] [用户权限] [总权限] [保存] [取消] 通过对已具有的权限取消勾选或为某权限添加勾选来修改用户的权限信息点击“保存”按钮保存修改信息。 4.3.5用户管理 当选择了某用户时点击右键弹出菜单列表修改、删除、取消点击修改和删除按钮可以实现用户的删除和修改功能。 选择某个组织例如下表中的“广州分公司”弹出菜单列表添加子组织、删除组织、修改组织、添加用户、取消点击添加用户按钮可以实现用户的添加功能。 用户权限信息 xx公司 广州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… 所选择用户阿蜜果 [所属角色] [所属组] [用户权限] [总权限] [修改] 角色ID 角色名称 角色描述 1 访客 -- 2 初级用户 -- … 4.3.6组织管理 选择某个组织例如下表中的“广州分公司”弹出菜单列表添加子组织、删除组织、修改组织、添加用户、取消点击添加子组织、删除组织、修改组织按钮可以实现组织的添加、删除和修改功能。 用户权限信息 xx公司 广州分公司 阿蜜果 肖xx yy… 北京分公司 zz1 zz2 zz3… 所选择用户阿蜜果 [所属角色] [所属组] [用户权限] [总权限] [修改] 角色ID 角色名称 角色描述 1 访客 -- 2 初级用户 -- … 4.4 操作日志管理 4.4.1查询操作日志 操作名称|________| 操作人|________| 操作时间从 |________| 到 |________| [查询] [重置] [删除] 编号 操作名称 操作内容 操作人 操作时间 1 xx1 -- Amigo 2007-10-8 2 xx2 -- xxyy 2007-10-8 … 输入上图表单中的查询信息后点击“查询”按钮可查询出符合条件的信息。 4.4.2删除操作日志 操作名称|________| 操作人|________| 操作时间从 |________| 到 |________| [查询] [重置] [删除] 编号 操作名称 操作内容 操作人 操作时间 1 xx1 -- Amigo 2007-10-8 2 xx2 -- xxyy 2007-10-8 … 输入上图表单中的查询信息后点击“查询”按钮可查询出符合条件的信息。而后点击“删除”按钮可删除符合查询条件的操作日志。 5. 数据结构设计 数据库设计的模型请参见《通用权限管理系统_数据库模型.pdm》。表的说明请参见《通用权限管理系统数据库设计说明书》。 5.1 设计原则 5.1.1命名的规范 数据库中表、主键、外键、索引的命名都以统一的规则采用大小写敏感的形式各种对象命名长度不要超过30个字符这样便于应用系统适应不同的数据库平台。 5.1.2数据的一致性和完整性 为了保证数据库的一致性和完整性往往通过表间关联的方式来尽可能的降低数据的冗余。表间关联是一种强制性措施建立后对父表Parent Table和子表(Child Table)的插入、更新、删除操作均要占用系统的开销。如果数据冗余低数据的完整性容易得到保证但增加了表间连接查询的操作为了提高系统的响应时间合理的数据冗余也是必要的。使用规则Rule和约束Check来防止系统操作人员误输入造成数据的错误是设计人员的另一种常用手段但是不必要的规则和约束也会占用系统的不必要开销需要注意的是约束对数据的有效性验证要比规则快。所有这些需要在设计阶段应根据系统操作的类型、频度加以均衡考虑。 5.2 数据库环境说明 数据库MySql5.0 设计库建模工具PowerDesigner12.0 5.3 数据库命名规则 表名以T开头外键以FK开头索引以INDEX开头。 5.4 逻辑结构 pdm文件的名称为《通用权限管理系统_数据库模型》。 5.5 物理存储 通过数据库建模工具PowerDesigner12可以将pdm导出为文本文件将数据库脚本放入文本文件中保存。 5.6 数据备份和恢复 数据库需定期备份每天备份一次备份文件格式为backup_yyyyMMdd数据库被破坏时利用最新的备份文件进行恢复。 6. 系统出错处理设计 6.1 出错信息 错误分类 子项及其编码 错误名称 错误代码 备注 数据库错误 连接 连接超时 100001001 连接断开 100001002 数据库本身错误代码 数据库本身错误代码 100002数据库错误代码 TCP连接错误 连接 连接超时 101001001 连接断开 101001002 其它TCP连接错误(socket自身错误代码) 101002 socket错误代码 配置信息错误 未配置输入参数 102001 未配置输出参数 102002 组管理部分自定义错误 103001——103999 角色管理部分自定义错误 104001——104999 用户管理部分自定义错误 105001——105999 操作日志管理 106001——106999 6.2 补救措施 为了当某些故障发生时对系统进行及时的补救提供如下补救措施 a后备技术 定期对数据库信息进行备份每天一次当数据库因某种原因被破坏时以最新的数据库脚本进行恢复。 7. 系统安全设计 7.1 数据传输安全性设计 SSH可以通过将联机的封包加密的技术进行资料的传递; 使用SSH可以把传输的所有数据进行加密即使有人截获到数据也无法得到有用的信息。同时数据经过压缩大大地加快了传输的速度。通过SSH的使用可以确保资料传输比较安全并且传输效率较高。 7.2 应用系统安全性设计 操作人的操作信息需要提供操作记录。对系统的异常信息需进行记录已备以后查看。只有授权用户才能登录系统对于某个操作需要具有相应权限才能进行操作。 7.3 数据存储安全性设计 对于用户的密码等敏感信息采用MD5进行加密。 OA之权限管理 权限管理自己做完了但是很多的研究和总结现在就来总结一下权限管理。 第一、数据库中主要类 主要负责类用户User角色Role、资源module和操作Permission 衍生类用户角色UserRole和对某个资源的某个操作ACL 第二、ACL的具体理解 一条acl授权记录中主要记录了以下信息: 角色、资源和授权 授权作为一个int, 每一位是一个操作的权限. 假设从右向左, 分别代表CRUD 那么, 我们CRUD的代码就应该是0123(也就是移位时要移的位数), 因为我们要进行移位进行认证。 先看授权与取消授权的代码 [java] view plaincopy publicvoidintboolean int; if else } 首先, 一个int temp 1的临时变量, aclState为原始授权状态 tmp的二进制表示是: 00000000 00000000 00000000 00000001 U对应的代码是U, 对应的是2. 将tmp左移2位, temp tmp 2; temp变成:00000000 00000000 00000000 00000100 假设原始授权是aclState00000000 00000000 00000000 00001010 当变量yestrue时为授权将temp与aclState求|运算因为temp现在只有他要授权的位为1求或运算后 aclState00000000 00000000 00000000 00001110这样就授权成功 当变量yesfalse时为取消授权先将temp取反即为11111111 11111111 11111111 11111011 现在只有要取消权限的位为0其余全为1然后与aclState求运算则除了要取消权限的位变0其余的都不变 即aclState00000000 00000000 00000000 00001010 再来看认证 [java] view plaincopy publicintint int; if){ return return } 认证更简单直接将temp变量与aclState求temp为1的位为要验证的权限其余全为0如果aclState的这一位为1则结果不为零即有该权限若aclState这一位为0即没权限则结果为0没有该操作权限 总结权限管理最难理解的就是CRUD中的数据得来至于别的我们可以关系我们还是可以清晰的理解还有一个概念就是集成的概念 a) 针对某个资源的所有操作我们可以设置这些权限对用户来说是“继承”或“不继承” i. 继承意思是这些权限将使用其即用户所拥有的角色的权限而不使用其即用户单独设置的权限 ii. 不继承意思是这些权限将使用其单独设置的权限而不使用其所拥有的角色的权限 转载于:https://www.cnblogs.com/taozi32/p/6129719.html
