用户·角色·权限·表
一．引言java
由于作过的一些系统的权限管理的功能虽然在逐步完善，但总有些不尽人意的地方，总想抽个时间来更好的思考一下权限系统的设计。web
权限系统一直以来是咱们应用系统不可缺乏的一个部分，若每一个应用系统都从新对系统的权限进行设计，以知足不一样系统用户的需求，将会浪费咱们很多宝贵时间，因此花时间来设计一个相对通用的权限系统是颇有意义的。数据库
二．设计目标安全
设计一个灵活、通用、方便的权限管理系统。网络
在这个系统中，咱们须要对系统的全部资源进行权限控制，那么系统中的资源包括哪些呢？咱们能够把这些资源简单归纳为静态资源（功能操做、数据列）和动态资源（数据），也分别称为对象资源和数据资源，后者是咱们在系统设计与实现中的叫法。数据结构
系统的目标就是对应用系统的全部对象资源和数据资源进行权限控制，好比应用系统的功能菜单、各个界面的按钮、数据显示的列以及各类行级数据进行权限的操控。socket
三．相关对象及其关系数据库设计
大概理清了一下权限系统的相关概念，以下所示：工具
1. 权限学习
系统的全部权限信息。权限具备上下级关系，是一个树状的结构。下面来看一个例子
系统管理
用户管理
查看用户
新增用户
修改用户
删除用户
对于上面的每一个权限，又存在两种状况，一个是只是可访问，另外一种是可受权，例如对于“查看用户”这个权限，若是用户只被授予“可访问”，那么他就不能将他所具备的这个权限分配给其余人。
2. 用户
应用系统的具体操做者，用户能够本身拥有权限信息，能够归属于0～n个角色，可属于0～n个组。他的权限集是自身具备的权限、所属的各角色具备的权限、所属的各组具备的权限的合集。它与权限、角色、组之间的关系都是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) |
|
|
电子邮箱 |
|
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 null（0:可访问，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 null（0:可访问，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 null（0:可访问，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. 用户
应用系统的具体操做者，用户能够本身拥有权限信息，能够归属于0～n个角色，可属于0～n个组。他的权限集是自身具备的权限、所属的各角色具备的权限、所属的各组具备的权限的合集。它与权限、角色、组之间的关系都是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进行加密。