文档库 最新最全的文档下载
当前位置:文档库 › 系统权限管理方案

系统权限管理方案

系统权限管理方案
系统权限管理方案

权限

在系统中,权限通过模块+动作来产生。(在系统中也就是一个页面的所有操作,比如(浏览、添加、修改、删除等)。将模块与之组合可以产生此模块下的所有权限。

权限组

为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个权限组,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。

角色

权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。

用户组将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。

一、通过给某个人赋予权限,有四种方式:

(一):通过职位

在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继承。

例如前台这个职位,对于考勤查询有权限,则可以通过对前台这个职位设置考勤

查询的浏览权,使他们有使用这个对象的权限,然后再设置个考勤查询权(当然也可以不设置,默认能进此模块的就能查询),则所有前台人员都拥有考勤查询的权利。

(二):通过项目

在项目中,项目成员的权限来自于所在项目的权限,他们同样不能继承下级项目的权限,而对于项目组长,他对项目有全权,对下级项目也一样。

例如在项目中,项目成员可以对项目中上传文档,查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口,这样每个成员能访问这个项目了,再加上项目文档的上传权限和查看文档权限即可。

对于组长,因为可以赋予组长一个组长权(组长权是个特殊的权限,它包含其他各种权限的一个权限包),所有组长对于本项目有全权,则项目组长可以对于项目文档查看,审批,删除,恢复等,这些权限对于本项目的下级项目依然有效。

(三):通过角色

角色中的成员继承角色的权限,角色与角色没有上下级关系,他们是平行的。通过角色赋予权限,是指没办法按职位或项目的分类来赋予权限的另一种方式,如:系统管理员,资料备份员

例如对于系统中,全体人员应该默认都有的模块,如我的邮件,我的文档,我的日志,我的考勤等等,这些模块系统成员都应该有的,我们建立一个角色为系统默认角色, 把所有默认访问的模块的浏览权限加入到里面去,则系统成员都能访问这些模块。 (四):直接指定

直接指定是通过对某个人具体指定一项权限,使其有使用这个权限的能力。直接指定是角色指定的一个简化版,为了是在建立像某个项目的组长这种角色时,省略创建角色这一个步骤,使角色不至于过多。

例如指定某个项目的组长,把组长权限指定给某个人。

二针对职位、项目组:

如果用添加新员工,员工调换职位、项目组,满足了员工会自动继承所在职位、项目组的权限,不需要重新分配权限的功能。

(一)用户管理

用户可以属于某一个或多个用户组,可以通过对用户组授权,来对组中的所有用户进行权限的授予。一个用户可以属于多个项目组,或担任多个职位。

(二)授权管理

将一个基本权限或角色授予用户或用户组,使用户或用户组拥有授予权限的字符串,如果角色、职位、项目中存在相同的基本权限,则取其中的一个;如脱离角色、职位、项目组,只是取消用户或用户组的中此角色、职位、项目组所授予的权限。用户所拥有的权限是所有 途径授予权限的集合。管理员用户可以查看每个用户的最终权限列表。

(三)权限管理

基本操作权限与权限组(基本操作权限的集合)的管理。 权限管理设计的实现:

设计一个通用的权限管理模块,当开发一个系统时能将此模块快速的移植到其中,对系统的用户权限进行管理。次模块将在一个学生信息管理系统中模拟实现。

系统采用三层模式:表示层、系统逻辑实现层、数据库层。

权限的控制在第二层和第三层实现。

金蝶K3数据权限管理

金蝶K/3数据权限管理 (K/3 各版本数据权限管理) 概述 l本文档适用金蝶K/3各版本数据权限管理。 l学习完本文档以后,您将了解数据权限设置过程。 l2012年5月31日V1.0 编写人:孙新建 步骤 数据权限是指对系统中具体数据的操作权限,分为数据查询权、数据修改权、数据删除权。 数据权限控制范围包括基础资料、BOM、BOS基础资料。 一、设置数据权限控制 1、打开【系统设置】-【用户管理】-【用户管理】-【用户管理】,选择用户名,点击 菜单【数据权限】-【设置数据权限控制】,显示“设置数据权限控制”界面。

2、“设置数据权限控制”界面,选择“子系统”,在子系统下选择需要设置的“数据 类别”并勾选“启用数据权限控制”,并点击【应用】按钮保存设置结果。 二、用过【数据权限管理】对系统中的用户进行该类别数据进行数据授权操作。

1、选择某个用户名,点击菜单【数据权限】-【数据权限管理】,选择“数据类型”,首先 取消该用户【具有当前数据类型的全部数据权限】选项,使当前用户默认不再具有当前数据类型的全部数据权限。取消该选项时,可以选择清理当前数据的权限或保留当前数据的权限。 2、选择授权方式,可以“按明细数据授权”或“按上级组授权”。

3、点击【授予查询权】、【授予修改权】或【授予删除权】按钮,出现当前数据类型的F7 选择界面,可以通过F7 界面浏览或搜索选择需要进行数据授权的数据。当用户选中数据后,系统立即授予当前用户相应的权限,并将选择的数据具有的数据权限在权限浏览 界面中显示。

可以对每一条数据进 行分别设置查询权、 修改权、删除权 4、授权用户可以在权限浏览界面上修改数据相应的数据权限,并通过点击【保存权限】按 钮保存授权用户所修改的权限。用户可以批量选中多个数据进行授权操作。 5、授权用户可以通过【取消查询权】、【取消修改权】或【取消删除权】按钮,同样现当

系统权限管理设计方案(优选.)

OA系统权限管理设计方案 l 不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 l 可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 l 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 l 满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 针对OA系统的特点,权限说明: 权限 在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。

角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4种方式(参考飞思办公系统) A. 通过职位 a) 在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继承。 b) 实例中:如前台这个职位,对于考勤查询有权限,则可以通过对前台这个职位设置考勤查询的浏览权,使他们有使用这个对象的权限,然后再设置个,考勤查询权(当然也可以不设置,默认能进此模块的就能查询),则所有前台人员都拥有考勤查询的权利。 B. 通过项目 a) 在项目中,项目成员的权限来自于所在项目的权限,他们同样不能继承下级项目的权限,而对于项目组长,他对项目有全权,对下级项目也一样。 b) 实例中:在项目中,项目成员可以对项目中上传文档,查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口,这样每个成员能访问这个项目了,再加上项目文档的上传权和查看文档权即可。

一种通用权限管理方案的设计方案

一种通用权限管理方案的设计方案 分析了权限管理的概念和一些与权限管理容易混淆的概念。提出了一种目前可以应用到绝大多数与权限有关的系统设计中的通用权限管理方案。该方案以角色对用户进行分组,通过用户数据库、角色数据库、权限数据库、用户-权限数据库以及角色-权限数据库来实现权限的分层管理。该设计方案能够由管理员方便的对权限进行设置。通过对角色的权限设置可以达到快速设置权限。通过对用户的权限设置可以达到权限的精确控制。文章最后以某项目为基础对该权限设计方案进行了实现。通过测试,该方案能够很好的对用户权限进行控制,从而提高整个系统的安全性。 标签:权限系统角色数据库 1 权限管理的概念 权限管理是软件系统中最常见的功能之一。所谓权限管理,一般指根据系统设置的安全规则或者安全策略,用户可以访问而且只能访问自己被授权的资源,不多不少。权限管理几乎出现在任何系统里面,只要有用户和密码的系统。尤其是在B/S机构的系统中,由于没有专门的客户端软件系统,所以权限管理就显的尤为重要。如果一个B/S系统的权限管理设计的不好,那么一个“非法用户”就可以轻而易举的获取整个系统的所有本能,包括超级管理员的功能。那么这样的系统还有谁敢使用。 很多人,常将“用户身份认证”、“密码加密”、“系统管理”等概念与权限管理概念混淆。用户身份认证,根本就不属于权限管理范畴。用户身份认证,是要解决这样的问题:用户告诉系统“我是谁”,系统就问用户凭什么证明你就是“谁”呢?对于采用用户名、密码验证的系统,那么就是出示密码。当用户名和密码匹配,则证明当前用户是谁;对于采用指纹等系统,则出示指纹;对于硬件Key 等刷卡系统,则需要刷卡。密码加密,是隶属用户身份认证领域,不属于权限管理范畴。 2 权限管理的设计 2.1 权限管理的对象在一般的系统设计中,权限管理的参于对象包括用户对象、角色(或分组)对象、功能模块对象。角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色。功能模块则对不同的系统来说各不相同,一般在系统设计中最终将其以图形界元素的形式表现出来(比如软件界面上的各个功能按钮)。 2.2 权限管理举例下面我们举例说明2.1中提到的用户、角色、功能三个对象在权限管理中具体应用。表1中列出了某文档管理项目中权限管理的一部分设计表。从中我们可以清晰的区别出这三个对象以及它们的各自作用。

信息系统权限及数据管理办法

******股份有限公司 信息系统权限及数据管理办法(试行) 第一章总则 第一条为了加强对******股份有限公司(简称:公司)各运行信息系统权限和数据的管理,明确权限及数据管理相关责任部门,提高信息系统的安全运行和生产能力,规范公司业务系统权限申请及数据管理流程,防范业务系统操作风险,公司制定了信息系统权限及数据管理办法,以供全公司规范执行。 第二条本办法所指信息系统权限及数据包括,但不仅限于公司运行的OA 办公系统、业务作业系统、对外网站系统等涉及的系统用户权限分配、日常管理、系统及业务参数管理,以及数据的提取和变更。 第三条本办法遵循责权统一原则对员工进行系统授权管理,控制公司相关信息传播范围或防范进行违规操作。 第四条信息技术部是本办法主要执行部门,设立系统运维岗负责系统用户权限管理、部分基本参数设置、系统数据的提取和变更的具体技术实现。其它相关部门应指定专人(简称:数据权限管理员)负责统一按本办法所制定的流程执行相关操作,或通过工作联系单方式提出需要信息技术部或其它相关部门完成的具体工作内容。 第五条用户授权和权限管理应采取保守原则,选择最小的权限满足用户需求。 第二章系统权限管理 第六条系统权限管理由信息技术部系统运维岗和各业务部门数据权限管理员共同协作完成,风险与合规部数据权限管理员负责对业务部门提出的系统权限进行审批,信息技术部系统运维岗负责对权限进行变更。信息技术部系统运维岗拥有系统管理和用户管理权限(信息技术部可以拥有开发测试环境超级用户权限),风险与合规部拥有超级用户权限,风险与合规部数据权限管理员拥有对权限列表进行查询的权限,以方便行使监督职能。

系统权限管理方案

权限 在系统中,权限通过模块+动作来产生。(在系统中也就是一个页面的所有操作,比如(浏览、添加、修改、删除等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个权限组,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。 角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。 用户组将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 一、通过给某个人赋予权限,有四种方式: (一):通过职位 在职位中,职位成员的权限继承当前所在职位的权限,对于下级职位拥有的权限不可继承。 例如前台这个职位,对于考勤查询有权限,则可以通过对前台这个职位设置考勤 查询的浏览权,使他们有使用这个对象的权限,然后再设置个考勤查询权(当然也可以不设置,默认能进此模块的就能查询),则所有前台人员都拥有考勤查询的权利。 (二):通过项目 在项目中,项目成员的权限来自于所在项目的权限,他们同样不能继承下级项目的权限,而对于项目组长,他对项目有全权,对下级项目也一样。 例如在项目中,项目成员可以对项目中上传文档,查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口,这样每个成员能访问这个项目了,再加上项目文档的上传权限和查看文档权限即可。 对于组长,因为可以赋予组长一个组长权(组长权是个特殊的权限,它包含其他各种权限的一个权限包),所有组长对于本项目有全权,则项目组长可以对于项目文档查看,审批,删除,恢复等,这些权限对于本项目的下级项目依然有效。 (三):通过角色 角色中的成员继承角色的权限,角色与角色没有上下级关系,他们是平行的。通过角色赋予权限,是指没办法按职位或项目的分类来赋予权限的另一种方式,如:系统管理员,资料备份员 例如对于系统中,全体人员应该默认都有的模块,如我的邮件,我的文档,我的日志,我的考勤等等,这些模块系统成员都应该有的,我们建立一个角色为系统默认角色, 把所有默认访问的模块的浏览权限加入到里面去,则系统成员都能访问这些模块。 (四):直接指定 直接指定是通过对某个人具体指定一项权限,使其有使用这个权限的能力。直接指定是角色指定的一个简化版,为了是在建立像某个项目的组长这种角色时,省略创建角色这一个步骤,使角色不至于过多。 例如指定某个项目的组长,把组长权限指定给某个人。 二针对职位、项目组: 如果用添加新员工,员工调换职位、项目组,满足了员工会自动继承所在职位、项目组的权限,不需要重新分配权限的功能。

通用权限管理系统java权限处理及其实现思路

关键字: 用户权限管理 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的 事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的 人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管 理系统,就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之 间,功能权限是可以重用的,而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。 我们先来分析一下数据库结构:

通用数据权限管理系统设计

通用数据权限管理系统设计 作者:逸云来源:网络 前言: 本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能权限的基础上增加数据权限的管理,实现数据权限和功能权限的集中处理。 解释: 功能权限:能做什么的问题,如增加销售订单; 数据权限:能在哪里干什么的问题,如察看北京分公司海淀销售部张三的销售订单; 术语: 资源:系统中的资源,主要是各种业务对象,如销售单、付款单等; 操作类型:对资源可能的访问方法,如增加、删除、修改等; 功能:对资源的操作,是资源与操作类型的二元组,如增加销售单、修改销售单等; 数据类型:业务系统中常用的数据权限类型,如公司、部门、项目、个人等; 数据对象:具体的业务对象,如甲公司、乙部门等等,包括所有涉及到数据权限的对象值; 权限:角色可使用的功能,分角色的功能权限和角色的数据权限; 角色:特定权限的集合; 用户:参与系统活动的主体,如人,系统等。 通用数据权限管理系统设计(二) 方法说明: 在实际应用中,数据权限的控制点一般相对固定,如针对公司、部门、个人、客户、供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象。 本方法中,数据权限的依赖于功能权限,是对功能权限的进一步描述,说明角色在指定的功能点上的数据控制权限。 本方法中采用“没有明确规定即视为有效”的原则,如果没有定义功能的数据权限,则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限,则该用户只具有该类型下指定数据的数据权限。 这段话比较绕口,下面举个例子实际例子。 某公司有北京销售部、上海销售部和广州销售部三个销售部,现在需要定义几种角色: ?销售总监-- 能察看所有销售部的销售订单; ?北京销售经理-- 只能察看北京销售部的所有销售订单; ?上海销售经理-- 只能察看上海销售部的所有销售订单;

最经典用户权限管理模块设计

实现业务系统中的用户权限管理--设计篇 B/S系统中的权限比C/S中的更显的重要,C/S系统因为具有特殊的客户端,所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现,而B/S中,浏览器是每一台计算机都已具备的,如果不建立一个完整的权限检测,那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测,让经过授权的用户可以正常合法的使用已授权功能,而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便 的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致 的人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套 管理系统,就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统 之间,功能权限是可以重用的,而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念,在设计阶段,系统设计人员无须考虑程序结构的设计,而是从程序流程以及数据库结构开始入手。为了实现需求,数据库的设计可谓及其重要,无论是“组”操作的概念,还是整套权限管理系统的重用性,都在于数据库的设计。 我们先来分析一下数据库结构: 首先,action表(以下简称为“权限表”),gorupmanager表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图:

多系统权限设计

多系统权限设计 1.多系统基于角色的权限设计 这种方案是最常见也是比较简单的方案,不过通常有这种设计已经够了,这种方案对于每一个操作不做控制,只是在程序中根据角色对是否具有操作的权限进行控制;这里我们就不做详述.此处采用角色关联模块的方式。 2.多系统基于操作的权限设计 这种模式下每一个操作都在数据库中有记录,用户是否拥有该操作的权限也在数据库中有记录,结构如下:

但是如果直接使用上面的设计,会导致数据库中的_SysUserFuncOperate这张表数据量非常大,所以我们需要进一步设计提高效率,请看方案3 3.多系统基于角色和操作的权限设计

如上图所示,我们通过采用角色分配操作的方式,这样子就可以减少操作权限表(_SysRole FuncOperate)中的记录,并且使设计更灵活一点。 但是这种方案在用户需求的考验之下也可能显得不够灵活够用,例如当用户要求临时给某位普通员工某操作权限时,我们就需要新增加一种新的用户角色,但是这种用户角色是不必要的,因为它只是一种临时的角色,如果添加一种角色还需要在收回此普通员工权限时删除此角色,我们需要设计一种更合适的结构来满足用户对权限设置的要求。 4.2,3组合的权限设计,其结构如下: 我们可以看到在上图中添加了_SysUserFunc和_SysUserFuncOperate表,使用此表来添加特殊用户的权限。这样在应用程序中我们就需要通过_SysUserFuncOperate和_SysRoleFuncOperat e两张表中的记录判断权限。 当然,有可能用户还会给出这样的需求:对于某一种Operate所操作的对象某一些记录会有权限,而对于其他的记录没有权限,比如说一个内容管理系统,对于某一些频道某个用户有

用户权限设计(三)——通用数据权限管理系统设计

通用数据权限管理系统设计(一) 作者:逸云 前言: 本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能权限的基础上增加数据权限的管理,实现数据权限和功能权限的集中处理。 解释: 功能权限:能做什么的问题,如增加销售订单; 数据权限:能在哪里干什么的问题,如察看北京分公司海淀销售部张三的销售订单; 术语: 资源:系统中的资源,主要是各种业务对象,如销售单、付款单等; 操作类型:对资源可能的访问方法,如增加、删除、修改等; 功能:对资源的操作,是资源与操作类型的二元组,如增加销售单、修改销售单等; 数据类型:业务系统中常用的数据权限类型,如公司、部门、项目、个人等; 数据对象:具体的业务对象,如甲公司、乙部门等等,包括所有涉及到数据权限的对象值;权限:角色可使用的功能,分角色的功能权限和角色的数据权限; 角色:特定权限的集合; 用户:参与系统活动的主体,如人,系统等。 通用数据权限管理系统设计(二) 方法说明: 在实际应用中,数据权限的控制点一般相对固定,如针对公司、部门、个人、客户、供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象。 本方法中,数据权限的依赖于功能权限,是对功能权限的进一步描述,说明角色在指定的功能点上的数据控制权限。 本方法中采用“没有明确规定即视为有效”的原则,如果没有定义功能的数据权限,则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限,则该用户只具有该类型下指定数据的数据权限。 这段话比较绕口,下面举个例子实际例子。 某公司有北京销售部、上海销售部和广州销售部三个销售部,现在需要定义几种角色:销售总监-- 能察看所有销售部的销售订单; 北京销售经理-- 只能察看北京销售部的所有销售订单; 上海销售经理-- 只能察看上海销售部的所有销售订单; 广州销售经理-- 只能察看广州销售部的所有销售订单;

系统权限管理设计方案.doc

OA系统权限管理设计方案7 OA系统权限管理设计方案 数据库2010-02-2310:09:25阅读13评论0字号:大中小 OA系统权限管理设计方案 l不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的功能。 l可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组”进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 l权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进行重新开发。 l满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能。 针对OA系统的特点,权限说明: 权限

在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。 角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中,用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限,有4种方式(参考飞思办公系统) A.通过职位 a)在职位中,职位成员的权限继承当前所在职位的权限,对

权限管理设计说明

对EMS权限管理模块设计 1.权限设计概述 1.1引言 随着Web 服务的复杂度增加以及用户数量和种类的增多,安全问题在理论及工程上都 是一个必须考虑的问题,而权限管理是安全问题中一个很重要的方面。因此本文针对权限做 了一个分析。 权限可简单表述为这样的逻辑表达式:判断“Who对What(Which)进行How的操作”的 逻辑表达式是否为真。 1.2意义 ?用户管理及权限管理一直是应用系统中不可缺少的一个部分 ?系统用户很多,系统功能也很多 ?不同用户对系统功能的需求不同 ?出于安全等考虑,关键的、重要的系统功能需限制部分用户的使用 ?出于方便性考虑,系统功能需要根据不同的用户而定制 1.3目标 直观,因为系统最终会由最终用户来维护,权限分配的直观和容易理解,显得比较重要, 除了功能的必须,更主要的就是因为它足够直观。 简单,包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解 决所有的权限问题是不现实的。设计中将变化的“定制”特点比较强的部分判断为业务逻辑, 而将相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。 扩展,采用可继承的方式解决了权限在扩展上的困难。引进Group概念在支持权限以组 方式定义的同时有效避免了权限的重复定义。 2.基于角色的权限管理设计(Role-Based Access Control,RBAC)2.1权限管理用例图

2.2用例图描述 超级管理员:系统中默认的角色,它是系统中拥有最高权限的角色,它不仅能够管理其他的管理员和用户,而且还可以对系统中每个模块的任一功能进行操作、维护。 普通管理员:它是由超级管理员创建的,并授予权限,它能够管理系统部分的功能,它可以查看所有普通管理员、普通用户的信息,它只能对由它自己创建的用户进行编辑、删除操作,和管理拥有权限的模块。 普通用户:它是系统中最低权限的角色,它只能对自己拥有的权限进行操作,一般情况下,它的权限是对信息的浏览和对自己信息的录入,修改。 登陆系统:根据用户拥有的权限不同,用户所能操作的功能多少就不同,所以在登陆系统的时候就要对用户的权限进行判断。

BBCA统一权限管理系统设计方案

(此文档为word格式,下载后您可任意编辑修改!) 统一权限管理系统 设计方案 项目名称: 承建单位: 管理单位: 意见签署页 需求确认栏

修订历史记录

目录 第1章引言 (1) 1.1概述 (1) 1.2目标 (1) 1.3术语 (2) 1.4参考资料 (3) 第2章总体设计 (4) 2.1运行环境 (4) 2.2设计思路 (4) 2.3认证服务模式 (6) 第3章功能概述 (7) 3.1系统用例 (8) 3.2处理流程 (9) 3.3应用系统设置 (11) 3.4用户管理模块设置 (11) 3.5权限及菜单设置 (13) 3.6角色管理设置 (16) 3.7应用系统调用方式 (17) 3.7.1身份验证 (17) 3.7.2获取用户权限列表 (17) 3.7.3获取菜单列表 (17) 3.7.4权限管理 (17) 3.8概念模型 (17) 第4章整合SSO (19)

第1章引言 1.1 概述 权限管理是应用系统中不可缺少的一部分,通常的做法是每开发一个系统都要将这部分功能作为一个模块来开发,一般要开发过程包含以下几个步骤: 1. 在数据库中建立用户和权限相关的表结构 2. 开发用户、角色、权限管理等的功能模块 3. 为系统的每个功能加入获取和判断权限的方法 其实在不同的应用系统中,这些功能基本上都是一样的,每个系统都要加入这些大同小异的功能无疑会带来相当多的重复性工作,浪费我们不少宝贵时间。虽然将这些功能模块化能减轻一些工作,但由于每个系统采用的开发环境不同(如有些系统采用.net技术,有些用J2EE技术),或者虽然采用的开发技术相同,但采用的框架也可能存在差异(如在J2EE技术下有的采用Hibernate,有的采用IBATIS或者直接调用JDBC等),造成将这些权限模块移植到不同的应用系统时还是需要对代码进行相当繁琐的修改。 1.2 目标 为了提高功能的可复用性,结合公司以往的成功项目经验,通过统一的系统规划和系统设计,开发一套通用的权限管理系统,将用户管理、权限管理及单点登录功能都集成到该系统中。该系统主要解决后期新开发的应用系统无需重新开发权限管理模块的工作,不管新开发的应用系统采用的是什么开发环境,都可以通过WebService 方法来调用权限管理系统提供的权限认证服务,而且还可以实现用户一次登录、网内通用,避免每进入一个系统都要重复登录的情况。此外,可以对区域内各信息应用系统的权限分配和权限变更进行有效的统一化管理,实现多层次统一授权,审计各种权限的使用情况,防止信息共享后的权限滥用,规范今后的应用系统的建设。 本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管

(完整版)应用系统权限及数据管理安全管理办法

用友系统权限及数据管理办法 一、总则 为了保障在用友系统使用及管理过程中因不安全的操作而导致的数据泄漏、被盗取等安全事件的发生,特制定本办法。 二、本管理办法仅适用于公司全员。 三、职责与分工 1、职能部门: (1)公司权限负责人:总经理 1)负责签批部门间的权限的授予; 2)负责对用友系统用户帐号及密码安全进行不定期抽查; (2)系统管理员:财务负责人 1)用友系统管理由财务部负责,除总经理及财务部指定的系统管理员外任何部门不得担任系统管理员一职。 2)负责帐号、各岗位权限分配、系统维护、各模块使用情况的安全运行监管。 3)负责根据《用友用户新增\变更\注销请示单》在系统中设置用户权限; 4)负责维护本单位用户和权限清单; 5)遵守职业道德,接受总经理权限负责人的抽查。 (3)各岗位系统操作员:负责所使用模块的权限管理和该模块的数据安全; A.采购部负责有关产品基础信息定义、系统采购模块使用。 B.销售部负责系统销售模块使用。 C.物流部负责仓库管理权限和销售单打印、查询权限; 2、用户帐号: 登录用友系统需要有用户帐号,用户帐号是由财务部系统管理员根据员工工作岗位员工的工作性质规定下进行系统岗位功能、权限分配和设置的。 (1)密码设置及更改: 1)第一次登录用友系统时,用户必须改变事先由管理员分配的初始密码; 2)系统管理员及操作员密码每三个月必须变更一次,密码不少于6位。 3、帐号与密码保管: 系统使用人必须保证用户ID和用户密码的保密和安全,不得对外泄漏,用户帐号不可转借他人使用;

3、责任承担及注意事项: (1)帐号的对应的使用者应对该帐号在系统中所做的操作及结果负全部责任。(2)系统管理员应该每天检查系统日志,对发现的非法登录、访问等行为。(3)管理帐号及管理权限的增加、删除必须经总经理书面批准,任何人不得任意增加、修改、删除。 (4)任何人除所负责权限岗位以外的信息数据不得随意导出:如客户资料、产品进价、销售数据等,如有需要需提交书面申请交总经理审批后统一由财务部导出打印,并建立打印档案。 (5)非财务部指定的系统管理人员未经许任何人不得擅自操作和对运行系统及各种设置进行更改。 四、用户申请\变更\注销流 (1)由用户本人提出申请(填写《请示单》)经部门主管审核交财务部并报总经理审核批示使用权限; (2)财务部系统管理员根据经总经理审批《请示单》在系统中进行权限设置后通知申请人; (3)申请人应在收到通知的当天修改初始口令。 (4)当用户由于工作变动、调动或离职等原因需要对用户的访问权限进行修改或注销时,应填写书面《请示单》经总经理审批后系统管理员应及时进行用户的变更、暂停或注销权限。 三、数据备份及安全管理 1、服务器数据库要设置每日自动备份,每周五财务部应进行一次介质数据的备份并异地存放,确保系统一旦发生故障时能够快速恢复,备份数据不得更改。 2、系统管理人员应恪守保密制度,不得擅自泄露中心各种信息资料与数据。 3、服务器是用友系统的关键设备,不得随意调试、挪作它用。 4、系统操作时,外来人员不得随意操作、靠近观看。对外来人员不合理要求应婉拒,外来人员不得未经同意不得查看、操作系统。 二、计算机病毒防范制度 1、系统管理人员应有较强的病毒防范意识,定期进行病毒检测。 2、不得在服务器上安装新软件,若确为需要安装,安装前应进行病毒例行检测。 3、经远程通信传送的程序或数据,必须经过检测确认无病毒后方可使用。 4、定期进行电脑杀毒,对电脑中毒后在各种杀毒办法无效后,须重新对电脑格

OA系统权限管理设计方案

OA系统权限管理设计方案 不同职责的人员,对于系统操作的权限应该是不同的。优秀的业务系统,这是最基本的 功能。 可以对“组”进行权限分配。对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的事情。所以,系统中就提出了对“组” 进行操作的概念,将权限一致的人员编入同一组,然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用,而不是每开发一套管理系统,就要针对权限管理部分进 行重新开发。 满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资源权限的管理,在不同系统之间,功能权限是可以重用的,而资源 权限则不能。 针对OA系统的特点,权限说明: 权限 在系统中,权限通过模块+动作来产生,模块就是整个系统中的一个子模块,可能对应一个菜单,动作也就是整个模块中(在B/S系统中也就是一个页面的所有操作,比如“浏览、添加、修改、删除”等)。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理,另将一个模块下的所有权限组合一起,组成一个“权限组”,也就是一个模块管理权限,包括所有基本权限操作。比如一个权限组(用户管理),包括用户的浏览、添加、删除、修改、审核等操作权限,一个权限组也是一个权限。 角色 权限的集合,角色与角色之间属于平级关系,可以将基本权限或权限组添加到一个角色中, 用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限(角色),快速使一类人具有相同的权限,来简化对用户授予权限的繁琐性、耗时性。用户组的划分,可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。

信息系统权限及数据管理办法

******股份有限公司 信息系统权限及数据管理办法(试行)
第一章 总则
第一条 为了加强对******股份有限公司(简称:公司)各运行信息系统权 限和数据的管理,明确权限及数据管理相关责任部门, 提高信息系统的安全运行 和生产能力, 规范公司业务系统权限申请及数据管理流程,防范业务系统操作风 险,公司制定了信息系统权限及数据管理办法,以供全公司规范执行。 第二条 本办法所指信息系统权限及数据包括,但不仅限于公司运行的 OA 办公系统、 业务作业系统、 对外网站系统等涉及的系统用户权限分配、 日常管理、 系统及业务参数管理,以及数据的提取和变更。 第三条 本办法遵循责权统一原则对员工进行系统授权管理, 控制公司相关 信息传播范围或防范进行违规操作。 第四条 信息技术部是本办法主要执行部门, 设立系统运维岗负责系统用户 权限管理、部分基本参数设臵、系统数据的提取和变更的具体技术实现。其它相 关部门应指定专人(简称:数据权限管理员)负责统一按本办法所制定的流程执 行相关操作, 或通过工作联系单方式提出需要信息技术部或其它相关部门完成的 具体工作内容。 第五条 用户授权和权限管理应采取保守原则, 选择最小的权限满足用户需 求。
第二章
系统权限管理
第六条 系统权限管理由信息技术部系统运维岗和各业务部门数据权限管 理员共同协作完成, 风险与合规部数据权限管理员负责对业务部门提出的系统权 限进行审批, 信息技术部系统运维岗负责对权限进行变更。信息技术部系统运维 岗拥有系统管理和用户管理权限 (信息技术部可以拥有开发测试环境超级用户权 限) ,风险与合规部拥有超级用户权限,风险与合规部数据权限管理员拥有对权 限列表进行查询的权限,以方便行使监督职能。
1

系统权限设计

系统权限设计 需求陈述 ?不同职责的人员,对于系统操作的权限应该是不同的。可以对“组”进行权限分配。 ?对于一个大企业的业务系统来说,如果要求管理员为其下员工逐一分配系统操作权限的话,是件耗时且不够方便的 事情。所以,系统中就提出了对“组”进行操作的概念, 将权限一致的人员编入同一组,然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断 的重用,而不是每开发一套管理系统,就要针对权限管理 部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中,存在着两种权限管理,其一是功能权限的管理,而另外一种则是资 源权限的管理,在不同系统之间,功能权限是可以重用的,而资源权限则不能 (以后可以加入权限分配管理的功能,目前暂不考虑) 首先,action表(以下简称为“权限表”),gorupmanager表(以

下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图: 首先,action表(以下简称为“权限表”),gorupmanager 表(以下简称为“管理组表”),以及master表(以下简称为“人员表”),是三张实体表,它们依次记录着“权限”的信息,“管理组”的信息和“人员”的信息。如下图: 这三个表之间的关系是多对多的,一个权限可能同时属于多个管理组,一个管理组中也可能同时包含多个权限。同样的道理,一个人员可能同时属于多个管理组,而一个管理组中也可能同时包含多个人员。如下图:

由于这三张表之间存在着多对多的关系,那么它们之间的交互,最好使用另外两张表来完成。而这两张表起着映射的作用,分别是“actiongroup”表(以下简称“权限映射表”)和“mastergroup”表(以下简称“人员映射表”),前者映射了权限表与管理组表之间的交互。后者映射了人员表与管理组表之间的交互。如下图:

111111111通用权限管理系统详细设计说明书

第一章引言 1.1 编写目的 系统详细设计说明书在概要设计的基础上,对统一权限管理系统的各模块、数据等分别进行了实现层面上的要求和说明。 本文档读者为系统设计人员、软件实现人员等(编码人员、测试人员),为程序的开发提供依据。 1.2 背景 石家庄大学有办公自动化系统、图书管理系统、教务系统、排课系统、宿舍管理系统等等系统。每个系统都有独立的系统管理权限模块,不便于学校系统管理员的统一管理,而且管理成本也比较高。 统一权限管理系统实现以上软件的统一权限管理,实现系统管理、用户管理等功能,是实现单点登录的基础。 1、项目名称是《统一权限管理系统》; 2、本项目的委托单位是石家庄大学,开发单位是安全一班和二班的全体同学,主管部 门信息工程系。 1.3 定义 权限: 角色 数据库建模: 统一权限管理: 三层架构:

1.4 参考文献 用到的参考资料如下表1.1所示: 表1.1 参考资料表

第二章总体设计 2.1 系统功能概述 通过此权限软件来统一管理我们学校所有或大部分系统软件的用户权限,降低整个学校系统的权限分配复杂性、提高可维护性、降低系统管理员的管理成本。为二期的统一用户单点登录工程项目打下了良好的基础。 通过系统概要设计说明书可知,此统一权限管理系统主要实现系统管理、权限管理、用户管理、日志管理等功能。系统功能结构如图2.1所示。 图2.1 系统功能结构图 2.2 系统软件结构 统一权限管理系统的软件结构如图2.2所示。

图2.2 系统软件结构图

第三章数据设计 3.1 静态数据 初始状态下,统一权限管理系统的测试用户,设置初始超级管理员,其登录用户名为admin,密码为123456。 初始测试用户如表3.1所示。 表3.1 初始测试用户表 3.2 动态数据 统一权限管理系统涉及到的基本数据信息有系统信息、系统模块信息、角色信息、划分权限信息、用户信息、分配角色信息、部门信息等。 一、系统信息 系统信息应包含系统编号、系统名称、系统描述信息、显示顺序等,如表3.2所示。 表3.2 系统信息表 二、系统模块信息 系统模块信息应包含模块编号、模块名称、模块描述、模块地址、显示顺序、显示图标等,如表3.3所示。 表3.3 系统模块信息表

统一身份认证、统一系统授权、统一系统审计、统一消息平台、统一内容管理方案设计

基础支撑层 统一身份认证(SSO) 统一身份认证解决用户在不同的应用之间需要多次登录的问题。目前主要有两种方法,一种是建立在PKI,Kerbose和用户名/口令存储的基础上;一种是建立在cookie的基础上。统一身份认证平台主要包括三大部分:统一口令认证服务器、网络应用口令认证模块(包括Web 口令认证、主机口令认证模块、各应用系统口令认证模块等) 和用户信息数据库,具体方案如下图。 1、采用认证代理,加载到原有系统上,屏蔽或者绕过原有系统的认证。 2、认证代理对用户的认证在公共数据平台的认证服务器上进行,认证代理可以在认证服务器上取得用户的登录信息、权限信息等。 3、同时提供一个频道链接,用户登录后也可以直接访问系统,不需要二次认证。 4、对于认证代理无法提供的数据信息,可以通过访问Web Service接口来获得权限和数据信息。 单点登录认证的流程如下图所示:

单点登录只解决用户登录和用户能否有进入某个应用的权限问题,而在每个业务系统的权限则由各自的业务系统进行控制,也就是二次鉴权的思想,这种方式减少了系统的复杂性。统一身份认证系统架构如下图所示。 统一系统授权 统一系统授权支撑平台环境中,应用系统、子系统或模块统通过注册方式向统一系统授权支撑平台进行注册,将各应用系统的授权部分或全部地委托给支撑平台,从而实现统一权限管理,以及权限信息的共享,其注册原理如下图。

用户对各应用系统的访问权限存放在统一的权限信息库中。用户在访问应用系统的时候,应用系统通过统一授权系统的接口去查询、验证该用户是否有权使用该功能,根据统一系统授权支撑平台返回的结果进行相应的处理,其原理如下图。 统一系统授权支撑平台的授权模型如下图所示。在授权模型中采用了基于角色的授权方式,以满足权限管理的灵活性、可扩展性和可管理性的需求 块

数据可视化系统及其数据权限管理方法与设计方案

图片简介: 本技术提供一种数据可视化系统及其数据权限管理方法,其中系统包括:一角色管理模块、一用户管理模块和一分享功能模块;角色管理模块用于创建和管理角色,角色包括一级角色和二级角色;二级角色关联于一级角色下;用户管理模块用于创建和管理用户,用户包括超级管理员、一级用户和二级用户;一级用户关联于一级角色下并拥有对应一级角色和该一级角色关联的二级角色的所有数据权限;二级用户关联于二级角色下并拥有对应二级角色的数据权限;分享功能模块用于数据权限的分享。本技术的一种数据可视化系统及其数据权限管理方法,可快速配置页面、按钮及数据权限,数据层级分级明确,可按组织架构及部门进行数据交互,节约人力成本。 技术要求 1.一种数据可视化系统,其特征在于,包括:一角色管理模块、一用户管理模块和一分享功能模块; 所述角色管理模块用于创建和管理角色,所述角色包括一级角色和二级角色;所述二级 角色关联于所述一级角色下;

所述用户管理模块用于创建和管理用户,所述用户包括超级管理员、一级用户和二级用户;所述一级用户关联于所述一级角色下并拥有对应所述一级角色和该一级角色关联的所述二级角色的所有数据权限;所述二级用户关联于所述二级角色下并拥有对应所述二级角色的数据权限; 所述分享功能模块用于数据权限的分享。 2.根据权利要求1所述的数据可视化系统,其特征在于,所述角色管理模块包括一新增角色模块、一搜索模块、一权限信息查看模块、一角色详情查看模块和一角色编辑模块; 所述新增角色模块用于新建所述一级角色和所述二级角色,所述新建所述一级角色和所述二级角色包括输入和存储所述一级角色和所述二级角色的角色基本信息并设置角色权限信息,所述角色权限信息包括页面权限、数据权限和按钮权限; 所述搜索模块用于搜索符合搜索条件的所述角色并展示; 所述权限信息查看模块包括一页面权限查看模块、一数据权限查看模块和一按钮权限查看模块;所述页面权限查看模块用于查看展示对应角色的所述页面权限;所述数据权限查看模块用于查看展示对应角色的所述数据权限;所述按钮权限查看模块用于查看展示对应角色的所述按钮权限; 所述角色详情查看模块用于查看角色详情信息; 所述角色编辑模块用于更改对应角色的所述角色基本信息、所述角色权限信息和角色状态信息,展示对应角色的角色成员信息。 3.根据权利要求2所述的数据可视化系统,其特征在于,所述角色基本信息包括角色名称、角色分类和角色备注; 所述角色详情信息包括所述角色基本信息、所述角色权限信息、一角色日志、角色ID信息、所述角色成员信息和所述角色状态信息; 所述角色状态信息包括启用和废弃。

相关文档
相关文档 最新文档