“用户在线注册系统”的用户模块功能设计与实现
实训二十一“用户在线注册系统”用户模块功能的设计与实现
实训目的：
1．分析用户在线注册系统的用户模块功能的分析与设计；
2．实现用户在线注册系统的用户模块的用户注册、用户登录、用户信息查看及修改等功能。
实训设备：
1．P4以上微机30台，不进行分组。
2．计算机配置：操作系统WindowsXP/2000、Tomcat6.0服务器、JDK1.6、MySQL数据库、Eclipse 工具等相关软件。
实训步骤：
正确启动计算机，在磁盘E区建立以学号和姓名为文件夹，从指定的共享文件夹中将“实习指导书”和其他内容复制到建立的文件夹中。
用户在线注册系统
——用户模块功能的设计与实现
1用户注册
(1) 界面：
图1 用户注册界面
(2) 界面核心代码register.jsp
(3) 创建RegisterAction-validation.xml 验证文件
在users.action 包中创建，主要对界面文本框相关信息合法性的验证（见提供附件参考） ◆ 用户名username ：必须填写，并且长度必须在4到20之间； ◆ 密码password 属性：必须填写，并且长度必须在6到25之间； ◆ 姓名name 属性：必须填写；
◆昵称nic属性：必须填写，并且长度必须在6到25之间；
◆性别sex属性：必须填写；
◆年龄age属性：必须填写，并且必须在16到50岁之间；
注意：验证文件的版本信息及部分验证规则见提供的RegisterAction-validation.xml，主要用requiredstring、regex /expression、int分别来验证不能为空、输入长度是否符合、是否为数字等，用
(4) 创建RegisterAction.java文件
◆实现ActionSupport类，声明用户填写的属性(包括username、password、name、nic、sex、age、email、phone、selfshow、tip)，生成相应的get和set方法；
◆设置register()方法，作用是调用UserDAO类中的findUsers()方法从数据库中检索用户名是否存在，若存在则返回注册页面，并提示用户存在；
register()代码：(完成后此时会出错？)
◆若不存在则实例化用户实体类Users，然后设置用户的基本信息，调用save()方法传入users对象，将用户的基本人信息插入到数据库reg中的users表。
◆创建Users.java，声明用户填写的属性(包括id、username、password、name、nic、sex、age、email、phone、selfshow)，生成相应的get和set方法；
(5) 创建UsersDAO.java类(重点、难点)
在users.dao包中创建UsersDAO.java
◆findUsers()方法
作用：查找用户名是否存；
分析：该方法用传递的用户名username作为SQL语名的判断条件，查找数据库中用户名是否存在，若存在，rs.next()方法向下执行，flag属性等于true，然后返回flag属性值，并在Action中进行判断。findUsers代码：
◆save()方法
作用：将用户的基本人信息插入到数据库reg中的users表；
分析：调用DatabaseDAO.getConnection()获取数据库连接对象con，然后预编译SQL语名，用users对象来依次设置SQL语句中？号的参数，再调用executeUpdate()方法执行SQL语句，最后关闭数据库连接。
Save()代码：
(6) 配置struts.xml文件
主要完成用启注册成功和不成功的视图结果：
测试：http://localhost:8080/RegSys/register.jsp
2 用户登录
用户登录页面是进入系统的唯一窗口，在login.jsp页面上输入用户名和密码，将数据提交到LoginAction.java中，再调用UsersDAO.java中的login()方法处理用户登录请求。
(1) 创建login.jsp页面
◆界面
◆代码：index.jsp
(2) 创建LoginAction.java类
作用：主要用来处理login.jsp页面的登录请求，判断是否登录
分析：该类实现ActionSupport，首先声明帐号username、密码password属性来获取用户的输入(包括相应的get方法set方法)，然后在该类中设置login()方法，将属性放到users对象中，并调用Users中的方法login()进行登录验证，根据返回值flag判断是否登录。
LoginAction类代码：
(3) 在UsersDAO.java类中添加login()方法
作用：实现用户登录验证，并返回一个逻辑值
分析：在UserDAO.java中添加login()方法，用传递的users对象获取帐号和密码，并在SQL语名中做判断条件；若程序能继续执行，表示帐号和密码正确，并设置flag等于true；最后关闭数据连接，返回flag 属性值。
login()代码：
(4) 配置struts.xml文件
测试：http://localhost:8080/RegSys/index.jsp
3 查看所有用户
分析：用户在登录后，在系统中的每个请求和响应都要受到拦截，判断用户是否已登录；主要采用Struts2.0的自定义拦截器实现。
定义一个AuthorityInterceptor拦截器，用来拦截用户是否已登录，若通过拦截器，系统找到FindAllUsersAction.java，并调用UsersDAO.java中的findAllUsers方法获取所有的用户，然后转发到allusers.jsp页面显示所有用户信息。
(1) 创建拦截器类AuthorityInterceptor.java
作用：用来拦截用户是否已登录
分析：在util包中创建，并继承了AbstractInterceptor类，并且重写了intercept()方法，在该方法中首先获取与请求相关的ActionContext类的实例化对象ctx，使用ctx的getSession方法获取session以后，取出保存在session里的帐号，判断帐号是否为空，若不为空，拦截通过并继续执行相应的Action类，若为空，系统将提示需要进行登录。
代码：
(2) struts.xml文件配置AuthorityInterceptor.java拦截器
分析：若让某个Action使用自定拦截器，只需将该Action配置文件和自定义拦截器的配置文件配置在同一包即可。若拦截器拦截通过，系统会FindAllUsersAction.java中处理用户的请求。
name="authority"/> (3) 创建查看所有用户FindAllUsersAction.java 作用：查看/处理获取所有用户的请求(与管理员查看所有用户的控制器是一样的) 分析：该类继承ActionSupport类，其中声明一个type变时用来获取从某一个页面提交过来的值，然后在findAllUsers()方法中实现实例化UsersDAO.java类，获取一个dao对象，调用其findAllUsers()方法并返回List获取所有的用户，将list对象存储在ActionContext里，判断type属性的值是用户还是管理员，最后返回相应的页面。 代码： (4) 在UsersDAO.java类中添加findAllUsers() 作用：获取所有的用户信息 分析：声明了一个list对象，然后执行SQL语句查询用户表中所有用户；在while循环内，每循环一次实例化一个users对象，然后取出数据表中对应的字段数据并且入到users对象中，并将user对象添加到list对象中，最后关闭数据库，返回list对象。 代码： public List findAllUsers() { List list = new ArrayList con = DatabaseDAO.getConnection(); try { pt = con.prepareStatement("select * from users"); Users users; for(rs = pt.executeQuery(); rs.next(); list.add(users)) { users = new Users(); users.setId(rs.getInt(1)); users.setUsername(rs.getString(2)); ... ... } } catch(SQLException e) { e.printStackTrace(); }finally{ DatabaseDAO.closeRs(rs); DatabaseDAO.closePt(pt); DatabaseDAO.closeCon(con); } return list; } (5) struts.xml文件配置FindAllUsersAction.java类 分析：在包users-authority中进行配置，并与拦截器mydefault在同一个包下 (6) 所有用户显示页面allusers.jsp 作用：显示所有用户的信息 分析：页面用Struts2.0的 测试：http://localhost:8080/RegSys/index.jsp 4 修改个人信息 分析： ◆单击“修改个信息”链接，若拦截器通过，系统首先执行SelectInfoAction.java类； ◆在该类中调用UsersDAO.java的selectInfo方法获取用户的详细信息，然后转发到selectinfo.jsp页面输出； ◆若用户修改了个人信息，单击“修改”按钮，数据提交到UpdateAction.java类中，在该类中调用UsersDAO.java的update方法修改到数据库中的个人信息。 (1) 创建SelectInfoAction.java类 作用：获取用户帐号和用户类型 分析：该类继承ActionSupport类，先声明username和type属性，分别用来获取用户帐号和用户类型，然后调用UserDAO.java中selectInfo方法传入username参数，获取用户的对象user，并将用户对象user 存储在session中。因为系统中有多个地方要用到查询用户信息，所以在这里只用了一个Action来查询，用type属性获取每个URL传过来的参数，最后判断转发相应的页面。 代码： (2) 在UsersDAO.java类中添加selectInfo()方法 作用：实施用户信息查询操作 分析：先实例化下一个Users对象users，然后根据username参数去数据库中查找当前用户的详细信息，若rs.next()方法返回值为true，取出数据库中用户的信息到users对象，最后关闭数据库，返回users对象。 代码： (3) 在struts.xml文件中配置SelectInfoAction.java类 (4) 创建显示用户自己的详细信息界面selectinfo.jsp 作用：页面主要使用EL表达式输出用户的详细信息 代码：selectinfo.jsp (5) 创建UpdateAction.java类 作用：获取用户的修改输入的数据 分析：若修改个人信息，需填写新的信息后，单击“修改”按钮，数据将提交到UpdateActin.java类中，该类继承ActionSupport类，类中声明用户的基本信息属性，获取用户的输入数据，实例化一个users对象，设置用户的值，然后调用UsersDAO的update()方法传入users对象，修改数据库中用户的个人信息。 代码： (6) 在UsersDAO.java类中添加update()方法 作用：实现修改后的数据提交到数据库，完成数据的更新 分析：该方法中先声明了一个int变量，然后据根传过来的users对象参数修改数据库中当前用户的信息，最后关闭数据库连接，返回int类型变量。 代码： (7) 在struts.xml文件中配置UpdateAction.java类 测试：http://localhost:8080/RegSys/index.jsp 用户角色权限设计 实现业务系统中的用户权限管理 B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 我们先来分析一下数据库结构： 首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图： 信息系统用户帐号与角色权限管理流程 一、目的 碧桂园的信息系统已经在集团下下各公司推广应用，为了确保公司各应用信息系统安全、有序、稳定运行，我们需要对应用信息系统用户帐号和用户权限申请与审批进行规范化管理,特制定本管理规定。 二、适用范围 适用于公司应用信息系统和信息服务，包括ERP系统、协同办公系统、各类业务应用系统、电子邮箱及互联网服务、数据管理平台等。 三、术语和定义 用户：被授权使用或负责维护应用信息系统的人员。 用户帐号：在应用信息系统中设置与保存、用于授予用户合法登陆和使用应用信息系统等权限的用户信息，包括用户名、密码以及用户真实姓名、单位、联系方式等基本信息内容。 权限：允许用户操作应用信息系统中某功能点或功能点集合的权力范围。 角色：应用信息系统中用于描述用户权限特征的权限类别名称。 四、用户管理 （一）用户分类 1.系统管理员：系统管理员主要负责应用信息系统中的系统参数配置，用户帐号开通与维护管理、设定角 色与权限关系，维护公司组织机构代码和物品编码等基础资料。 2.普通用户：指由系统管理员在应用信息系统中创建并授权的非系统管理员类用户，拥有在被授权范围内 登陆和使用应用信息系统的权限。 （二）用户角色与权限关系 1.应用信息系统中对用户操作权限的控制是通过建立一套角色与权限对应关系，对用户帐号授予某个角色 或多个角色的组合来实现的，一个角色对应一定的权限（即应用信息系统中允许操作某功能点或功能点 集合的权力），一个用户帐号可通过被授予多个角色而获得多种操作权限。 2.由于不同的应用信息系统在具体的功能点设计和搭配使用上各不相同，因此对角色的设置以及同样的角 色在不同应用信息系统中所匹配的具体权限范围可能存在差异，所以每个应用信息系统都需要在遵循《应 用信息系统角色与权限设置规范》基础上，分别制定适用于本系统的《碧桂园应用信息系统角色与权限 关系对照表》（表样见附表1）。具体详细各系统角色与权限关系表以各系统公布为准。 五、用户帐号实名制注册管理 扩展RBAC用户角色权限设计方案 RBAC （Role-Based Access Control ，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。（如下图） 角色是什么？可以理解为一定数量的权限的集合，权限的载体。例如：一个论坛系统，“超级管理员”、“版主”都是角色。版主可 管理版内的帖子、可管理版内的用户等，这些是权限。要给某个用户授予这些权限，不需要直接将权限授予用户，可将“版主”这个 角色赋予该用户。 当用户的数量非常大时，要给系统每个用户逐一授权（授角色），是件非常烦琐的事情。这时，就需要给用户分组，每个用户组内有 多个用用户表 用户ID 範加刖 户。除了可给用户授权外，还可以给用户组授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在用户组拥有的权限之和。（下图为用户组、用户与角色三者的关联关系） 用户亀 用,口?血 IF 用尸廻名称 则G01 敦用户绢茗称imiEEH 用尸角色关联表 SPTB mBER <￡kl> 角色IE ?0EIt <￡k2> 用户组TD2 MJWBER <￡kt> 用 FID2 HUMBER 航开发系统用户账号及权限管理制度 第一章总则 第一条 航开发系统用户的管理包括系统用户ID的命名；用户ID的主数据的建立；用户ID的增加、修改；用户ID的终止；用户密码的修改；用户ID的锁定和解锁；临时用户的管理；应急用户的管理；用户ID的安全管理等。 第二章管理要求 第二条 航开发系统管理员（以下简称系统管理员）在系统中不得任意增加、修改、删除用户ID，必须根据《系统用户账号申请及权限审批表》和相关领导签字审批才能进行相应操作，并将相关文档存档。 第三条 用户ID的持有人特别是共享的用户ID必须保证用户ID和用户密码的保密和安全，不得对外泄漏，防止非此用户ID的所有者登录系统。 第四条 用户管理员要定期检查系统内用户使用情况，防止非法授权用户恶意登录系统，保证系统的安全。 第五条 用户ID持有人要对其在系统内的行为负责，各部门领导要对本部门用户的行为负责。 第六条 用户ID的命名由系统管理员执行，用户ID命名应遵循用户ID的命名规则，不得随意命名。 第七条 用户ID主数据库的建立应保证准确、完整和统一，在用户ID发生改变时，用户管理员应及时保证主数据库的更新，并做好用户ID变更的归档工作。 第八条 对用户申请表等相关文档各申请部门的用户管理员必须存档，不得遗失。 第九条 公司NC-ERP系统中各部门必须明确一名运维管理人员负责本部门用户管理、权限管理及基础数据维护等相关工作。 第三章增加、修改用户ID的管理第十条 公司NC-ERP系统中增加、修改用户ID应符合下列情况之一： 1、因工作需要新增或修改用户ID； 2、用户ID持有人改变； 3、用户ID封存、冻结、解冻； 4、单位或部门合并、分离、撤消； 5、岗位重新设置； 6、其他需要增加或修改公司NC-ERP系统中用户ID的情况。 第十一条 昆明理工大学 信息工程与自动化学院物联网工程专业 2012年级 学生姓名：王永达 毕业设计（论文）题目：拍卖交易系统APP的设计与实现 【毕业设计（论文）主要功能】 1、用户注册模块：任何安装了该APP的用户都可以注册，成为客户； 注册页面需要用户提供真实姓名，密码，邮箱，手机号，性别信息，只有格式核对之后方可注册成功，正式成为可以使用该APP所有功能的客户。 2、客户登录模块：该应用要求客户参与竞拍之前必须先登录系统，以 保证拍卖交易的真实性和可靠性；注册页面需要用户输入手机号，密码进行登录，登录时可以选择记住密码功能方便下次自动登录，登录时需要向后台服务器发起请求，以验证该用户是否真实已注册成为客户，如果未注册过则提示需要先注册才能登录。 3、查看拍卖商品模块：注册用户可以登录成功之后可以查看拍卖中的商品和已拍卖完成的商品；显示拍卖商品界面包括两个Tab(正在拍卖，已结束)，点击之后可展示各自的商品列表。 4、查看拍卖商品详情模块：客户可以选择感兴趣的拍卖商品点击进入 查看拍卖详情和商品的详情，并在该界面展示参与竞拍的入口。 5、参与竞拍模块：当客户点击参与竞拍按钮之后，便跳转到填写竞拍 信息界面(包括竞拍价,收货地址)，竞拍成功之后便能接收到系统的相关提示并受到短信通知。 6、添加拍卖商品模块：客户不仅可以在该应用中参与竞拍，还可以主动发起拍卖信息；在添加拍卖商品界面，需要客户填写商品的相关信息(商品的名称，商品的种类，商品的图片上传，最低起拍价，发货地址)，点击添加按钮，添加成功之后，则跳转到管理拍卖商品界面。 7、管理拍卖商品模块：在模块中客户可以删除或者修改已发布的拍卖信息(注：前提必须是没有人竞拍之前或者竞拍已结束之后) 【毕业设计（论文）主要技术】 1、Android客户端和服务器端的通信时采用JSON 作为数据交互格式。 2、Android客户端底层使用HttpClient和服务器端进行通信。 3、采用Bmob这一开源的云端服务器为移动应用提供所需要数据。 中国免疫规划信息管理系统用户与权限管理规范 一、总则 （一）目的 加强中国免疫规划信息管理系统管理，规范系统用户与权限，保障免疫规划信息管理系统的安全运行，特制定本规范。 （二）依据 《计算机信息系统安全保护条例》 《疫苗流通和预防接种管理条例》 《卫生系统电子认证服务管理办法（试行）》 《预防接种工作规范》 《儿童预防接种信息报告管理工作规范（试行）》 《全国疑似预防接种异常反应监测方案》 《中国疾病预防控制中心计算机网络安全管理办法（试行）》 （三）适用范围 “中国免疫规划信息管理系统”包括预防接种、疫苗管理、疑似预防接种异常反应、冷链设备4个业务管理子系统和综合管理系统。 本规范适用于使用“中国免疫规划信息管理系统”的所有机构和用户，包括各级卫生计生行政部门、疾病预防控制机构、乡级防保组织和预防接种单位、药品不良反应监测机构及其它有关机构和用户。 二、用户管理 （一）用户类型 1、系统管理员 国家、省、市、县级疾病预防控制机构设立系统管理员，授权管理“中国免疫规划信息管理系统”用户，是履行用户管理与服务职能的唯一责任人。 2、审计管理员 国家、省、市、县级疾病预防控制机构设立审计管理员，授权“中国免疫规划信息管理系统”安全审计，是履行系统安全审计的责任人。 3、业务管理员 国家、省、市、县级疾病预防控制机构设立业务管理员，授权分配业务子系统用户权限，是履行所管业务子系统的权限分配、建立角色等职能的责任人。 4、普通用户 各级根据业务需求，由系统管理员建立普通用户，由业务管理员授权，是执行相应业务工作的责任人。 （二）用户职责 1、系统管理员 负责本级的业务管理员、普通用户以及下一级系统管理员的用户账号管理，县级系统管理员还需负责辖区内乡级普通用户的账号管理。包括各类用户的创建、有效性及密码等维护管理，分配业务子系统，为所管用户提供账号使用的操作培训和技术指导等。 2、审计管理员 负责本级及下一级操作安全审计，县级审计管理员还需负责辖区 OA系统权限管理设计方案 l 不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 l 可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 l 权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 l 满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 针对OA系统的特点，权限说明： 权限 在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有4种方式(参考飞思办公系统) A. 通过职位 a) 在职位中，职位成员的权限继承当前所在职位的权限，对于下级职位拥有的权限不可继承。 b) 实例中：如前台这个职位，对于考勤查询有权限，则可以通过对前台这个职位设置考勤查询的浏览权，使他们有使用这个对象的权限，然后再设置个，考勤查询权（当然也可以不设置，默认能进此模块的就能查询），则所有前台人员都拥有考勤查询的权利。 B. 通过项目 a) 在项目中，项目成员的权限来自于所在项目的权限，他们同样不能继承下级项目的权限，而对于项目组长，他对项目有全权，对下级项目也一样。 b) 实例中：在项目中，项目成员可以对项目中上传文档，查看本项目的文档,可以通过对项目设置一个对于本项目的浏览权来实现进口，这样每个成员能访问这个项目了，再加上项目文档的上传权和查看文档权即可。 功能模块详细设计说明书 编写目的................................................... 项目背景................................................... 定义....................................................... 参考资料................................................... 2．总体设计.................................................... 需求概述................................................... 软件结构................................................... 3．程序描述.................................................... 功能....................................................... 性能....................................................... 输入项目................................................... 输出项目................................................... 算法....................................................... 程序逻辑................................................... 接口....................................................... 存储分配................................................... 限制条件................................................... 测试要点................................................... 系统账户权限管理规范 1.目的 为规范产业公司系统账户、权限管理，确保各使用单位与权限操作间的有效衔接，防止账户与权限管理失控给公司带来利益损失、经营风险。信息系统帐号的合理配置、有效使用、及时变更、安全保密，特制订本规范。 2.适用范围 本规范适用于多公司本部各单位、营销机构。 3.定义 3.1公司：指多媒体产业公司 3.2单位：指公司下属各单位，包含HR中体现为不同人事范围的直属部门、驻外机构。 3.3人事管理：指负责本单位人事信息人员，包括行政机构、驻外分公司人事经理、事业部、生产厂等部门级人事管理岗。 3.4权限管理员：负责本单位信息系统用户集中申请、变更，管理本单位信息系统用户对口的管理人员。包含单位自行开发和管理的信息系统（自行开发系统由所在部门指定系统管理员负责），如营销中心的“DDS”，研究“PDM”也是流程申请的维一发起人。 3.5系统管理员：指系统开发、系统配置管理的IT人员，部分虹信IT顾问为主。也可根据组织架构授权给某业务单位的相关人员，其负责某系统用户和权限的配置管理者。 3.6系统流：指每个系统固定的申请、审批流，原则上由系统管理员或权限管理员配置。 4.部门职责 4.1产业公司负责人： 4.1.1.公司信息系统立项、验收等审批工作。 4.1.2.公司信息系统，信息安全的第一责任人。 4.1.3.公司信息系统组织第一责任人 4.2人事部门： 4.2.1负责在人力资源管理系统（以下简称HR系统）处理人事档案，各单位权限管理员提交的信息系统需求协助。 4.2.2提供各单位的入职、调动、离职信息给信息系统管理部门。 4.2.3协助信息系统部门与人事相关的其它需求。 4.3控制中心： 4.3.1负责发布和制定信息建设规范，并组织通过技术手段或辅助工具管理。4.3.2负责组织周期性清理各信息系统账户。 4.3.3负责信息系统档案的建立。 4.3.4负责信息系统维护、权限配置、权限审核等相关事宜。 4.3.5 4.4用户申请部门和使用单位: 4.4.1各单位第一负责人管理本单位员工，各信息系统账户、权限申请、审核并对信息系统安全负责。定期组织相关人员对部门的信息系统帐号、权限进行清理和检查，申请职责可指定单位专人负责。 4.4.2权限管理员作为各单位信息系统申请的唯一发起人。 4.4.3权限管理员协助单位人事向公司人事部提交本单位入职、调动、离职信息。 4.4.4权限管理员负责本单位员工，各信息系统账户的新增、变更、冻结以及对应系统权限的申请工作。 4.4.5权限管理员负责定期核查本单位员工，对应系统账户的权限，若有偏差及时发起变更申请流程。 4.4.6帐号使用者不得将自己权限交由它人使用，部分岗位因工作需要交由同部门使用时，必须保证其安全和保密工作。 4.5系统操作部门： 4.5.1系统管理员负责对权限管理员提交的申请进行权限操作、审核。 4.5.2系统管理员定期在系统或SSU上获取信息系统的账号、权限分布表，并进行检查，对发现问题和风险的帐号及时告知相关部门并发起相应流程。 4.5.3系统管理员负责对系统故障进行处理或提交集团。 4.5.4系统管理员负责对系统操作手册的解释和编制工作。 系统功能模块设计描述（样例） 根据前面对数据流的分析，本系统划分为两大模块：应用模块和管理模块。 应用模块是为整个用户提供服务的各个模块的总和，包括用户登录、在线测评、信息浏览（包括测评新闻、测评结果、系统帮助、测评指标等）、用户留言、修改密码、信息查询（包括用户信息和测评记录）等。 系统管理模块用来实现对整个系统的管理，包括测评指标体系与智能建议规则库的维护、测评监控、新闻管理、留言管理、用户管理、系统初始化、系统数据库备份等。 系统功能模块如图3.4.6所示，下面分别介绍如下。 （1）用户登录模块 本模块是用户进入系统的入口，用户登录时要经过身份验证，只有本校在册学生和教职工才可以登录本系统。本系统有学生、学生信息员、教师、同行专家、系级领导、院级领导、系级管理员、院级管理员八种用户角色，根据其身份及作用的不同，通过ID 和密码验证用户的身份，对不同级别的用户系统自动调用不同的可访问页面，使用系统提供的与其身份相应的各项功能，其他用户只可以浏览公开信息。 （2）在线测评模块 在线测评模块由学生测评、同行专家测评、系领导评价、信息员汇报组成，其中系领导评价、信息员汇报属于日常教学质量管理监控范畴，在统计教师的课程教学质量测评总成绩时，只计算学生测评、同行专家测评的成绩。 学生测评和同行专家测评需要在规定的测评时间完成，每学期一次。在测评期间，系统根据当前学期的开课表，自动列出当前登录的学生与所学课程、任课教师一一对应的被测课程一览表，学生每次从中选择一门课程进行测评，提交后成功后再继续选评其他课程，每门课程只许测评一次。学生一次登录未测评完的课程，可以在下次登录时续评。学生评教时分理论课程教学、实践课程教学、体育课程教学三类，每一类均由详细的评价指标构成，并列有指标权重；专家评教时采用与学生评教不同的测评指标体系。测评者可根据测评内容和评分标准直接点击选择项进行评分。每类测评页面都设有开放性指标，测评者可自由参与评价。为防止部分学生测评时马虎了事，系统对全部选最好或最差选项的结果不许提交，并要求重新进行测评，避免造成测评结果异常。 系领导评价每年度进行一次，系统根据教师所属系部，自动列出与系领导的测评关系，评价结果存入领导评价结果表中。信息员每隔一周汇报一次本班级的教学整体情况，汇报结果存入信息员汇报结果表中。 图3.4.6 系统功能模块结构图 多系统权限设计 1.多系统基于角色的权限设计 这种方案是最常见也是比较简单的方案，不过通常有这种设计已经够了，这种方案对于每一个操作不做控制，只是在程序中根据角色对是否具有操作的权限进行控制；这里我们就不做详述.此处采用角色关联模块的方式。 2.多系统基于操作的权限设计 这种模式下每一个操作都在数据库中有记录，用户是否拥有该操作的权限也在数据库中有记录，结构如下： 但是如果直接使用上面的设计，会导致数据库中的_SysUserFuncOperate这张表数据量非常大，所以我们需要进一步设计提高效率，请看方案3 3.多系统基于角色和操作的权限设计 如上图所示，我们通过采用角色分配操作的方式，这样子就可以减少操作权限表（_SysRole FuncOperate）中的记录，并且使设计更灵活一点。 但是这种方案在用户需求的考验之下也可能显得不够灵活够用，例如当用户要求临时给某位普通员工某操作权限时，我们就需要新增加一种新的用户角色，但是这种用户角色是不必要的，因为它只是一种临时的角色，如果添加一种角色还需要在收回此普通员工权限时删除此角色，我们需要设计一种更合适的结构来满足用户对权限设置的要求。 4.2,3组合的权限设计，其结构如下： 我们可以看到在上图中添加了_SysUserFunc和_SysUserFuncOperate表，使用此表来添加特殊用户的权限。这样在应用程序中我们就需要通过_SysUserFuncOperate和_SysRoleFuncOperat e两张表中的记录判断权限。 当然，有可能用户还会给出这样的需求：对于某一种Operate所操作的对象某一些记录会有权限，而对于其他的记录没有权限，比如说一个内容管理系统，对于某一些频道某个用户有 CRM系统设计 1. 功能模块划分及描述 1.1系统功能模块结构图 1.2系统功能模块描述 2. 系统配置设计 3.系统流程图设计 4. 代码设计 5. 数据库设计 5.1概念结构设计 5.2逻辑设计 6. 系统模块设计 1. 功能模块划分及描述 客户关系管理系统是一个典型的数据库开发应用程序，由客户管理模块、库存管理模块、服务管理模块、报表管理模块、email管理模块、用户管理模块组成，系统功能模块及描述如下。 1.1系统功能模块结构图 图1 系统功能模块结构图 1.2系统功能模块描述 1、客户管理模块 该模块主要功能是对客户信息、客户联系人信息、合同信息进行添加、删除、查询等操作。 2、库存管理模块 该模块的主要功能是管理入库、出库信息、产品信息进行管理，其中包括对库存信息、产品信息进行添加、删除、查询等操作。 3、服务管理模块 该模块主要功能是对客户反馈信息进行添加、删除、查询等操作。 4、报表管理模块 该模块主要通过查询条件，对各种信息进行查询，并将得到的结果导出Excel 表、进行打印报表等操作（其息包括：客户信息、联系人信息、反馈客户信息、库存信息）。 5、管理模块 该模块主要管理客户联系人email地址信息，对企业客户之间的email文件进行管理，向客户发送。 6、用户管理 该模块主要管理用户信息的添加、删除等操作，并设置用户的使用权限。2. 系统配置设计 硬件平台： CPU：P4 2.8GHz； 存：2GB以上。 软件平台： 操作系统：Windows xp/ Windows 7/ Windows 2003； 数据库：SQL Server 2000； 浏览器：IE6.0，推荐使用IE8.0； Web服务器：IIS5.0； 分辨率：最佳效果1024*768。 3.系统流程图设计 系统流程图又叫事务流程图，是在计算机事务处理应用进行系统分析时常用的一种描述法（另一个是数据流图），它描述了计算机事务处理中从数据输入开始到获得输出为止，各个处理工序的逻辑过程。 根据需求分析的要求对系统进行设计，系统流程图如图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.涉及资源，权限和规则的权限设计 公司信息化系统用户权限管理制度 第一章总则 第一条为了规范公司信息化系统的权限管理工作，明确系统用户权限的管理职责，结合公司实际情况，特制定本制度。 第二条相关名词解释 信息化系统:公司ERP系统，炼钢生产管控系统、报表系统、在线质量判定系统、物资计量网、调度日报系统、能力计划系统、物资计量系统、热轧自动仓储、冷轧自动仓储、一卡通、OA、内网、文档管理、IT运行管理等系统。 权限：在信息化系统中用户所能够执行的操作及访问的数据。 第三条本制度的适用范围为公司各单位，其中派驻站、ERP权限变更按照其归属部门流程提报。 第二章职责分工 第四条运营改善部作为信息化系统用户权限的归口管理部门，主要负责各系统内用户权限的命名、审批、上报、配置、监控、删除、通知和培训等管理工作。负责《公司信息化系统用户权限管理制度》的修订、培训、实施、检查。 第五条各相关部室和作业部负责指定本单位权限管理员和权限审批者参与权限管理工作，权限管理员负责本单位信息系统权限的收集、申请、下发、测试、反馈；权限审批者负责本单位申请的系统权限进行审批把关，并对权限申请后形成的业务结果负责。 第六条系统用户负责本人权限测试、保管工作；负责权限密码泄密后的上报和密码更换工作；负责依据本人权限进行相应系统操作。 第三章系统用户权限管理 第七条用户权限的申请 业务部门根据实际业务，需要新建（变更）信息化系统用户的权限，由本部门权限管理员在公司IT运行管理系统中填报权限新增（变更）申请。 第八条用户权限的审批 信息系统用户权限新增（变更）申请在公司IT运行管理系统中由申请单位权限审批者进行审批。 第九条用户权限的系统实现 经公司IT运行管理系统申请的系统权限，由运营改善部权限管理员于收到权限申请后一个工作日内完成权限审批、配置、变更工作，对于审批通过的ERP权限申请，由运营改善部按照《R/3系统用户申请表》、《用户权限变更申请表》要求完成上报工作。 第十条用户权限的系统测试 申请单位权限管理员在接到权限配置完成的信息后，应及时通知相关用户，在两个工作日之内完成系统权限测试，存在问题的由权限管理员反馈运营改善部。申请单位权限管理员在接到权限删除完成的信息后，由权限管理员在两个工作日之内完成系统权限测试，存在问题的由权限管理员反馈运营改善部。 在两个工作日之内无问题反馈的，运营改善部将视此权限设置正确，以后该申请权限存在的任何问题重新按照权限新增（变更）流程处理。 第四章用户权限的使用和管理 第十一条系统权限用户命名由运营改善部权限管理员负责，ERP权限命名规则为首字母Q加上模块名（如：FI、MM、PP）加上连接字符“-”，再加上4位用户 实现业务系统中的用户权限管理--设计篇 B/S系统中的权限比C/S中的更显的重要，C/S系统因为具有特殊的客户端，所以访问用户的权限检测可以通过客户端实现或通过客户端+服务器检测实现，而B/S中，浏览器是每一台计算机都已具备的，如果不建立一个完整的权限检测，那么一个“非法用户”很可能就能通过浏览器轻易访问到B/S系统中的所有功能。因此B/S业务系统都需要有一个或多个权限系统来实现访问权限检测，让经过授权的用户可以正常合法的使用已授权功能，而对那些未经授权的“非法用户”将会将他们彻底的“拒之门外”。下面就让我们一起了解一下如何设计可以满足大部分B/S系统中对用户功能权限控制的权限系统。 需求陈述 ?不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 ?可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便 的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致 的人员编入同一组，然后对该组进行权限分配。 ?权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套 管理系统，就要针对权限管理部分进行重新开发。 ?满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统 之间，功能权限是可以重用的，而资源权限则不能。 关于设计 借助NoahWeb的动作编程理念，在设计阶段，系统设计人员无须考虑程序结构的设计，而是从程序流程以及数据库结构开始入手。为了实现需求，数据库的设计可谓及其重要，无论是“组”操作的概念，还是整套权限管理系统的重用性，都在于数据库的设计。 我们先来分析一下数据库结构： 首先，action表（以下简称为“权限表”），gorupmanager表（以下简称为“管理组表”），以及master表（以下简称为“人员表”），是三张实体表，它们依次记录着“权限”的信息，“管理组”的信息和“人员”的信息。如下图： OA系统权限管理设计方案7 OA系统权限管理设计方案 数据库2010-02-2310:09:25阅读13评论0字号：大中小 OA系统权限管理设计方案 l不同职责的人员，对于系统操作的权限应该是不同的。优秀的业务系统，这是最基本的功能。 l可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。 l权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。 l满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。 针对OA系统的特点，权限说明： 权限 在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。将模块与之组合可以产生此模块下的所有权限。 权限组 为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。 角色 权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。 用户组 将某一类型的人、具有相同特征人组合一起的集合体。通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。用户组的划分，可以按职位、项目或其它来实现。用户可以属于某一个组或多个组。 通过给某个人赋予权限，有4种方式(参考飞思办公系统) A.通过职位 a)在职位中，职位成员的权限继承当前所在职位的权限，对 研发生产中心文档编号版本A1 密级商密A 项目名称Xx系统 项目来源 Xxx系统 详细设计说明书 (内部资料请勿外传) 编写：日期：检查：日期：审核：日期：批准：日期： XX公司 版权所有不得复制 文档变更记录 序号变更（+/-）说明作者版本号日期批准1 2 目录 1. 引言 (5) 1.1 编写目的和范围 (5) 1.2 术语表 (5) 1.3 参考资料 (5) 1.4 使用的文字处理和绘图工具 (5) 2. 全局数据结构说明 (7) 2.1 常量 (7) 2.2 变量 (8) 2.3 数据结构 (8) 3. 模块设计 (9) 3.1 用例图 (9) 3.2 功能设计说明 (10) 3.2.1 模块1 (10) 3.2.2 模块2 (11) 4. 接口设计 (12) 4.1 内部接口 (12) 4.2 外部接口 (12) 4.2.1 接口说明 (12) 4.2.2 调用方式 (12) 5. 数据库设计 (12) 6. 系统安全保密设计 (12) 6.1 说明 (12) 6.2 设计 (12) 6.2.1 数据传输部分 (12) 6.2.2 IP过滤分部 (13) 6.2.3 身份验证部分 (13) 7. 系统性能设计 (13) 8. 系统出错处理 (13) 1.引言 1.1背景 此文档的背景 1.2编写目的和范围 说明写这份详细设计说明书的目的。 本详细设计说明书编写的目的是说明程序模块的设计考虑，包括程序描述、输入/输出、算法和流程逻辑等，为软件编程和系统维护提供基础。本说明书的预期读者为系统设计人员、软件开发人员、软件测试人员和项目评审人员。 1.3术语表 定义系统或产品中涉及的重要术语，为读者在阅读文档时提供必要的参考信息。 序号术语或缩略语说明性定义 1 PM Project Manager,项目经理 2 1.4参考资料 列出有关资料的名称、作者、文件编号或版本等。参考资料包括： a．需求说明书、架构设计说明书等； b．本项目的其他已发表的文件； c．引用文件、资料、软件开发标准等。 资料名称作者文件编号、版本资料存放地点 1.5使用的文字处理和绘图工具 文字处理软件：[编写设计文档使用的文字处理软件，如RedOffice ] 绘图工具：[使用的UML工具，如Rose、Jude、Visio] 基础支撑层 统一身份认证（SSO） 统一身份认证解决用户在不同的应用之间需要多次登录的问题。目前主要有两种方法，一种是建立在PKI，Kerbose和用户名/口令存储的基础上；一种是建立在cookie的基础上。统一身份认证平台主要包括三大部分：统一口令认证服务器、网络应用口令认证模块(包括Web 口令认证、主机口令认证模块、各应用系统口令认证模块等) 和用户信息数据库，具体方案如下图。 1、采用认证代理，加载到原有系统上，屏蔽或者绕过原有系统的认证。 2、认证代理对用户的认证在公共数据平台的认证服务器上进行，认证代理可以在认证服务器上取得用户的登录信息、权限信息等。 3、同时提供一个频道链接，用户登录后也可以直接访问系统，不需要二次认证。 4、对于认证代理无法提供的数据信息，可以通过访问Web Service接口来获得权限和数据信息。 单点登录认证的流程如下图所示： 单点登录只解决用户登录和用户能否有进入某个应用的权限问题，而在每个业务系统的权限则由各自的业务系统进行控制，也就是二次鉴权的思想，这种方式减少了系统的复杂性。统一身份认证系统架构如下图所示。 统一系统授权 统一系统授权支撑平台环境中，应用系统、子系统或模块统通过注册方式向统一系统授权支撑平台进行注册，将各应用系统的授权部分或全部地委托给支撑平台，从而实现统一权限管理，以及权限信息的共享，其注册原理如下图。 用户对各应用系统的访问权限存放在统一的权限信息库中。用户在访问应用系统的时候，应用系统通过统一授权系统的接口去查询、验证该用户是否有权使用该功能，根据统一系统授权支撑平台返回的结果进行相应的处理，其原理如下图。 统一系统授权支撑平台的授权模型如下图所示。在授权模型中采用了基于角色的授权方式，以满足权限管理的灵活性、可扩展性和可管理性的需求 块 系统用户和权限管理制度 第一章总则 第一条为加强系统用户账号和权限的规范化管理,确保各信息系统安全、有序、稳定运行，防范应用风险，特制定本制度。 第二条本制度适用于管理的、基于角色控制和方法设计的各型信息系统，以及以用户口令方式登录的客户端。 第三条系统用户、角色、权限的划分和制定，以人力资源部对部门职能定位和各业务部门内部分工为依据。 第四条协同办公系统用户和权限管理由场办公室负责，其他业务系统的用户和权限管理由各业务部门具体负责。所有信息系统须指定系统管理员负责用户和权限管理的具体操作。 第五条信息系统用户和权限管理的基本原则是： （一）用户、权限和口令设置由系统管理员全面负责。 （二）用户、权限和口令管理必须按照要求进行分配管理。 （三）用户、权限和口令管理采用实名制管理模式。 （四）严禁杜绝一人多账号登记注册。 第二章管理职责 第七条系统管理员职责 创建各类申请用户、用户有效性管理、为用户分配经授权批准使用的业务系统、为用户授权和操作培训和技术指导。 第八条用户职责 用户须严格管理自己用户名和口令，遵守保密性原则，除获得授权或另有规定外，不能将收集的个人信息向任何第三方泄露或公开。系统内所有用户信息均必须采用真实信息，即实名制登记。 第三章用户管理 第十条用户申请和创建 （一）申请人填写基本情况，提交本部门负责人； （二）部门负责人确认申请业务用户的身份权限，并在《用户账号申请和变更表》确认。 （三）经由部门经理进行审批后，由系统管理员创建用户或者变更权限。 （四）系统管理员将创建的用户名、口令告知申请人本人，并要求申请人及时变更口令； （五）系统管理员将《用户账号申请和变更表》存档管理。 第十一条用户变更和停用 （一）人力资源部主管确认此业务用户角色权限或变更原因。 （二）执行部门主管确认此业务用户角色权限或变更原因。 （三）系统管理员变更 系统管理员变更，应及时向上级系统管理员报告，并核对其账户信息、密码以及当时系统中的各类用户信息及文档，核查无误后方可进行工作交接。新任系统管理员应及时变更账户信息及密码。 （四）业务管理员变更 业务变更应及时向本级管理或上级业务管理报告，上级业务管理和系统管理员及时变更业务管理信息。 （五）用户注销 用户因工作岗位变动，调动、离职等原因导致使用权限发生变化或需要注销其分配账号时，应填写《用户账号申请和变更表》，按照用户账号停用的相关流程办理，由系统管理员对其权限进行注销。 第四章安全管理 第十二条使用各信息系统应严格执行国家有关法律、法规，遵守公司的规章制度，确保国家秘密和企业利益安全。 第十三条口令管理 （一）系统管理员创建用户时，应为其分配独立的初始密码，并单独告知申请人。 （二）用户在初次使用系统时，应立即更改初始密码。 （三）用户应定期变更登陆密码。 （四）用户不得将账户、密码泄露给他人。 第十四条帐号审计用户权限设计
信息系统用户帐号与角色权限管理系统流程
RBAC用户角色权限设计方案(非常好)
系统用户及权限管理制度
功能模块设计
中国免疫规划信息管理系统用户与权限管理规范
系统权限管理设计方案(优选.)
软件开发功能模块详细设计文档
最全系统账户权限的管理规范完整版.doc
系统功能模块设计 样例
多系统权限设计
系统设计报告模板
权限设计方案
公司信息化系统用户权限管理制度 Office
最经典用户权限管理模块设计
系统权限管理设计方案.doc
软件详细设计模板(最全面)
统一身份认证、统一系统授权、统一系统审计、统一消息平台、统一内容管理方案设计
信息系统用户和权限管理制度