权限设计方案范本
- 格式:doc
- 大小:429.00 KB
- 文档页数:16
权限设计文档范文一、背景与目标随着互联网的快速发展,系统的权限管理变得非常重要。
一个完善的权限管理系统可以保障系统的安全性和稳定性,控制用户的访问权限,防止未授权的用户对系统进行恶意操作。
本文所述的权限设计文档旨在为一个Web应用程序的权限管理系统设计提供指导。
二、设计原则1.权限粒度细权限应该尽量细化,以便更好地控制用户的操作范围。
管理员可以根据用户的角色和职责为每个用户分配特定的权限,确保其只能访问其需要的功能和数据。
2.权限层级清晰权限应该有明确的层级结构,以便管理员能够直观地理解和管理权限。
例如,可以将权限分为系统级权限、模块级权限和功能级权限等。
3.权限可扩展系统的权限设计应该具备可扩展性,能够适应未来的业务需求变化。
权限的添加和修改应该简单,并能够方便地与系统的其他模块集成。
4.权限控制灵活权限管理系统应该具备灵活性,能够根据实际情况进行权限控制。
管理员应该能够根据不同的场景和需求,对用户的权限进行动态调整。
三、权限设计方法1.角色与权限根据系统的实际需求,将用户分为不同的角色,每个角色对应一组权限。
角色的权限由系统管理员进行定义和分配。
通过为用户分配角色,可以实现权限的细化管理。
2.权限继承为了避免权限管理过于繁琐,可以使用权限继承的方式,使部分角色拥有其他角色的权限。
例如,一个管理员角色可以继承普通用户的权限,以便管理员能够查看和管理所有用户的信息。
3.权限组将相似的权限组合成权限组,在分配权限时可以直接分配权限组,而不需要逐个分配权限。
这样可以简化权限管理的工作量,并提高系统的安全性。
4.权限审批与审计对于敏感的权限操作,应该增加权限审批和审计机制,确保权限的合理使用和追溯。
例如,删除用户的权限操作应该经过管理员的审批,并记录下操作的时间和操作人。
四、权限管理流程1.角色管理系统管理员可以通过后台管理界面对角色进行创建、修改和删除。
在创建角色时,需要定义角色的名称和描述,以及该角色拥有的权限。
数据库权限设计方案概述数据库是一个关键的信息系统组成部分,对于保护数据的机密性、完整性和可用性至关重要。
在现代应用中,数据库的权限控制是确保只有授权用户可以访问和操作数据的重要方面之一。
本文档旨在提供一个数据库权限设计方案,以确保只有合适的用户能够访问和操作数据库。
目标和原则目标•限制对数据库的非授权访问•分配合适的权限给授权用户•简化权限管理和维护流程原则•最小权限原则:给予用户的权限应尽可能少,只包含其工作所需的最小权限。
这样可以减少意外数据泄露或不当操作的风险。
•隔离原则:将用户分组并给予特定组的权限,从而限制一组用户对其他组用户的访问。
•审计原则:记录和监控用户对数据库的访问和操作,以便及时发现和处理异常行为。
•合理性原则:按照工作职能和数据需求来分配用户的权限,确保权限的合理使用和高效管理。
权限设计数据库角色在权限设计中,可以使用角色来管理和分配权限。
数据库角色是一个逻辑组,可以包含一组权限和用户。
这样用户只需要分配到适当的角色即可获得相应的权限。
常见的数据库角色包括:•超级用户角色:拥有完全的数据库操作权限,包括创建、删除、修改和查询数据库对象、用户和角色等。
•管理员角色:负责管理数据库的日常操作,包括备份和恢复、性能优化等。
•开发者角色:负责开发和维护数据库应用程序,具有对数据库对象和数据进行查询和修改的权限。
•数据分析师角色:负责对数据库中的数据进行分析和报告,具有读取和汇总数据的权限。
根据实际需求,可以创建更多的角色,并根据角色的权限需求分配相应的权限。
权限分配在数据库中,权限可以分为两种类型:对象级权限和系统级权限。
对象级权限对象级权限控制用户对特定数据库对象(如表、视图、存储过程等)的访问和操作权限。
常见的对象级权限包括:•SELECT:允许用户查询数据。
•INSERT:允许用户向表中插入新数据。
•UPDATE:允许用户修改表中的现有数据。
•DELETE:允许用户删除表中的数据。
用户权限管理设计方案用户权限管理是一种重要的信息安全控制手段,能够确保系统中的用户只能访问其所需的数据和功能,防止未授权的操作和数据泄露。
本文将从用户权限的概念、设计原则、权限管理模型以及权限管理方案的实施等方面进行详细讨论。
一、用户权限的概念用户权限是指用户在系统中所具备的操作和访问资源的能力。
它涵盖了用户能够进行的操作类型、访问的资源范围以及操作的具体权限。
通过用户权限,系统可以灵活地控制用户在系统中的行为和操作,确保用户只能进行其所需的操作,从而提高系统的安全性。
二、用户权限管理的设计原则1.最小权限原则:用户应该被授予执行其工作所需的最小权限,以降低潜在的风险。
只有在确实需要的情况下,才应该授予更高级别的权限。
2.分级管理原则:根据用户的角色和职责将用户划分为不同的权限组,每个权限组仅拥有其所需的操作和资源访问权限。
3.统一权限管理原则:用户权限应该经过集中管理,避免出现分散和重复的权限设置,以减少管理成本和提高管理效率。
三、权限管理模型1. 自顶向下授权模型(Top-Down Authorization Model):该模型将权限从高层次向低层次授权,通过角色定义和角色授权的方式,将用户划分为不同的角色,每个角色拥有其所需的权限。
2. 基于角色的访问控制模型(Role-Based Access Control Model):该模型根据用户的角色将权限分配给用户,通过角色的添加、修改和删除来变更用户的权限。
3. 基于目录的访问控制模型(Directory-Based Access Control Model):该模型根据用户所在的组织结构进行权限管理,通过目录结构的设定和权限的继承来实现权限的控制和管理。
四、权限管理方案的实施1.确定用户的角色和职责:根据不同用户的角色和职责,将用户划分为不同的权限组。
同时,定义每个角色所需的操作和资源访问权限。
2.设计权限继承关系:通过权限的继承,将上层角色的权限传递给下层角色,以减少权限设置的重复。
OA系统权限管理设计方案第一篇:OA系统权限管理设计方案OA系统权限管理设计方案l 不同职责的人员,对于系统操作的权限应该是不同的。
优秀的业务系统,这是最基本的功能。
l 可以对“组”进行权限分配。
对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。
所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。
l 权限管理系统应该是可扩展的。
它应该可以加入到任何带有权限管理功能的系统中。
就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。
l 满足业务系统中的功能权限。
传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。
针对OA系统的特点,权限说明:权限在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。
将模块与之组合可以产生此模块下的所有权限。
权限组为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。
比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。
角色权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。
用户组将某一类型的人、具有相同特征人组合一起的集合体。
通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。
用户组的划分,可以按职位、项目或其它来实现。
用户可以属于某一个组或多个组。
通过给某个人赋予权限,有4种方式(参考飞思办公系统)A.通过职位a)在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继承。
用户权限管理设计方案用户认证管理设计方案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.身份验证和授权:在权限管理系统中,身份验证是首要任务。
用户需要提供正确的凭证(例如用户名和密码)来验证自己的身份。
验证通过后,系统会分配相应的访问权限。
在授权过程中,可以基于角色的权限分配模型,将用户分为不同的角色,然后将每个角色与相应的权限关联起来。
2.细粒度的权限控制:权限管理系统应该能够支持对资源的细粒度控制。
也就是说,不同的用户可以被授予不同级别的访问权限,从而限制他们访问资源的能力。
例如,一些用户只能读取数据,而其他用户则可以修改或删除数据。
3.审计和日志:权限管理系统应该能够记录用户的操作并生成相应的日志。
这些日志可以用于监控和追踪用户的行为,以检测潜在的安全问题。
此外,审计也可以用于合规性检查和法律要求。
4.强化安全性:权限管理系统需要采取一系列措施来保证数据的安全性。
例如,对用户密码进行加密存储,采用多因素身份验证,限制访问次数和时间,以及监控和检测潜在的攻击和异常行为。
5.用户自助和管理:权限管理系统应该提供用户自助功能,允许用户自行管理其权限和角色。
这样可以减轻管理员的负担,并提高用户的满意度。
此外,系统还应该提供管理功能,允许管理员更改和更新权限设置。
6.扩展性和灵活性:权限管理系统应该具有良好的扩展性和灵活性,以适应不断变化的需求。
它应该能够支持不同类型的用户、资源和权限,并且可以轻松地进行更改和扩展。
7.集成和互操作性:权限管理系统应该能够与其他系统进行集成,并支持不同的身份验证和授权机制。
这样可以提高系统的互操作性,并减少重复工作和管理成本。
需要注意的是,权限管理设计需要根据具体的应用场景和需求进行定制。
每个系统的权限管理需求都可能不同,因此设计过程中需要充分理解用户需求,并选择适合的权限管理策略和技术。
权限设置方案1 WEBI-VIEW 组,只对webi进行保存操作对文件夹设置不可访问权限对universe链接设置完全控制权限对universe文件夹设置高级权限,包含所有设置WEBI-VIEW 组进行高级权限设置,赋相应的权限(对整个webi文档进行控制的)对webinteligence 应用程序设置高级权限,赋相应的权限(对具体webi中一些访问细节的控制)添加_V用户,见图1.So,_V用户对报表就可以只保存(在运行环境下)2WEBI-DESIGNER组,可以对webi进行设计对文件夹设置不可访问权限对universe链接设置完全控制权限对universe文件夹设置高级权限,包含所有添加_V用户设置中对WEBI-VIEW 组进行高级权限设置,赋全部的权限(对整个webi文档进行控制的)对webinteligence 应用程序设置高级权限,赋全部的权限(对具体webi中一些访问细节的控制)添加_D用户3 对各个渠道设置组渠道_D对其可访问的文件夹设置完全控制权限,对不可访问的文件夹设置无访问权备注:对everyone组都设置不可访问权限对 WEBI-VIEW组设置不可访问权限对 WEBI-DESIGNER组设置不可访问权限添加_D用户4.管理员,具有所有权限,包括Designer设计权限一.具有访问权限用户1.新建用户 8611_DP_V命名规则:机构代码_角色(2位)_V图1.添加用户2.对文件夹设置无访问权限图2.为文件夹添加用户图3.为文件夹设置无访问权限二.具有设计权限用户,只对webi有操作权限1.新建用户 8611_DP_D命名规则:机构代码_角色(2位)_D同上图2.对文件夹设置无访问权限同上图对其具有访问权限的文件夹赋予完全控制权限3.设置universe文件夹无访问权限(默认用户对所有universe文件夹可见)5.对universe链接设置完全控制权限6.设置应用程序的操作权限对webi应用程序进行操作三.86_ADMIN用户,对webi和designer有操作权限1.新建用户86_ADMIN2.对所有文件夹设置完全控制权限3.对universe链接设置完全控制权限4.设置universe文件夹(所有的文件夹)完全控制权限5.设置应用程序的操作权限对webi应用程序的操作入上所述对designer应用程序进行操作6.新建组BJ添加用户在designer中对机构进行控制在designer中设置访问权限命名规则:BJ_universe名添加组对组做机构限制这样,隶属北京分公司下面的用户在webi中就只能看到北京分公司的数据了模型 DESIGNER一般式书库仓库性的但是根据需求有可能需要客户跨越几个模块去去查询这个时候就需要生产构架型的这个时候可以可以用2种方式一种是创建别名如下这个时候可以设置别名和上下文来解决环路的问题可以手动创建别名,也可以让 Designer 自动检测将可能解决联接路径环路的别名。
权限管理详细设计(*部分可选)概述授权机制完善严密,为不同的用户或用户组赋予相应的角色,为不同的角色赋予相应的功能系统功能1、用户管理2、用户组管理3、用户组角色管理4、临时权限管理(用户功能管理)*5、角色管理6、角色功能管理7、功能管理*相关事项以下首先介绍基本概念1.用户:一个外部对象或实体2.用户组:一个用户只能属于一个用户组,例如,王刚属于财务部,那么他的用户组就是财务部组,李明属于生产部,那么他的用户组就是生产部组。
相应的,每个组有不同的权限,只要用户属于这个组就自动拥有了这些组权限。
3.角色:一个用户组可以有多种角色,作用是赋予用户组可以操作系统的权限。
4.功能:一个完整且独立不可再分的业务流程或操作5.密级 *:密级是针对具体的一个用户而言。
密级有四种分类,从低到高分别是无密,保密,绝密,机密。
例如,王刚的密级为绝密,则他可以操作无密,保密和绝密属性的内容,但不可以操作机密属性的内容。
6.临时权限:当用户有时权限不够,比如王刚要操作机密属性的内容时,他可以向系统申请临时权限,待赋权人批准后,他方可执行有限制的操作。
需要注意的是,当财务部的王刚需要查看生产部的低密级文档时,虽然他的密级达到要求,但由于王刚所在的组没有查看生产部文档的权限,则王刚也需向生产部的赋权人申请临时权限。
详细需求:1用户管理用户设置:查询、添加、修改、删除用户记录信息。
用户实际拥有的权限为:用户所在用户组的权限 + 临时权限。
2用户组管理用户组设置:按实际需要设定用户分组,执行用户组的查询、添加、修改、删除操作。
3用户组角色管理实现用户组和角色的关联。
一个用户组可以拥有多个角色,一个角色可以属于多个用户组。
用户组角色设置:查询、添加、修改、删除用户组角色关联记录信息用户组实际拥有的权限为:用户组的权限。
4临时权限管理(用户功能管理)实现用户和功能的临时关联。
用户功能设置:查询、添加、修改、删除用户功能关联记录信息用户实际拥有的权限为:用户所在用户组的权限 + 临时权限。
权限配置计划方案
权限配置计划方案是确保系统或应用程序的安全性和完整性的一种方法。
以下是一个简单的权限配置计划方案,供您参考:
1. 确定权限需求:首先,需要明确系统或应用程序需要哪些权限,例如读、写、执行等。
这可以通过与相关利益相关者(如管理员、用户等)进行沟通来确定。
2. 角色和用户管理:根据系统或应用程序的需求,定义不同的角色和用户,并为每个角色和用户分配相应的权限。
这可以确保不同的人员只能访问其所需的数据和功能。
3. 最小权限原则:遵循最小权限原则,为每个角色和用户分配所需的最小权限。
这有助于减少潜在的安全风险,并确保数据和系统的完整性。
4. 权限审查:定期进行权限审查,以确保权限的分配符合组织的安全政策和最佳实践。
审查可以包括检查权限分配是否正确、是否需要更新或撤销某些权限等。
5. 权限变更管理:建立权限变更管理流程,以确保在发生权限变更时能够及时通知相关人员并进行必要的审批。
这可以确保权限的变更符合组织的安全要求,并减少潜在的安全风险。
6. 培训和意识:对员工进行培训和意识教育,使其了解权限管理的重要性和如何正确使用其分配的权限。
这有助于减少误操作和潜在的安全风险。
7. 监控和日志记录:实施监控和日志记录机制,以监测系统的权限使用情况,并在发生异常时及时发出警报。
这有助于及时发现和解决潜在的安全问题。
通过以上步骤,您可以制定一个有效的权限配置计划方案,确保系统或应用程序的安全性和完整性。
数据权限设计范文在进行数据权限设计时,需要考虑以下几个方面:1.用户角色和职责:首先需要明确系统中的各种用户角色和他们的职责。
不同的角色可能有不同的数据访问需求和权限。
例如,系统中可能存在管理员、普通用户、审核员等角色,他们在系统中的操作权限和数据访问权限可能存在差异。
2.数据分类和敏感级别:根据业务需求,对系统中的数据进行分类和划分敏感级别。
例如,将数据分为公开数据、内部数据、机密数据等等。
不同级别的数据应该有不同的权限管理策略。
3.权限分级和细化:在数据权限设计中,可以考虑将权限分为读权限和写权限,读权限可以进一步细化为查看、导出、打印等操作。
写权限可以细化为新增、修改、删除等操作。
通过将权限细化,可以更加精确地控制用户的数据访问和操作权限。
4.角色与权限的关联:根据用户角色和职责,将不同的权限赋予相应的角色。
可以通过角色配置表或者权限管理界面,将不同的权限与角色进行关联。
这样,在用户管理中只需将用户分配到相应的角色,即可获得相应的权限。
5.数据访问过滤:在实际应用中,可能需要实现用户只能访问自己所属部门或者所负责的数据等需求。
这时可以通过数据过滤的方式,根据用户的角色和相关条件,对数据进行过滤,使用户只能看到符合条件的数据。
6.审计和日志记录:数据权限设计中,需要记录用户的操作行为,包括访问数据的时间、操作类型、操作结果等信息。
这样可以方便审计和追溯用户的操作,对于系统中的数据安全事件进行调查和处理。
7.定期评估和更新:随着系统的使用,用户角色和职责可能会发生变化,数据访问需求也可能发生调整。
因此,需要定期对数据权限进行评估和更新,确保系统的数据权限设计与实际需求保持一致。
数据权限设计对于系统的数据安全性和可用性具有重要影响。
合理的数据权限设计可以保护数据的隐私和机密性,防止未经授权的用户进行非法操作和访问。
因此,在系统设计和开发过程中,需要充分考虑数据权限设计,根据不同的角色和职责,对数据进行精确的权限管理,确保系统的安全运行和数据的保护。
网站权限设计方案网站权限设计方案在现代网络社会中,网站权限的设计和管理非常重要,它可以控制网站的信息安全和用户权限。
下面是一个网站权限设计方案的示例:1. 用户角色分类:将用户分为不同的角色,如管理员、普通用户、游客等。
不同角色拥有不同的权限,管理员可以操作网站的所有功能,普通用户可以浏览和使用网站的一部分功能,游客只能查看部分公开信息。
2. 权限分配:根据用户角色,为每个角色分配不同的权限。
管理员拥有最高权限,可以添加、删除和修改用户的角色和权限。
普通用户可以编辑个人资料和发布评论等功能。
3. 数据访问控制:对不同角色的用户设置不同的数据访问权限。
管理员可以查看和修改所有数据,普通用户只能访问自己的数据,游客只能查看公开的数据。
确保用户只能访问和操作其具备权限的数据。
4. 密码保护:为每个用户设置独立的用户名和密码,并要求其定期更换密码。
密码需要符合一定的复杂度要求,如包含大小写字母、数字和特殊字符等。
为了增加安全性,可以使用加密算法对用户密码进行处理。
5. 登录授权机制:用户在登录网站时需要提供正确的用户名和密码,系统会验证用户的身份后才能进入网站。
如果用户连续多次输入错误密码,系统应该自动锁定该用户的账号,以防止暴力破解。
6. 日志记录与审计:对用户的所有操作和访问记录进行日志记录,并保留一段时间用于审计。
这可以帮助发现潜在的安全问题和不当行为,追踪用户的操作轨迹。
7. 安全漏洞修复:定期检查和修复网站的安全漏洞,及时更新系统和应用程序的补丁。
保持系统和软件处于最新的安全状态,以防止黑客利用已知漏洞攻击网站。
8. 加密传输:采用SSL证书对网站进行加密传输,以保护用户数据在传输过程中的安全性。
确保用户的登录信息和敏感数据不会被截获和篡改。
9. 跨站点脚本(XSS)和SQL注入预防:对用户输入的数据进行过滤和转义,避免用户输入恶意代码或SQL注入攻击。
使用安全的编程技术和框架,防止这些常见的安全漏洞。
业务系统权限分配设计方案(草)为结合推行综合柜员制实际,严格按照三级审批流程,特制定此方案。
住房公积金业务系统权限根据岗位属性大致设计为7类权限,其中所有权限均有基础查询权限,分别是管理部5类,中心2类。
缴存业务二级审核,贷款业务三级审核,提取业务二级审核。
业务初审岗(综合柜员):负责中心三大业务的初审办理工作。
缴存类:负责分配登记缴存单位网上大厅业务账号;负责审核各缴存单位经办人通过网厅上报的各类业务(汇缴清册、个人和单位信息修改),审核完成即处理完毕,无复审环节,审核未通过,则由单位经办人重新上报。
贷款类:负责贷款资料初审录入工作,包括电子档案的拍摄增删功能,成功录入后推送至复核岗,对未复审或复审未通过的贷款资料拥有修改权限。
提取类:分为一般性提取和其他提取,一般性提取:指退休,解除劳动关系、死亡等销户提取,按月划还贷和提前还清提取;其他提取:指转移调动、购房,支付房租、大病、子女上学等部分支取业务。
一般性提取业务由柜员直接受理到办结(结算),其他提取业务由柜员完成初审录入工作完成后,推送至结算中心完成复审结算工作。
业务复审岗(管理部):仅负责三大业务中贷款复审工作,原则上业务复审岗由各管理部班子成员担任,主要核查信息的真实性,准确性。
若审核不通过,则退回柜员进行修改后,重新上报或终止办理;若审核通过,则进入终审环节(银行签约、放贷)。
业务结算岗:主要负责其他提取业务和贷款业务的审核结算,根据岗位性质分为中心结算和银行结算。
结算中心负责其他提取业务检查审核,审核确认后完成实时结算,若审核不通过或结算失败,返回初审岗核查信息,修改后重新推送上报;银行结算负责贷款业务的签约、放贷结算,对复审推送的贷款信息进行三级审批,完成签约,打印借款借据,实时结算发放贷款。
此外现金提前部分或全部偿还住房公积金贷款,由银行直接完成相应结算操作。
初审、复审、结算三个阶段为逐级递进关系,如若一个环节失败或审核不通过,则退回上一环节再次审核,而资料修改完善只能由业务初审人员完成。
权限设计方案
权限管理设计一
•博客分类:
•设计
设计模式数据结构
应用程序权限设计
我们在开发系统的时候,经常会遇到系统需要权限控制,而权限的控制程度不同有不同的设计方案。
1. 基于角色的权限设计
这种方案是最常见也是比较简单的方案,不过一般有这种设计已经够了,因此微软就设计出这种方案的通用做法,这种方案对于每一个操作不做控制,只是在程序中根据角色对是否具有操作的权限进行控制;这里我们就不做详述
2. 基于操作的权限设计
这种模式下每一个操作都在数据库中有记录,用户是否拥有该操作的权限也在数据库中有记录,结构如下:
可是如果直接使用上面的设计,会导致数据库中的UserAction 这张表数据量非常大,因此我们需要进一步设计提高效率,请看方案3
3. 基于角色和操作的权限设计
如上图所示,我们在添加了Role,和RoleAction表,这样子就能够减少UserAction中的记录,而且使设计更灵活一点。
可是这种方案在用户需求的考验之下也可能显得不够灵活够用,例如当用户要求临时给某位普通员工某操作权限时,我们就需要新增加一种新的用户角色,可是这种用户角色是不必要的,因为它只是一种临时的角色,如果添加一种角色还需要在
收回此普通员工权限时删除此角色,我们需要设计一种更合适的结构来满足用户对权限设置的要求。
4. 2,3组合的权限设计,其结构如下:
我们能够看到在上图中添加了UserAction表,使用此表来添加特殊用户的权限,改表中有一个字段HasPermission能够决定用户是否有某种操作的权限,改表中记录的权限的优先级要高于UserRole中记录的用户权限。
这样在应用程序中我们就需要经过UserRole和UserAction两张表中的记录判断权限。
到这儿呢并不算完,有可能用户还会给出这样的需求:对于某一种action所操作的对象某一些记录会有权限,而对于其它的记录没有权限,比如说一个内容管理系统,对于某一些频道某个用户有修改的权限,而对于另外一些频道没有修改的权限,这时候我们需要设计更复杂的权限机制。
5. 对于同一种实体(资源)用户能够对一部分记录有权限,而对于另外一些记录没有权限的权限设计:
对于这样的需求我们就需要对每一种不同的资源创立一张权限表,在上图中对Content和Channel两种资源分别创立了
UserActionContent和UserActionChannel表用来定义用户对某条记录是否有权限;这种设计是能够满足用户需求的可是不是很经济,UserActionChannel和UserActionContent中的记录会很多,而在实际的应用中并非需要记录所有的记录的权限信息,有时候可能只是一种规则,比如说对于根Channel什么级别的人有权限;这时候呢我们就能够定义些规则来判断用户权限,
下面就是这种设计。
6. 涉及资源,权限和规则的权限设计。