下载文档原格式
通用权限管理设计篇----38c41bc0-7165-11ec-8fd2-7cb59b590d7d通用权限管理设计篇（一）因为虽然一些系统的权限管理功能在逐步完善，但总有一些不尽如人意的地方。
我总是想花时间来更好地思考权限系统的设计。
权限系统一直以来是我们应用系统不可缺少的一个部分，若每个应用系统都重新对系统的权限进行设计，以满足不同系统用户的需求，将会浪费我们不少宝贵时间，所以花时间来设计一个相对通用的权限系统是很有意义的。
二．设计目标设计一个灵活、通用、方便的权限管理系统。
在这个系统中，我们需要控制系统的所有资源。
系统中的资源是什么？我们可以简单地将这些资源概括为静态资源（函数操作、数据列）和动态资源（数据），分别称为对象资源和数据资源。
后者是我们在系统设计和实现方面的名字。
系统的目标是控制应用系统的所有对象资源和数据资源的权限，如应用系统的功能菜单、每个界面的按钮、数据显示列和各种行级数据。
3、相关对象及其关系大概理清了一下权限系统的相关概念，如下所示：1.权限系统的所有权限信息。
权限具有层次关系，是一种树状结构。
让我们举个例子对于上面的每个权限，又存在两种情况，一个是只是可访问，另一种是可授权，例如对于“查看用户”这个权限，如果用户只被授予“可访问”，那么他就不能将他所具有的这个权限分配给其他人。
2.用户应用系统的特定操作员，用户可以拥有权限信息，可以属于0~n个角色，也可以属于0~n个组。
他的权限集是他自己的权限、每个角色的权限和每个组的权限的集合。
它与权限、角色和组的关系是n对n的。
角色为了对许多拥有相似权限的用户进行分类管理，定义了角色的概念，例如系统管理员、管理员、用户、访客等角色。
角色具有上下级关系，可以形成树状视图，父级角色的权限是自身及它的所有子角色的权限的综合。
父级角色的用户、父级角色的组同理可推。
4.组为了更好地管理用户，对用户进行分组和分类，简称用户分组。
组还具有父子关系，可以形成树视图。
用户权限管理设计简介本文档旨在设计一个用户权限管理系统，该系统可用于管理用户在系统中的访问权限和操作权限。
通过合理的权限管理，可以提高系统的安全性、保护敏感数据，并确保系统仅被授权用户访问。
功能需求1. 用户注册和登录功能：系统应提供用户注册和登录功能，以便用户可以进行身份验证和访问授权操作。
2. 用户角色管理：系统应支持定义不同的用户角色，并为每个角色分配特定的权限。
用户角色可以根据其职责和需求来定义，例如管理员角色、普通用户角色等。
3. 权限分配：系统管理员应有权将特定的权限分配给用户角色或个别用户。
这些权限可以包括系统模块访问权限、数据操作权限等。
4. 权限验证：系统应能够验证用户对特定操作的权限。
在用户进行敏感操作之前，系统应先验证该用户是否具有执行该操作的权限，并相应地提供授权或拒绝访问的提示。
5. 日志记录：系统应能够记录用户的操作日志，包括登录、权限变更、敏感操作等。
这有助于审计和安全追踪。
6. 密码策略：系统应支持强密码策略，要求用户选择足够强度的密码，并定期要求用户更改密码。
7. 密码加密：系统应对用户密码进行加密存储，以保护用户密码的安全。
8. 异常处理：系统应有健壮的异常处理机制，能够处理各种异常情况并提供相应的错误提示，以确保系统的稳定性和可靠性。
技术实现1. 用户数据存储：系统可以使用关系型数据库或非关系型数据库来存储用户数据，以便进行用户身份验证和权限验证。
2. 认证与授权：系统可以使用常见的认证与授权框架来实现用户登录、角色管理和权限分配等功能，如Spring Security、Shiro等。
3. 日志记录：系统可以使用日志记录框架来记录用户操作日志，如Log4j、Slf4j等。
4. 异常处理：系统可以使用异常处理框架来捕获和处理异常，如Spring MVC的异常处理机制。
5. 密码加密：系统可以使用加密算法对用户密码进行加密存储，如MD5、SHA等。
安全考虑1. 防止跨站脚本攻击（XSS）：系统应对用户输入进行合理的过滤和转义，防止恶意脚本注入。
用户权限管理设计方案用户权限管理是一种重要的信息安全控制手段，能够确保系统中的用户只能访问其所需的数据和功能，防止未授权的操作和数据泄露。
本文将从用户权限的概念、设计原则、权限管理模型以及权限管理方案的实施等方面进行详细讨论。
一、用户权限的概念用户权限是指用户在系统中所具备的操作和访问资源的能力。
它涵盖了用户能够进行的操作类型、访问的资源范围以及操作的具体权限。
通过用户权限，系统可以灵活地控制用户在系统中的行为和操作，确保用户只能进行其所需的操作，从而提高系统的安全性。
二、用户权限管理的设计原则1.最小权限原则：用户应该被授予执行其工作所需的最小权限，以降低潜在的风险。
只有在确实需要的情况下，才应该授予更高级别的权限。
2.分级管理原则：根据用户的角色和职责将用户划分为不同的权限组，每个权限组仅拥有其所需的操作和资源访问权限。
3.统一权限管理原则：用户权限应该经过集中管理，避免出现分散和重复的权限设置，以减少管理成本和提高管理效率。
三、权限管理模型1. 自顶向下授权模型（Top-Down Authorization Model）：该模型将权限从高层次向低层次授权，通过角色定义和角色授权的方式，将用户划分为不同的角色，每个角色拥有其所需的权限。
2. 基于角色的访问控制模型（Role-Based Access Control Model）：该模型根据用户的角色将权限分配给用户，通过角色的添加、修改和删除来变更用户的权限。
3. 基于目录的访问控制模型（Directory-Based Access Control Model）：该模型根据用户所在的组织结构进行权限管理，通过目录结构的设定和权限的继承来实现权限的控制和管理。
四、权限管理方案的实施1.确定用户的角色和职责：根据不同用户的角色和职责，将用户划分为不同的权限组。
同时，定义每个角色所需的操作和资源访问权限。
2.设计权限继承关系：通过权限的继承，将上层角色的权限传递给下层角色，以减少权限设置的重复。
权限管理系统毕业设计一、需求分析1.1 背景介绍随着企业信息化的不断发展，权限管理已成为企业信息管理的重要组成部分。
一个完善的权限管理系统可以帮助企业实现精细化的权限控制，提高信息安全性和工作效率。
本次毕业设计旨在开发一款功能完善、安全可靠的权限管理系统，满足企业对权限管理的需求。
1.2 功能需求根据实际应用需求，本权限管理系统应具备以下功能：1. 用户管理：实现用户信息的录入、修改、删除等操作。
2. 角色管理：定义角色及其权限，实现角色的分配和撤销。
3. 权限管理：对系统各个模块的权限进行设置，实现不同用户拥有不同的操作权限。
4. 日志记录：记录用户登录、操作等日志信息，方便追踪和审计。
5. 数据统计：对系统使用情况进行统计和分析，为企业提供数据支持。
二、系统设计2.1 系统架构本系统采用B/S架构，主要由前端、后端和数据库三部分组成。
前端负责与用户交互，后端负责业务逻辑处理，数据库负责数据存储和查询。
2.2 功能模块根据需求分析，本系统主要包括以下功能模块：1. 用户管理模块：实现用户信息的录入、修改、删除等操作。
2. 角色管理模块：定义角色及其权限，实现角色的分配和撤销。
3. 权限管理模块：对系统各个模块的权限进行设置，实现不同用户拥有不同的操作权限。
4. 日志记录模块：记录用户登录、操作等日志信息，方便追踪和审计。
5. 数据统计模块：对系统使用情况进行统计和分析，为企业提供数据支持。
2.3 数据库设计本系统的数据库设计主要涉及用户表、角色表、权限表等。
用户表包含用户基本信息，角色表包含角色信息和权限信息，权限表则定义了各个模块的权限信息。
三、系统实现3.1 技术栈选择本系统前端采用HTML5、CSS3和JavaScript技术，后端采用Java语言和Spring框架，数据库采用MySQL。
3.2 关键技术实现本系统的关键技术实现包括以下几点：1. 前后端分离：前端只负责展示数据和接收用户输入，后端负责处理业务逻辑和数据存储。
权限管理模块设计说明书摘要权限管理分为两个部分，操作权限管理和资源权限管理。
针对我们的系统，分别进行说明。
一、操作权限管理即为允许用户使用那些功能，进行哪些操作。
有两个地方需要处理，1、对用户隐藏没有授权的功能。
如“LOG管理”功能没有对用户A授权，则用户A是看不见“LOG管理”这个功能菜单的。
2、在功能所在的页面进行权限验证，防止没有授权的用户通过输入URL进入功能所在页面。
如“LOG管理”功能没有对用户A授权，则用户A是即使是手动输入“LOG管理”功能所在的页面，他也无法使用这个功能。
在实现方式上可以通过”角色”和”功能”来实现，一个”角色”对应多个”功能”，”用户”与”角色”是多对多的关系。
当用户登录时通过(用户->角色->功能)查询出该用户可以使用的功能列表并显示，无权使用的功能将被隐藏。
并且在功能所在页面进行权限验证，避免没有权限的用户通过特殊方法进入页面。
二、资源权限管理的意思是限制用户对资源的访问和操作。
1、省级的用户可以查看和操作全省的数据。
但不能查看和操作外省的数据。
2、市级的用户可以查看和操作全市的数据，但不能查看和操作该市以外的数据。
3、全国级的用户可以查看和操作全国的数据。
目录1概述 (3)1.1目的 (3)2模块结构描述 (3)3模块功能描述 (3)3.1权限管理 (3)3.1.1功能菜单管理 (3)3.1.2用户管理 (4)3.1.3角色管理 (4)3.2操作权限验证 (5)3.2.1登录验证 (5)3.2.2页面载入验证 (5)3.2.3页面操作权限验证 (6)3.3资源权限验证 (6)4数据库设计ER图 (7)1概述1.1目的权限管理模块是为了对系统权限进行管理和验证。
2模块结构描述3模块功能描述3.1权限管理3.1.1功能菜单管理系统的每个功能都要对应一个功能菜单，功能菜单管理即是对这些菜单项的增删改查管理。
3.1.1.1查询功能菜单输入：功能名称、功能级别、是否已删除输出：功能名称，父功能名称，功能代码，功能级别，功能页面名称，是否已删除。
权限管理功能设计
一．概述
基于角色管理. 用户，角色，模块，权限的相互组合，可以形成一个强大的权限管理系统。
设计思路
1.用户的权限通过角色来控制,一个用户可以拥有单个角色.
2.用户拥有单个角色时，其权限应该是单个角色相互的补集.
3.一个角色拥有多个模块（权限）
4.用户的前台菜单显示根据角色所拥有的模块所决定，不同的用户在前端显示的操作菜单
是不一样的。
5.页面中的功能按钮根据模块中所包含的功能所定义，通过模块及角色所拥有的权限进行
控制
6.可看某个模块有哪些用户，哪些对应角色,并对其进行特殊权限设置.
7.可以针对单个用户进行特殊设置
二．权限管理包括用户、角色、资源：
用户：user
角色：role
用户-角色：user_role
资源：resource（包括上级菜单、子菜单、按钮等资源）
角色-资源：role_resource
标准的权限管理系统设计为以上5张表。
三．表结构：
优惠券表：is_coupon_info
会员<1——n>优惠券。
OA系统权限管理设计方案第一篇：OA系统权限管理设计方案OA系统权限管理设计方案l 不同职责的人员，对于系统操作的权限应该是不同的。
优秀的业务系统，这是最基本的功能。
l 可以对“组”进行权限分配。
对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统操作权限的话，是件耗时且不够方便的事情。
所以，系统中就提出了对“组”进行操作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。
l 权限管理系统应该是可扩展的。
它应该可以加入到任何带有权限管理功能的系统中。
就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。
l 满足业务系统中的功能权限。
传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。
针对OA系统的特点，权限说明：权限在系统中，权限通过模块+动作来产生，模块就是整个系统中的一个子模块，可能对应一个菜单，动作也就是整个模块中（在B/S系统中也就是一个页面的所有操作，比如“浏览、添加、修改、删除”等）。
将模块与之组合可以产生此模块下的所有权限。
权限组为了更方便的权限的管理，另将一个模块下的所有权限组合一起，组成一个“权限组”，也就是一个模块管理权限，包括所有基本权限操作。
比如一个权限组（用户管理），包括用户的浏览、添加、删除、修改、审核等操作权限，一个权限组也是一个权限。
角色权限的集合，角色与角色之间属于平级关系，可以将基本权限或权限组添加到一个角色中，用于方便权限的分配。
用户组将某一类型的人、具有相同特征人组合一起的集合体。
通过对组授予权限（角色），快速使一类人具有相同的权限，来简化对用户授予权限的繁琐性、耗时性。
用户组的划分，可以按职位、项目或其它来实现。
用户可以属于某一个组或多个组。
通过给某个人赋予权限，有4种方式(参考飞思办公系统)A.通过职位a)在职位中，职位成员的权限继承当前所在职位的权限，对于下级职位拥有的权限不可继承。
权限管理表设计权限管理表主要记录用户的权限信息，包括用户的角色、菜单、操作和资源等。
具体的表设计如下：用户表（user）- 用户ID（user_id）：主键，用户的唯一标识- 用户名（username）：用户的登录名- 密码（password）：用户登录的密码- 姓名（name）：用户的真实姓名- 手机号（phone）：用户的联系电话- 邮箱（email）：用户的邮箱地址角色表（role）- 角色ID（role_id）：主键，角色的唯一标识- 角色名称（role_name）：角色的名称- 角色描述（role_description）：角色的描述信息用户角色关系表（user_role）- 用户角色关系ID（user_role_id）：主键，用户角色关系的唯一标识- 用户ID（user_id）：外键，关联到用户表的用户ID- 角色ID（role_id）：外键，关联到角色表的角色ID菜单表（menu）- 菜单ID（menu_id）：主键，菜单的唯一标识- 菜单名称（menu_name）：菜单的名称- 菜单路径（menu_path）：菜单的访问路径角色菜单关系表（role_menu）- 角色菜单关系ID（role_menu_id）：主键，角色菜单关系的唯一标识- 角色ID（role_id）：外键，关联到角色表的角色ID- 菜单ID（menu_id）：外键，关联到菜单表的菜单ID操作表（operation）- 操作ID（operation_id）：主键，操作的唯一标识- 操作名称（operation_name）：操作的名称菜单操作关系表（menu_operation）- 菜单操作关系ID（menu_operation_id）：主键，菜单操作关系的唯一标识- 菜单ID（menu_id）：外键，关联到菜单表的菜单ID- 操作ID（operation_id）：外键，关联到操作表的操作ID资源表（resource）- 资源ID（resource_id）：主键，资源的唯一标识- 资源名称（resource_name）：资源的名称- 资源路径（resource_path）：资源的访问路径角色资源关系表（role_resource）- 角色资源关系ID（role_resource_id）：主键，角色资源关系的唯一标识- 角色ID（role_id）：外键，关联到角色表的角色ID- 资源ID（resource_id）：外键，关联到资源表的资源ID通过以上表的设计，可以实现对用户权限的管理。
对EMS权限管理模块设计1.权限设计概述1.1引言随着Web 服务的复杂度增加以及用户数量和种类的增多，安全问题在理论及工程上都是一个必须考虑的问题，而权限管理是安全问题中一个很重要的方面。
因此本文针对权限做了一个分析。
权限可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。
1.2意义❖用户管理及权限管理一直是应用系统中不可缺少的一个部分❖系统用户很多，系统功能也很多❖不同用户对系统功能的需求不同❖出于安全等考虑，关键的、重要的系统功能需限制部分用户的使用❖出于方便性考虑，系统功能需要根据不同的用户而定制1.3目标直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，除了功能的必须，更主要的就是因为它足够直观。
简单，包括概念数量上的简单和意义上的简单还有功能上的简单。
想用一个权限系统解决所有的权限问题是不现实的。
设计中将变化的“定制”特点比较强的部分判断为业务逻辑，而将相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。
扩展，采用可继承的方式解决了权限在扩展上的困难。
引进Group概念在支持权限以组方式定义的同时有效避免了权限的重复定义。
2.基于角色的权限管理设计（Role-Based AccessControl ,RBAC）2.1权限管理用例图2.2用例图描述超级管理员：系统中默认的角色，它是系统中拥有最高权限的角色，它不仅能够管理其他的管理员和用户，而且还可以对系统中每个模块的任一功能进行操作、维护。
普通管理员：它是由超级管理员创建的，并授予权限，它能够管理系统中大部分的功能，它可以查看所有普通管理员、普通用户的信息，它只能对由它自己创建的用户进行编辑、删除操作，和管理拥有权限的模块。
普通用户：它是系统中最低权限的角色，它只能对自己拥有的权限进行操作，一般情况下，它的权限是对信息的浏览和对自己信息的录入，修改。
登陆系统：根据用户拥有的权限不同，用户所能操作的功能多少就不同，所以在登陆系统的时候就要对用户的权限进行判断。
用户管理：这里对本系统的登录用户进行维护。
包括，新建、删除、编辑、注销等；系统初始化的时候，用户管理中默认只有一个拥有超级管理员角色的用户，因此在初始化登陆的时候，只能用这个用户登陆，其他的用户由这个用户创建并授予角色。
角色管理：角色是赋予系统用户的职权名称。
包括，新建、删除、编辑、注销等；系统初始化的时候，角色管理中默认只拥有一个超级管理员的角色，其他角色由拥有这个角色的用户创建并授权。
其他模块：其他模块的每个功能都拥有一个唯一Id，根据用户登陆的权限，再确定这些功能是否对用户开放。
3.权限设计思路3.1 基于角色的访问控制RBACRBAC 的主要思想是:权限（Permissions）是和角色（Roles）相联系的，而用户（Users）则被指定到相应的角色作为其成员。
这样就使权限的管理大大简化了。
系统的权限控制主要是采用基于角色的访问控制，把权限绑定到角色上，当用户要操作权限时，就把角色赋给用户。
而且在需要撤回权限时，只需把角色上的权限撤回就行了。
3.2思路为了设计一套具有较强可扩展性的权限管理，需要建立用户、角色和权限等数据库表，并且建立之间的关系，具体实现如下3.3 用户用户仅仅是纯粹的用户，用来记录用户相关信息，如用户名、密码等，权限是被分离出去了的。
用户（User）要拥有对某种资源的权限，必须通过角色（Role）去关联。
用户通常具有以下属性：编号，在系统中唯一。
名称，在系统中唯一。
用户口令。
注释，描述用户或角色的信息。
3.4 角色角色是使用权限的基本单位，拥有一定数量的权限，通过角色赋予用户权限，通常具有以下属性：编号，在系统中唯一。
名称，在系统中唯一---- (监控人员 )注释，描述角色信息. ---→(在线监控人员)3.5 权限权限指用户根据角色获得对程序某些功能的操作，例如对文件的读、写、修改和删除功能，通常具有以下属性：编号，在系统中唯一。
名称，在系统中唯一-----→(添,删,改,查)注释，描述权限信息 .---→允许增加监控对象3.6 用户与角色的关系一个用户（User）对应一个角色（Role），一个角色可以被多个用户使用，用户角色就是用来描述他们之间隶属关系的对象。
用户（User）通过角色（Role）关联所拥有对某种资源的权限，例如用户（User）：UserID UserName UserPwd1 张三xxxxxx2 李四xxxxxx……角色（Role）：RoleID(角色编号) RoleName(角色名称) RoleNote(角色注释)01 系统管理员监控系统维护管理员02 监控人员在线监控人员03 调度人员调度工作人员04 一般工作人员工作人员……用户角色（User_Role）：UserRoleID UserID RoleID UserRoleNote( 用户角色注释)1 1 02 用户“张三”被分配到角色“监控人员”2 2 02 用户“李四”被分配到角色“监控人员”……从该关系表可以看出，用户所拥有的特定资源可以通过用户角色来关联。
3.7 权限与角色的关系一个角色（Role）可以拥有多个权限（Permission），同样一个权限可分配给多个角色。
例如：角色（Role）：RoleUUID(角色UUID) RoleName(角色名称) RoleRemark(角色注释)01 系统管理员监控系统维护管理员02 监控人员在线监控人员03 调度人员调度工作人员04 一般工作人员工作人员……权限（Privilege）：PrivilegeUUID(权限UUID) PrivilegeName(权限名称) PrivilegeRemark(权限注释) 0001 增加监控允许增加监控对象0002 修改监控允许修改监控对象0003 删除监控允许删除监控对象0004 察看监控信息允许察看监控对象角色权限（Role_ Privilege）：RolePermissionID RoleUUID PrivilegeUUID Role_PrivilegeRemark(角色权限注释)1 01 0001 角色“系统管理员”具有权限“增加监控”2 01 0002 角色“系统管理员”具有权限“修改监控”3 01 0003 角色“系统管理员”具有权限“删除监控”4 01 0004 角色“系统管理员”具有权限“察看监控”5 02 0001 角色“监控人员”具有权限“增加监控”6 02 0004 角色“监控人员”具有权限“察看监控”……由以上例子中的角色权限关系可以看出，角色权限可以建立角色和权限之间的对应关系。
3.8 建立用户权限用户权限系统的核心由以下三部分构成：创造权限、分配权限和使用权限。
第一步由Creator创造权限（Permission），Creator在设计和实现系统时会划分，指定系统模块具有哪些权限。
第二步由系统管理员（Administrator）创建用户和角色，并且指定用户角色（User－Role）和角色权限（Role－Permission）的关联关系。
第三步用户（User）登陆系统，对自己拥有的权限进行管理、使用。
4.权限的具体实现模式模式一：用户->角色->权限（最通用的方法）4.1 数据库结构4.1.1用户表：4.1.2角色表：4.1.3权限表：4.2 在控制层写if/else判断条件用户登入系统后，就通过其角色加载所有可以访问的页面，保存到 Session, 一直到用户退出系统或者 session 过期。
用户访问页面时，添加一个 Dispatcher （ tapestry5 方式），在这个 Dispatcher中解析出页面地址如 /cs/deposit ，和用户保存在 Session 里的可访问页面作比较，如果存在则继续，不存在则跳到登入页面。
模式二：Ralasafe第三方组件（图形界面的形式，简单易用）安装、配置与使用手册：/downloads/Ralasafe_Configuration_zh.pdf Ralasafe，是采用Java语言开发的轻量级数据级权限管理中间件。
解开权限与业务的耦合，采用全景式、图形化管理方式，无需大量Java和XML开发配置。
Ralasafe将权限分为两大类查询权限：用户从系统获取数据，此时系统根据用户不同，返回该用户具有权限查询的数据决策权限：用户向系统提交操作数据（如：修改、添加或者删除某订单），此时系统根据用户和被操作数据，判断是否允许操作权限层级分为两大类功能级权限，又称操作权限，使用角色模型足够数据级权限，支持数据行级、列级，又称内容权限，细粒度权限Ralasafe专注于数据级权限，使用策略机制进行管理。
Ralasafe也提供了功能级权限实现，该功能可选，并不耦合。
Ralasafe系统架构安全引擎，该引擎解析授权策略，对所有访问进行过滤。
从2个方向进行控制：从系统获取数据，比如查询订单，查询客户资料向系统提交数据，比如修改某订单，删除某客户资料管理界面，通过管理界面IT管理员可以轻松管理、设计授权策略，并在线仿真测试。
Ralasafe是服务，而不是框架。
对应用程序没有要求，也不需要修改业务数据库。
Ralasafe的结构性数据与业务数据独立保存在数据库，非结构性数据保存在文件系统，方便移植。
模式三：注解和拦截器实现权限通用模型的设计使用这种设计方案，可以很好地分离权限与系统本身的功能，让开发过程更加关注系统的核心功能，同时可以很容易做到开发时的任务划分，同时使项目代码的可读性大大提升。
权限模型的常量定义：一个系统里最常见的需求莫过于权限、角色，我们需要两个类，一个表明都有什么权限（例如：删除帖子权限、编辑帖子权限，等等）;另一个类表明，各个角色都有什么权限。
这样子相当于定义了一个权限和角色模型。
拦截器与注解：拦截器（Invocation）在在流行的开源框架中很常见，依赖的技术就是Java的动态代理。
许多流行的框架都提供实现拦截器的接口，可以很简单就实现一个拦截器，此文不表如何实现。
注解（Annotations）是JAVA在5.0后引入的特性，它引入的目的是为了替代一些简单的配置到java代码里，而不用原来的xml。
注解请求示例：一般的框架，都会有一个controller类，以下用伪代码表示：public class ThreadsController{@PriCheckRequired({MemberPrivilegeIdentity.CREATE_THREAD})public String createThread(){return "createThread";}}如代码中所示，一个controller里的一个method对应一个URL请求（例中所示为创建帖子）。
