实验五用户、角色与权限管理
一、实验目的及要求
掌握Oracle的安全管理方法。
二、实验主要内容
(1) 概要文件的建立、修改、查看、删除操作。
(2) 用户的建立、修改、查看、删除操作。
(3) 权限的建立、修改、查看、删除操作。
(4) 角色的建立、修改、查看、删除操作。
三、实验仪器设备
在局域网环境下，有一台服务器和若干台客户机。服务器成功安装Oracle 11g 数据库服务器（企业版），客户机成功安装Oracle 11g客户端软件，网络服务配置正确，数据库和客户端正常工作。
四、实验步骤
1创建概要文件。
①利用企业管理器创建概要文件“ygbx+学号_pro”，要求在此概要文件中CPU/会话为1000，读取数/会话为2000，登录失败次数为3，锁定天数为10。
②利用SQL*Plus或PL/SQL Developer，创建概要文件“ygbx+学号_pro_sql”，其结构与“ygbx+学号_pro”一致。
2 查看概要文件。
②利用企业管理器查看概要文件“ygbx+学号_pro”的信息。
②利用SQL*Plus或PL/SQL Developer，从DBA_PROFILES数据字典中查看“ygbx+学号_pro_sql”概要文件的资源名称和资源值等信息。
③利用SQL*Plus或PL/SQL Developer，从查看“ygbx+学号_pro_sql”概要文件中锁定天数的值。
3修改概要文件。
②利用企业管理器，修改“ygbx+学号_pro”概要文件，将CPU/会话改为4000，连接时间为60。
②利用SQL*Plus或PL/SQL Developer，修改“ygbx+学号_pro_sql”概要文件，将并行会话设为20，读取数/会话设为DEFAULT。
4创建用户。
①利用企业管理器，创建“ygbxuser+学号”用户，密码为“user+学号”，默认表空间为“ygbx_tbs”。
②利用SQL*Plus或PL/SQL Developer，创建“ygbxuser+学号_sql”用户，密码为“user+学号+sql”，该用户处于锁状态。
③利用SQL Plus或PL/SQL Developer，将“ygbx+学号_pro”概要文件赋予“ygbxuser+学号”用户。
④利用SQL Plus或PL/SQL Developer，将“ygbx+学号_pro_sql”概要文件赋予“ygbxuser+学号_sql”用户。
5 查看用户。
②利用企业管理器，查看“ygbxuser+学号”用户的信息。
②利用SQL*Plus或PL/SQL Developer，查看“ygbxuser+学号_sql”用户的信息，并查看该用户验证的方式。
③利用SQL*Plus或PL/SQL Developer，从DBA_USERS数据字典中查看“ygbxuser+学号_sql”用户的默认表空间和临时表空间的信息。
6修改用户。
②利用企业管理器，修改“ygbxuser+学号”用户，验证方式为外部。
②利用SQL*Plus或PL/SQL Developer，修改“ygbxuser+学号_sql”用户，将
该用户解锁，并将密码改为“sql+学号+user”。
7权限管理。
①利用企业管理器，授予“ygbxuser+学号”用户“CREATE ANY TABLE”、“CREATE ANY INDEX”、“ALTER ANY TABLE”、“ALTER ANY INDEX”、“DROP ANY TABLE”和“DROP ANY INDEX”系统权限。
②利用SQL*Plus或PL/SQL Developer，授予“ygbxuser+学号_sql”用户“SYSOPER”系统权限。
③利用企业管理器，将“ygbxuser+学号”用户增加到“SYSTEM”方案中对“help”表的查看、修改、删除等对象权限。
④利用SQL*Plus或PL/SQL Developer，收回“ygbxuser+学号_sql”用户在“SYSTEM”方案中对“help”表的查看、修改、删除等对象权限。
④利用SQL*Plus或PL/SQL Developer，收回“ygbxuser+学号_sql”用户的“SYSOPER”系统权限。
8创建角色。
①利用企业管理器，创建“ygbxrole+学号”角色，赋予该角色能对表、索引、存储过程、序列、同义词进行基本操作的权限。
②利用SQL*Plus或PL/SQL Developer，创建“ygbxrole+学号_sql”角色，该角色具有“SYSDBA”系统权限，并将该角色赋予“ygbxuser+学号_sql”用户。
9查看角色。
②利用企业管理器，查看“ygbxrole+学号”角色所具有的所有权限。
②利用SQL*Plus或PL/SQL Developer，查看“ygbxrole+学号_sql”角色所具有的所有权限。
10 修改角色。
①利用企业管理器，修改“ygbxrole+学号”角色，增加对角色的基本操作，并收回存储过程和序列的操作权限。
②利用SQL*Plus或PL/SQL Developer，修改“ygbxrole+学号_sql”角色，收回“SYSDBA”系统，而授予“SELECT ANY TABLE”系统权限。
11 删除角色。
②利用企业管理器，删除“ygbxrole+学号”角色。
②利用SQL*Plus或PL/SQL Developer，删除“ygbxrole+学号_sql”角色。
12 删除概要文件。
②利用企业管理器，删除“ygbx+学号_pro”概要文件，查看“ygbxuser+学号”用户的概要文件。
②利用SQL*Plus或PL/SQL Developer，删除“ygbx+学号_pro_sql”概要文件，查看“ygbxuser+学号_sql”用户的概要文件。
13 删除用户。
①利用企业管理器，删除“ygbxuser+学号”用户。
②利用SQL*Plus或PL/SQL Developer，删除“ygbxuser+学号_sql”用户。
常用系统权限
常用系统权限如表1所示。
常见问题分析
(1) 授权重复的问题。
A用户本身具有了对A表的创建、删除的操作权限，而B用户同时具有对A表的创建、删除的操作权限。这时，B用户授予A用户对A表的创建、删除的操作权限时，系统不报重复授权的错误。
(2) 收回系统权限的问题。
当A用户授权B用户对A表的操作系统权限，B用户又授予C用户对A表的操作系统权限时，如果A用户收回B用户对A表的操作系统权限，那么C用户对A 表的操作系统权限不会被级联收回。
(3) 收回对象权限的问题。
当A用户授权B用户对A对象的操作对象权限，B用户又授予C用户对A对象的操作对象权限时，如果A用户收回B用户对A对象的操作对象权限，那么C用户对A表的操作对象权限会被级联收回。
信息系统用户帐号与角色权限管理流程 一、目的 碧桂园的信息系统已经在集团下下各公司推广应用，为了确保公司各应用信息系统安全、有序、稳定运行，我们需要对应用信息系统用户帐号和用户权限申请与审批进行规范化管理,特制定本管理规定。 二、适用范围 适用于公司应用信息系统和信息服务，包括ERP系统、协同办公系统、各类业务应用系统、电子邮箱及互联网服务、数据管理平台等。 三、术语和定义 用户：被授权使用或负责维护应用信息系统的人员。 用户帐号：在应用信息系统中设置与保存、用于授予用户合法登陆和使用应用信息系统等权限的用户信息，包括用户名、密码以及用户真实姓名、单位、联系方式等基本信息内容。 权限：允许用户操作应用信息系统中某功能点或功能点集合的权力范围。 角色：应用信息系统中用于描述用户权限特征的权限类别名称。 四、用户管理 （一）用户分类 1.系统管理员：系统管理员主要负责应用信息系统中的系统参数配置，用户帐号开通与维护管理、设定角 色与权限关系，维护公司组织机构代码和物品编码等基础资料。 2.普通用户：指由系统管理员在应用信息系统中创建并授权的非系统管理员类用户，拥有在被授权范围内 登陆和使用应用信息系统的权限。 （二）用户角色与权限关系 1.应用信息系统中对用户操作权限的控制是通过建立一套角色与权限对应关系，对用户帐号授予某个角色 或多个角色的组合来实现的，一个角色对应一定的权限（即应用信息系统中允许操作某功能点或功能点 集合的权力），一个用户帐号可通过被授予多个角色而获得多种操作权限。 2.由于不同的应用信息系统在具体的功能点设计和搭配使用上各不相同，因此对角色的设置以及同样的角 色在不同应用信息系统中所匹配的具体权限范围可能存在差异，所以每个应用信息系统都需要在遵循《应 用信息系统角色与权限设置规范》基础上，分别制定适用于本系统的《碧桂园应用信息系统角色与权限
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中列出了某文档管理项目中权限管理的一部分设计表。从中我们可以清晰的区别出这三个对象以及它们的各自作用。
角色权限模块说明 一、何为权限 通常登录一个系统在页面左边部分能看到相关操作菜单，鼠标点击相应菜单会进入相关操作页面，页面里面展示当前登录用户能查看的相关数据及对数据可进行的操作按钮；通过以上描述，我们可以用相对专业点的术语描述：当前登录用户有该菜单功能的操作权限，并且该用户只能查看自己拥有权限查看的数据，数据的操作按钮也可能不是全部操作按钮，比如可以新增但是不可以删除，而管理员登录后进入该页面这可以看到删除按钮并且可以进行删除操作等；以上文字描述了菜单权限，数据权限，按钮权限等三种权限概念； 二、何为角色 如果管理员为系统每个用户各自选择可以操作的权限，这样不仅效率低下而且用户体验相当不好，每新建一个用户就要为该用户单独选择可操作的权限，即使该用户的权限和之前的用户是一模一样的可还是要重新选择，有没有好的解决方案呢？我们可以将权限相似的用户所拥有的权限进行分组，将用户加入该分组，那么用户就拥有该分组里面的权限，分组名称就是角色，这样只要我们为用户分配相应的角色该用户就一次性的获得了多个可操作的权限。 三、权限分配 通常角色拥有的权限及用户所属的角色会根据需求进行变化，比如部门重组或者人员调离，该部门人员的职责不同了，那么其拥有的权限和所属角色也会发生相应的变化，通常管理员会根据实际情况新增或取消某个角色拥有的权限或者新建新的角色亦或者删除过期的角色等，这些操作我们称之为权限分配。 四、新系统权限管理说明 新系统后台权限分为三种即菜单权限，数据权限，按钮权限。新系统默认有个超级管理员角色(superadmin)及该角色下用户名为superadmin的用户，该角色默认拥有系统全部资源的操作权限(新功能开发时由开发人员进行配置)，并且在权限分配时只有该角色里面的用户才能看到所有权限并对其进行分配，其他任何角色里面的用户都不能对其进行修改和重新分配权限，该角色仅限公司内部开发人员，维护人员及测试人员使用，其中菜单管理，系统配置管理，定时器配置管理，系统词典管理，demo功能原型等功能为该角色独有的权限(业务逻辑上如此规定，如超级管理员将这些权限分配给其他角色则其他角色里面的用户也是可以对其进行操作的)。 超级系统管理员可以创建其他的角色，创建角色时分配该角色拥有的权限，如果将权限分配权限也分配给新角色，那么新角色在创建其他新角色并对其进行权限分配时只能看到自
对EMS权限管理模块设计 1.权限设计概述 1.1引言 随着Web 服务的复杂度增加以及用户数量和种类的增多，安全问题在理论及工程上都 是一个必须考虑的问题，而权限管理是安全问题中一个很重要的方面。因此本文针对权限做 了一个分析。 权限可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的 逻辑表达式是否为真。 1.2意义 ?用户管理及权限管理一直是应用系统中不可缺少的一个部分 ?系统用户很多，系统功能也很多 ?不同用户对系统功能的需求不同 ?出于安全等考虑，关键的、重要的系统功能需限制部分用户的使用 ?出于方便性考虑，系统功能需要根据不同的用户而定制 1.3目标 直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要， 除了功能的必须，更主要的就是因为它足够直观。 简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解 决所有的权限问题是不现实的。设计中将变化的“定制”特点比较强的部分判断为业务逻辑， 而将相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。 扩展，采用可继承的方式解决了权限在扩展上的困难。引进Group概念在支持权限以组 方式定义的同时有效避免了权限的重复定义。 2.基于角色的权限管理设计（Role-Based Access Control,RBAC）2.1权限管理用例图
2.2用例图描述 超级管理员：系统中默认的角色，它是系统中拥有最高权限的角色，它不仅能够管理其他的管理员和用户，而且还可以对系统中每个模块的任一功能进行操作、维护。 普通管理员：它是由超级管理员创建的，并授予权限，它能够管理系统部分的功能，它可以查看所有普通管理员、普通用户的信息，它只能对由它自己创建的用户进行编辑、删除操作，和管理拥有权限的模块。 普通用户：它是系统中最低权限的角色，它只能对自己拥有的权限进行操作，一般情况下，它的权限是对信息的浏览和对自己信息的录入，修改。 登陆系统：根据用户拥有的权限不同，用户所能操作的功能多少就不同，所以在登陆系统的时候就要对用户的权限进行判断。
实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。 就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 我们先来分析一下数据库结构： 首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：
系统设置说明书 系统设置包括基础配置和流程配置，点击主菜单的系统设置，点击左菜单的基础配置 1、添加部门和删除部门 点击主菜单的系统设置---点击左菜单的基础配置---点击做菜单的人事管理，在中间的组织部门上弹鼠标右键，选择新增下级部门，出现的编辑页面如下： 在这里，部门名称和部门编码为必填字段，用蓝色标识。 如果你想删除部门，点击主菜单的系统设置---点击左菜单的基础配置---点击左菜单的人事管理，在需删除的部门上弹鼠标右键，选择删除当前部门，点击确定即可。
2、添加人员 左击主菜单的系统配置-----左击左菜单的基础配置---点击人事管理-----选择部门-----在人员信息维护栏点新增，出现的页面如下：
用户代号（即用户登陆的账号）和姓名为蓝色，必填，同时用户代号至少为3个以上字母或数字。建议在维护人员基本资料时，尽可能填写详细，特别是手机号、email、办公电话、QQ，这样为以后的消息通知提供方便。点击保存后，出现页面如下： 保存后，用户的初始化密码和用户代号相同。 如果人员发生调动，比如从一个部门调到另一部门，双击部门输入框，弹出的页面如下：
选择他现在的新部门，点击“确定”即可 3、给新增的人员配权限 1、先配置基本的权限 左击主菜单的系统配置-----左击左菜单的基础配置---点击角色权限管理-在角色下点击一般用户 在人员信息下点新增，选择刚才添加的人员------点确定。这时该用户有了基本的权限，可以进入系统浏览各模块。 3、配置不走流程的模块的权限
比如设备台帐， 点击左菜单的基础配置---点击角色权限管理-----在角色下找到设备台帐管理人员，点击它----在人员信息下点新增---在弹出的人员选择页面中选择部门-----选择人员-----点确定. 注意设备台帐有一点不同，他还需要配置每个部门可以管理哪些设备 点击主菜单的设备管理----点击部门所辖位置，点击需要配权限的部门，点击新增弹出选择位置的页面， 勾选位置后，点确定，提示：
实现业务系统中的用户权限管理--设计篇 B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便 的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致 的人员编入同一组，然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套 管理系统，就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统 之间，功能权限是可以重用的，而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 我们先来分析一下数据库结构： 首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图：
admin超级管理员的意思 简单的说：Admin是Administrator的简写形式，其中文意思就是“系统管理员”。 Admin与账套主管的区别 ADMIN是系统初始化时默认的用户，可以增加、修改、删除操作员及员工档案等基础数据维护，建立账套管用户为各用户授权、还有对同步打印模块的设置和维护，但不可以查询报表等操作账套主管的权限最大，拥有ADMIN的所有权限（除同步打印模块维护指定ADMIN外）、日常业务、基础数据维护、报表查询等 admin 是系统初始化时默认的用户 可以登陆软件的系统管理中增加、修改、删除操作员及员工档案等基础数据维护建立新的账套，指定操作员为某账套的账套主管 为新账套操作员用户授权 备份、恢复已存在所有的账套数据，清除异常任务 admin不参与具体的账务日常业务操作，只在系统管理中使用 账套主管 针对某个账套的权限最大，拥有账套操作的所有权限、日常业务、基础数据维护、 报表查询等 登陆系统管理可以对操作员授权 做年度账套新建、结转年初数 2010-04-13 08:34
用友软件系统管理员admin和账套主管的权限区别 系统管理员admin和账套主管的权限区别2009年07月18日星期六14:54 用友软件系统管理员admin和账套主管的权限区别 从前面的介绍中，可以看到在系统管理中，有些操作需要系统管理员admin来注册，而有些操作需要账套主管来登陆。现在就把这两个操作员的权限区别列示如下： 功能操作员建立账套备份、恢复账套角色操作用户操作权限操作修改账套清除异常任务和单据锁定年度账管理结转上年数据系统管理员admin 系统管理概述 用友ERP-U8软件产品是由多个产品组成，各个产品之间相互联系、数据共享，完全实现财务业务一体化的管理。对于企业资金流、物流、信息流的统一管理提供了有效的方法和工具。系统管理包括新建账套、新建年度账、账套修改和删除、账套备份，根据企业经营管理中的不同岗位职能建立不同角色，新建操作员和权限的分配等功能。系统管理的使用者为企业的信息管理人员：系统管理员Admin、安全管理员admin、管理员用户和账套主管。 系统管理模块主要能够实现如下功能： ?对账套的统一管理，包括建立、修改、引入和输出(恢复备份和备份)。 ?对操作员及其功能权限实行统一管理，设立统一的安全机制，包括用户、角色和权限设置。 ?允许设置自动备份计划，系统根据这些设置定期进行自动备份处理，实现账套的自动备份。 ?对年度账的管理，包括建立、引入、输出年度账，结转上年数据，清空年度数据。 ?对系统任务的管理，包括查看当前运行任务、清除指定任务、清退站点等。
应用系统的角色、权限分配管理制度 第一条、用户权限管理 一、用户类型 1．系统管理员： 为应用系统建立账号及分配权限的用户 2．高级用户： 具有对应用系统内的数据进行查询和修改的用户 3．普通用户： 只对系统内数据有查询功能的用户 二、用户建立 1．建立的原则 （1）不同类型用户的建立应遵循满足其工作需要的原则，而用户的权限分配则应以保障数据直报的高效、准确、安全为原则。 （2）用户的权限分配应尽量使用系统提供的角色划分。如需特殊的操作权限，应在准确理解其各项操作内容的基础上，尽量避免和减少权限相互抵触、交叉及嵌套情况的发生，经调试成功后，再创建相应的角色赋予本级用户或直报用户。 （3）通过对用户进行角色划分，分配报告用户权限，合理限制对个案数据的修改权限，将数据报告与数据利用剥离，即原始数据报告与统计加工后信息利用分开。 （4）系统内所有涉及报告数据的帐户信息均必须采用真实信息，即
实名制登记。 2．建立的程序 （1）用户申请 可由使用部门使用人填写应用系统用户申请表，经单位领导签字批准后，向本单位负责应用的相关部门提出申请。 （2）用户创建 负责应用系统的相关部门在收到用户申请表后，系统管理员根据用户申请的内容和实际的工作范围，为其建立用户帐号并授予相应的角色，再填写用户申请回执表，经部门主管领导签字批准后，反馈给申请单位。 创建用户的步骤：①建立用户帐号；②创建角色；③为角色配置权限； ④将角色授予用户。 第二条、用户安全 一、系统安全 1.用户必须遵守国家法律、单位规章制度，不得参加任何非法组织和发布任何反动言论；严守单位机密，不得对外散布、传播本系统内部信息；不得有诋毁、诽谤、破坏本系统声誉的行为。 2.用户必须按“传染病监测信息应用工作与技术指南”对系统进行操作，尽量做到专人、专机运行使用本系统，并避免使用公共场所（如网吧）的计算机使用应用系统。 3.用户应在运行本系统的计算机上安装杀毒软件、防火墙，定期杀毒；禁止在运行本系统的计算机上安装、运行含有病毒、恶意代码、木马
用户管理模块设计 用户管理模块提供对用户信息的管理，包括用户注册、用户登录、用户权限管理、用户信息修改以及用户等级修改。 1、用户注册 根据用户表，设计相应的注册页面，注册页面包括用户名、密码、邮箱、部门、电话等信息，当用户进行注册时，填写这些信息，用户名是不能与已注册的用户名相同，填写完成后，提交注册请求，后台相应的Action会响应该动作，首先获取到页面发来的参数，然后将这些参数通过Session 对象写入到数据库中，最后向用户提示注册成功与否。 2、用户登录 用户注册之后，就可以通过账户和密码登陆至平台。当用户提交登陆请求，后台相应的Action 会响应该动作，首先获取到页面发来的用户名和密码，然后通过Query对象查询该用户是否存在且密码正确，最后将根据结果给用户发送跳转页面，如果用户存在且密码正确，则可进入平台主页面，否则，提示登陆错误信息。 3、用户权限管理 用户权限管理将用户分为普通用户和管理员，他们具有不同的权限，他们各自的权限如表1所示。此平台首次使用时，会内置一个超级管理员，有修改用户等级的权限。 表1 不同用户权限授权
定义一个权限拦截器，它的功能是用来检验用户类型，对每一个需要管理权限的操作均进行拦截，同时检验用户类型，判断该用户类型是否可执行该操作，即可达到权限管理的作用。如果某操作在当前用户等级对应的操作范围内，则可正常访问，否则跳转到提示页面，提示用户权限不足。 4、用户信息修改 用户管理模块提供用户修改自己信息的功能。当进入信息修改界面，首先会获取Session中当前用户信息，供用户在当前信息基础上进行信息修改。当用户填写完修改信息，并发送修改请求后，后台将响应用户的请求，首先得到所有用户修改参数，然后将修改的信息设置到该对象中，最后更新数据库，将更新结果发送给用户。 青山埋白骨，绿水吊忠魂。
OA系统权限管理设计方案7 OA系统权限管理设计方案 数据库2010-02-2310:09:25阅读13评论0字号：大中小 OA系统权限管理设计方案 l不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 l可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 l权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 l满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 针对OA系统的特点，权限说明： 权限
在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有4种方式(参考飞思办公系统) A.通过职位 a)在职位中，职位成员的权限继承当前所在职位的权限，对
OA系统权限管理设计方案 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的 功能。 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组” 进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进 行重新开发。 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源 权限则不能。 针对OA系统的特点，权限说明： 权限 在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中， 用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。
一个用户权限管理模块的设计思路： 1. 权限资源（功能资源） 系统的所有权限信息。权限具有上下级关系，是一个树状的结构。如下： 系统管理 单位管理 查看单位 添加单位 修改单位 删除单位 部门管理 查看部门 添加部门 修改单位 删除单位 对于每个权限，又存在两种情况：1可访问；2可授权，部分表中采用拥有类型做判断(0可访问，1即可访问也可授权) 2. 用户 系统的具体操作者，用户可以自己拥有权限信息，可以归属于0～n个角色，可属于0～n 个组。他的权限集是自身具有的权限+所属的各角色具有的权限+所属的各组具有的权限的合集。它与权限、角色、组之间的关系都是n对n的关系。 3. 角色 为了对拥有相似权限的用户进行分类管理，因此定义角色，例如：超级管理员，一般管理员、一般用户等角色。在这里同时也让角色具有上下级关系，形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。 4. 组 为了更好地管理用户，对用户进行分组归类，简称为用户分组。组也具有上下级关系，可以形成树状视图。在实际应用中，我们知道，组也可以具有自己的角色信息、权限信息。 就好比是javaeye中的圈子，一个圈子可以拥有多个会员，同时一个会员也可以加入多个圈子，对于不同的圈子又有不同的权限信息。(组的解释：例如一个公司中，不同的部门即可划分不同的组来进行权限的分配) 针对以上描述，结构关系如下： 整个模块分为组权限管理、角色权限管理、用户权限管理。 其中组权限管理：组权限 = 所属角色的权限合集 + 组自身的权限。
角色权限管理：角色权限 = 角色自身权限。 用户权限管理：用户权限 = 所属角色权限合集 + 所属组权限合集 + 用户自身权限。 注意：因为组和角色都具有上下级关系，所以下级的组或角色的权限只能在自己的直属上级的权限中选择，下级的组或者角色的总的权限都不能大于直属上级的总权限。 欢迎大家拍砖，给点建议。
XX医院 应用信息系统用户帐号与角色权限管理办法 （讨论版） 新津县妇幼保健院信息科 二○一五年四月
目录 1 目的 (3) 2 适用范围 (3) 3 术语和定义 (3) 4 用户管理 (3) 4.1用户分级 (3) 4.2用户分类 (3) 4.3用户角色与权限关系 (4) 4.4用户帐号实名制注册管理 (5) 5 用户帐号申请与审批 (8) 5.1帐号申请 (8) 5.2帐号审批和开通 (8) 6 安全管理 (8) 6.1帐号安全 (8) 6.2密码安全 (9) 6.3信息安全 (9) 7 档案管理 (9) 附表1 应用信息系统角色与权限关系对照表（表样） (10) 附表2 用户帐号申请单 (12) 附表3 用户帐号批量申请单 (13) 附表4 用户帐号管理工作登记表 (15)
1目的 为加强新津县妇幼保健院信息科计算机中心（以下简称：中心）应用信息系统用户帐号和用户权限申请与审批的规范化管理, 确保中心各应用信息系统安全、有序、稳定运行，特制定本管理办法。 2适用范围 适用于中心开发、建设和管理的各项应用信息系统，包括HIS系统、EMR系统、LIS系统、PACS 系统、医保接口系统、网络直报系统、网站门户等管理系统。 3术语和定义 用户：被授权使用或负责维护应用信息系统的人员。 用户帐号：在应用信息系统中设置与保存、用于授予用户合法登陆和使用应用信息系统等权限的用户信息，包括用户名、密码以及用户真实姓名、科室、职务或职称等基本信息内容。 权限：允许用户操作应用信息系统中某功能点或功能点集合的权力范围。 角色：应用信息系统中用于描述用户权限特征的权限类别名称。 4用户管理 4.1用户分级 中心各应用信息系统的用户根据各相关业务的信息管理工作要求，涉及行政、后勤、临床、医院门户四个方面。因此中心应用信息系统用户分为4个类（级）别，即：院领导级、部门负责人级、职能部门管理人员级、医师护士职称分级。 4.2用户分类 4.2.1系统管理员 系统管理员主要负责应用信息系统中的系统参数配置，用户帐号开通与维护管理、设定角色与权限关系，维护科室、项目等数据字典，系统日志管理以及数据管理等系统运行维护工作。 按照上述用户分级，系统管理员分为一级系统管理员、二级系统管理员二个等级，分别相应的应用信息系统日常运行维护管理工作。不同等级的系统管理员拥有不同等级的系统管理权限，当在一个应用信息系统中存在两个等级的系统管理员时，上级系统管理员对下级系统管理员拥有授权和监督管
1.1.1 权限管理 1、用户(User)可以拥有多个角色(Role)，角色可以被分配给多个用户 2、权限的意思就是对某个资源的某个操作，现在规定： a) 所谓资源，即系统的模块 b) 所谓操作，包括：增加、删除、修改、查询等操作 3、权限管理系统的总体功能分为：授权与认证 4、授权，指将权限授予角色或用户 a) 如果用户A拥有角色B、角色C，那么，缺省的情况下，用户A将拥有被分配给角色 A和角色C的所有权限（即默认情况下，用户A继承其拥有的角色所具有的所有权限） b) 如果用户拥有多个角色，那么用户的权限是这些角色权限的合集 c) 如果用户拥有多个角色，而且角色之间的授权有冲突（比如对同一个资源的同一个操 作，一个角色为“允许”，另外一个角色为“不允许”），将以优先级别高的角色为 准（所谓优先级别，也就是对于这个用户所拥有的角色而言，是有顺序的，同一个角 色在不同的用户那里可能拥有不同的优先级） d) 除了可以对角色进行授权外，也可以针对用户进行授权，也就是说，将权限授予用户。 针对某个资源的所有操作，我们可以设置这些权限对用户来说是“继承”或“不继承” i. 继承：意思是这些权限将使用其（即用户）所拥有的角色的权限，而不使用其（即 用户）单独设置的权限 ii. 不继承：意思是这些权限将使用其单独设置的权限，而不使用其所拥有的角色的权限 5、认证，指用户访问资源的某些操作时，根据授权，判断是否允许用户的访问 a) 在用户访问的时候，需要进行即时的判断（是否有权访问） b) 应该提供查询的功能，可以查询某个用户所拥有的所有权限 总体上，可分为模块管理、角色管理和用户管理模块： 模块管理： 模块管理主界面参考：
软件需求分析报告目录 1．引言 1.1 项目简介 本文档对通用用户权限管理系统的总体设计、接口设计、界面总体设计、数据结构设计、系统出错处理设计以及系统安全数据进行了说明。 1.2 编写说明 1．3参考资料 《通用权限管理系统需求规格说明书》 《通用权限管理系统数据库设计说明书》
2．目标 2.1概述 权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。 本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。2.2系统目标 系统的目标包括如下三点： （1）对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控； （2）完善用户、角色、组织、资源、操作的管理功能，其中的组织管理模块只提供组织视图，不参与权限的控制管理。 （3）开发人员开发新的系统功能，通过资源和角色模块进行操作管理。使用系统管理员身份登陆，直接将访问路径作对角色资源授权给操作，实现资源访问控制管理。 2.2.1 总目标 本系统提供一个调用简单、可复用性高、满足一般需求的权限管理模块，并为需要对权限管理的系统节省开发本。 2.2.2 性能目标 1、要求下载和安装速度快，响应时间快。
2、要求系统可适用于不同操作平台。 3、要求系统的可维护性和实用性强。 4、要求系统有一定的检错能力。 5、要求系统支持多用户同时操作，但管理者与用户不能同时操作。 2.2.3 功能目标 本系统的设计目标是对应用系统的所有资源进行权限控制，比如应用系统的功能菜单、各个界面的按钮控件等进行权限的操控。 2.3 目标说明 3.结构 3.1系统需求结构 系统采用B/S架构模式，基于 BNFW开发，服务封装了对后台数据操纵的细节，并提供安全调用接口. WEB 应用程序通过接口访问系统服务，执行用户操作并返回结果。系统采用SQL SERVER数据库和tomcat web应用服务器开发，部署在 Linux和windows服务器下运行。 3.2 需求结构的说明 用户权限管理系统概貌如图所示：
OA权限管理设计的实现 任何系统都离不开权限的管理,有一个好的权限管理模块,不仅使我们的系统操作自如,管理方便,也为系统添加亮点。 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 针对OA系统的特点，权限说明： 权限 在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有4种方式(参考飞思办公系统) A.通过职位 a)在职位中，职位成员的权限继承当前所在职位的权限，对于下级职位拥有的权限 不可继承。
扩展RBAC用户角色权限设计方案 RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如下图） 角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可
管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个角色赋予该用户。 当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有多个用户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系）
在应用系统中，权限表现成什么？对功能模块的操作，对上传文件的删改，菜单的访问，甚至页面上某个按钮、某个图片的可见性控制，都可属于权限的范畴。有些权限设计，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。而在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性。（见下图）
请留意权限表中有一列“权限类型”，我们根据它的取值来区分是哪一类权限，如“MENU”表示菜单的访问权限、“OPERATION”表示功能模块的操作权限、“FILE”表示文件的修改权限、“ELEMENT”表示页面元素的可见性控制等。 这样设计的好处有二。其一，不需要区分哪些是权限操作，哪些是资源，（实际上，有时候也不好区分，如菜单，把它理解为资源呢还是功能模块权限呢？）。其二，方便扩展，当系统要对新的东西进行权限控制时，我只需要建立一个新的关联表“权限XX关联表”，并确定这类权限的权限类型字符串。 这里要注意的是，权限表与权限菜单关联表、权限菜单关联表与菜单表都是一对一的关系。（文件、页面权限点、功能操作等同理）。也就是每添加一个菜单，就得同时往这三个表中各插入一条记录。这样，可以不需要权限菜单关联表，让权限表与菜单表直接关联，此时，须在权限表中新增一列用来保存菜单的ID，权限表通过“权限类型”和这个ID来区分是种类型下的哪条记录。 到这里，RBAC权限模型的扩展模型的完整设计图如下：
角色管理 主要功能 1.1添加角色信息 定义角色基本信息：角色名称，状态，角色描述 Action: 方法名：addRoleInfo() 返回值：String（Success/Error） 参数：无 方法功能：对界面传过来的RoleInfoDTO进行空值判断，如果非空，做RoleInfoDTO 和RoleInfo的相互转换，并调用RoleService中的saveRoleInfo（RoleInfo ri）方法； 如果为空，给出错误提示。 备注：在添加完角色名称后应该先检查是否有重名的角色，调用的Action是 findRoleBByName，如果有给出提示并制空名称重新填入。 Service： 方法名：saveRoleInfo（RoleInfo ri） 返回值：boolean 参数：RoleInfo对象 方法功能：调用RoleInfoDAO中的save（RoleInfo ri）方法。 1.2删除角色信息 根据角色ID删除一条角色信息 Action: 方法名：removeRoleById() 返回值：String(Success/Error) 参数：无 方法功能：对界面传过来的RoleInfoDTO.rid进行空值判断，如果非空，调用 RoleService中的removeRoleById(String rid)方法;如果为空，给出错误提示。 Service: 方法名：removeRoleById(String rid) 返回值：boolean 参数：rid(角色rid) 方法功能：修改RoleInfo的rstatus为“废弃”，调用RoleInfoDAO中的updateRoleById(RoleInfo ri)方法。 1.3编辑（修改）角色信息 根据角色ID修改一条角色信息 Action: 方法名：editRoleById() 返回值：String(Success/Error) 参数：无 方法功能：对界面传过来的RoleInfoDTO对象进行空值判断，如果非空，做 RoleInfoDTO和RoleInfo的相互转换，调用RoleService中的editRoleById(String rid) 方法;如果为空，给出错误提示。 Service: