基于组件和拦截器的Web系统权限设计与实现

赵秀霞+付秀丽

摘要： 权限组件让组件具有自省性，组件能够智能地判断自己的表现形式，不需要依赖于业务程序自身的控制，使其自身的独立性、重用性和易用性大大提高；权限拦截器则可以对访问进行统一拦截，统一判断权限，并能够根据需要随意“插拔”。通过权限组件与权限拦截器的配合工作，程序开发人员可以完全专注于业务的开发，无需意识到权限控制的存在。

关键词： 权限设计； 组件； 拦截器； AOP； Struts2

中图分类号： TN919⁃34； TP311.52； TP393.08 文献标识码： A 文章编号： 1004⁃373X（2014）08⁃0105⁃03

Permission design and implementation of Web system based on subassembly and interceptor

ZHAO Xiu⁃xia， FU Xiu⁃li

（School of Mechanical Engineering， University of Jinan， Jinan 250014， China）

Abstract：Permission subassembly has introspection property， can intelligently determine its own form of expression， and does not depend on the control of business program， so its independence， reusability and usability are greatly increased. The permission interceptor can intercept access， judge rights of applicants， and be able to be free to "plug". By cooperation with the permission subassembly and interceptor， developers can fully concentrate their efforts on the development of the business program， but do not consider the access control.

Keywords： permission design； subassembly； interceptor； AOP； Struts2

从权限控制项目的角度，Web系统的权限控制内容包括2部分：页面组件显示控制和请求拦截控制。只有同时控制这2个部分，才能真正做到完全的权限控制，并让使用者有较好的操作体验。目前大部分的权限控制大多围绕用户角色进行设计，本文在这种角色管理的基础上，提出了基于权限组件和权限拦截器的设计思想。现代软件设计更讲究解耦和重用，通过权限组件和权限拦截器，能够让权限控制独立于业务程序之外，开发人员可以将精力完全投入业务功能的实现，无需意识权限控制的存在。实际的权限控制，则是通过页面组件本身的自省性，自动根据访问者的权限，表现出不同的形式（如显示、不显示、不可用等）；同时，由于Web系统自身的特点，为了完全控制权限，还需要通过权限拦截器，对客户端的请求进行拦截，判断访问者是否具有访问权限，决定是否允许访问者继续执行当前的请求。

1角色访问控制

角色访问控制作为一种经典的权限解决方案[1]，在Web开发中得到了广泛的应用。本文设计实现的权限组件与权限拦截器，在组件和拦截器内部对访问者权限进行判断时，同样也采用的是基于角色的访问控制方式。所谓角色访问控制，无非就是采用分而治之的思想，将用户划分为不同角色，比如：经理、科长、职员等，再分别授予每种角色不同的权限，然后将全部用户划归到不同的角色中去，当用户向系统发出请求时，系统会首先查找出用户所属的角色，随后再查找判断该角色是否拥有所请求的资源的访问权限，既而决定是否继续执行请求或是中止请求。图1反映了这种访问控制的处理过程。

2权限组件

对于Web开发来讲，网页的表现基本是通过HTML语言的代码来诠释的[2]，然而HTML的各种标签，只提供了显示功能，并不具备更高的可控性，为了实现权限组件，需要使用基于JEE实现的标签（Tag）来代替纯粹的HTML标签，在其中通过增加权限判断的处理，从而增加标签的自省特性，最终让标签能够自动根据访问者的访问权限来决定自己的表现形式。

图1 访问控制处理过程图

本文通过给出一个权限按钮的实现过程来具体说明如何实现权限组件。根据JEE的标签开发规范，首先需要实现一个标签类，并通过标记库描述文件对标签类进行登记[3]。图2是标签中权限判断处理的流程图。

图2 标签中权限判断处理的流程图

对于需要根据权限判断决定是否显示的按钮，只需要像下面那样声明一个按钮标签，即可让按钮根据登录用户的权限来决定是否显示自己。

以下是参考代码：

<#⁃⁃ 引入自定义标签库 ⁃⁃>

<#assign ipcat=JspTaglibs["/WEB⁃INF/tld/ipcat⁃tags.tld"]>

…

<#⁃⁃ 使用自定义的权限按钮 ⁃⁃>

<@ipcat.button posturl="/customer/del" />

※ 这里使用的FreeMarker模板框架来渲染的表示层，同时Web层采用的是Struts2架构。

通过实现权限组件，不仅可以让组件自己决定是否显示，而且提高了组件的重用性。任何需要进行权限控制的页面组件，均可以通过权限组件来生成出相应的HTML标签代码，当然在生成之前必须通过权限组件的自省功能实现了权限控制，决定是否输出实际的HTML代码。

同样的，可以将HTML的常用标签，如链接、Label、输入框等都设计成JEE的标签，对于需要权限控制的HTML标签，直接使用自定义的标签就可以实现权限的自动控制了；同时，对于在线系统中最常见的“菜单”来说，也可以设计成自定义的标签，在其中进行菜单项的权限控制，这样就实现了可重用的具有权限判断功能的菜单组件了，其本身可以根据登录用户的不同，自动决定显示哪些菜单项、哪些菜单不可用（如：灰色并且点击无效）等特性。

3权限拦载器

不同于以往的C/S结构，在Web系统中，即使将按钮或链接隐藏了，系统使用者依然可以通过在浏览器的地址栏中直接输入地址的方式来访问没有显式链接的页面。这样，就算隐藏了按钮或链接也并不能彻底杜绝用户对于一些有特殊限定的网页的访问。为了避免用户通过地址栏输入地址直接访问系统想进行权限限定的资源，就必须设法在用户访问到这些资源之前，对用户进行识别，只有拥有访问权限的用户才能继续访问，而对于没有访问权限的用户就直接将页面跳转到非法请求页面。

为了实现以上处理，本文引入AOP的概念来进行说明权限拦截器的设计思路[4]。AOP是OOP的延续，是Aspect Oriented Programming的缩写，意思是面向切面编程[5]。

AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。在进行权限设计时，程序员在开发业务的过程中，为了限制系统访问者的访问，可能会将权限判断处理加到业务处理的入口处，虽然可以将权限判断的处理进行封装，但是这样做依然还是避免不了将权限的控制与纯粹的业务处理耦合在一起，不仅给维护带来了复杂性，也给业务本身增加了不相关性。如果借助AOP的思想，将权限控制归为一个切面，统一控制，让权限控制彻底剥离到业务处理之外，这样，程序员在开发的过程中，就可以完全专注于业务的开发，而权限控制则可以由专注于权限业务的程序员来设计和实现，并且可以根据客户的需要，在实现的业务处理之外，通过配置的方式，灵活地设定各业务的权限范围。图3可以进一步说明权限拦截器的设计思路。

请求A、B及C均想访问同一业务处理，但是在他们到达业务处理之前，权限拦截器将对请求统一拦截，当判断请求A和B的用户并不具有访问权限时，请求会直接转向非法页面呈现给客户，而对于请求C的用户由于通过了权限的验证，就可以有效地访问到业务处理，并进行相应的数据处理了。为了实现对于权限的统一切面处理，本文结合Struts2的拦截器技术，设计一个更加灵活的权限拦截器，不仅可以实现独立于业务处理之外的权限控制，还可以让权限控制做到可以任意“插拔”。

图3 权限控制示意图

拦截器（Interceptor）本身就是AOP思想的典型应用，同时它也是Struts2的一个显著特性，并且Struts2框架的大多数核心功能都是通过拦截器来实现的[6]，像避免表单重复提交、对象组装、验证、上传文件等。通过使用拦截器，能将系统中可以分离的统一处理，全部从系统中解耦，而不是分散到业务处理中，这样的功能类似于个人电脑的组装，变成了可插拔，需要某个功能时就“插入”一个拦截器，不需要某个功能时就“拔出”这个拦截器。了解了AOP及Struts2中拦截器的概念后，就可以实现一个基于Struts2拦截器处理机制的权限拦截器，并将权限拦截器通过配置文件与业务处理组装起来 （注意：不是通过程序固化在一起），这样的权限拦截器是完全独立于业务处理之外的权限控制，需要时就配置上，不需要时就不必配置。

当然，在权限拦截器的权限判断部分，和权限组件一样，也是基于角色进行判断的，先从Session中得到用户的角色，然后判断该角色是否具有对正在请求的地址的访问权限，从而决定是放行，还是直接转向非法访问的错误提示页面。很显然，权限拦截器在实现了独立于业务之外的权限控制功能之外，还具备可重用性，可以将权限拦截器反复“插入”到需要进行权限控制的业务处理之前。

4结语

通过权限组件和权限拦截器，实现了业务逻辑与权限的解耦，让权限完全独立于纯粹的业务功能之外，并且组件的重用性和拦截器的统一处理特性，都让权限控制变得非常简单灵活，利用Struts2框架设计的权限拦截器更可以实现权限控制的任意“插拔”，这一切，都将使系统的开发、维护和扩展也变得更加容易和轻松。

参考文献

[1] 刘强.基于角色的访问控制技术[M].广州：华南理工大学出版社，2010.

[2] Jon Duckett.Web编程入门经典：HTML，XHTML和CSS[M].

2版.北京：清华大学出版社，2010.

[3] 邹化，方卫宁，邹蓉.Servlet/JSP程序设计技术与实现[M].北京：人民邮电出版社，2001.

[4] WALLS Craig， BREIDENBACH Ryan. Spring in Action [M]. [S.l.]： Manning Publications， 2006.

[5] 吴炜煜.面向对象分析设计与编程：OOA/OOD/OOP/AOP[M].

2版.北京：清华大学出版社，2007.

[6] 孙鑫.Struts 2 深入详解[M].北京：电子工业出版社，2008.

AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。在进行权限设计时，程序员在开发业务的过程中，为了限制系统访问者的访问，可能会将权限判断处理加到业务处理的入口处，虽然可以将权限判断的处理进行封装，但是这样做依然还是避免不了将权限的控制与纯粹的业务处理耦合在一起，不仅给维护带来了复杂性，也给业务本身增加了不相关性。如果借助AOP的思想，将权限控制归为一个切面，统一控制，让权限控制彻底剥离到业务处理之外，这样，程序员在开发的过程中，就可以完全专注于业务的开发，而权限控制则可以由专注于权限业务的程序员来设计和实现，并且可以根据客户的需要，在实现的业务处理之外，通过配置的方式，灵活地设定各业务的权限范围。图3可以进一步说明权限拦截器的设计思路。

请求A、B及C均想访问同一业务处理，但是在他们到达业务处理之前，权限拦截器将对请求统一拦截，当判断请求A和B的用户并不具有访问权限时，请求会直接转向非法页面呈现给客户，而对于请求C的用户由于通过了权限的验证，就可以有效地访问到业务处理，并进行相应的数据处理了。为了实现对于权限的统一切面处理，本文结合Struts2的拦截器技术，设计一个更加灵活的权限拦截器，不仅可以实现独立于业务处理之外的权限控制，还可以让权限控制做到可以任意“插拔”。

图3 权限控制示意图

拦截器（Interceptor）本身就是AOP思想的典型应用，同时它也是Struts2的一个显著特性，并且Struts2框架的大多数核心功能都是通过拦截器来实现的[6]，像避免表单重复提交、对象组装、验证、上传文件等。通过使用拦截器，能将系统中可以分离的统一处理，全部从系统中解耦，而不是分散到业务处理中，这样的功能类似于个人电脑的组装，变成了可插拔，需要某个功能时就“插入”一个拦截器，不需要某个功能时就“拔出”这个拦截器。了解了AOP及Struts2中拦截器的概念后，就可以实现一个基于Struts2拦截器处理机制的权限拦截器，并将权限拦截器通过配置文件与业务处理组装起来 （注意：不是通过程序固化在一起），这样的权限拦截器是完全独立于业务处理之外的权限控制，需要时就配置上，不需要时就不必配置。

当然，在权限拦截器的权限判断部分，和权限组件一样，也是基于角色进行判断的，先从Session中得到用户的角色，然后判断该角色是否具有对正在请求的地址的访问权限，从而决定是放行，还是直接转向非法访问的错误提示页面。很显然，权限拦截器在实现了独立于业务之外的权限控制功能之外，还具备可重用性，可以将权限拦截器反复“插入”到需要进行权限控制的业务处理之前。

4结语

通过权限组件和权限拦截器，实现了业务逻辑与权限的解耦，让权限完全独立于纯粹的业务功能之外，并且组件的重用性和拦截器的统一处理特性，都让权限控制变得非常简单灵活，利用Struts2框架设计的权限拦截器更可以实现权限控制的任意“插拔”，这一切，都将使系统的开发、维护和扩展也变得更加容易和轻松。

参考文献

[1] 刘强.基于角色的访问控制技术[M].广州：华南理工大学出版社，2010.

[2] Jon Duckett.Web编程入门经典：HTML，XHTML和CSS[M].

2版.北京：清华大学出版社，2010.

[3] 邹化，方卫宁，邹蓉.Servlet/JSP程序设计技术与实现[M].北京：人民邮电出版社，2001.

[4] WALLS Craig， BREIDENBACH Ryan. Spring in Action [M]. [S.l.]： Manning Publications， 2006.

[5] 吴炜煜.面向对象分析设计与编程：OOA/OOD/OOP/AOP[M].

2版.北京：清华大学出版社，2007.

[6] 孙鑫.Struts 2 深入详解[M].北京：电子工业出版社，2008.

AOP实际是GoF设计模式的延续，设计模式孜孜不倦追求的是调用者和被调用者之间的解耦，AOP可以说也是这种目标的一种实现。在进行权限设计时，程序员在开发业务的过程中，为了限制系统访问者的访问，可能会将权限判断处理加到业务处理的入口处，虽然可以将权限判断的处理进行封装，但是这样做依然还是避免不了将权限的控制与纯粹的业务处理耦合在一起，不仅给维护带来了复杂性，也给业务本身增加了不相关性。如果借助AOP的思想，将权限控制归为一个切面，统一控制，让权限控制彻底剥离到业务处理之外，这样，程序员在开发的过程中，就可以完全专注于业务的开发，而权限控制则可以由专注于权限业务的程序员来设计和实现，并且可以根据客户的需要，在实现的业务处理之外，通过配置的方式，灵活地设定各业务的权限范围。图3可以进一步说明权限拦截器的设计思路。

请求A、B及C均想访问同一业务处理，但是在他们到达业务处理之前，权限拦截器将对请求统一拦截，当判断请求A和B的用户并不具有访问权限时，请求会直接转向非法页面呈现给客户，而对于请求C的用户由于通过了权限的验证，就可以有效地访问到业务处理，并进行相应的数据处理了。为了实现对于权限的统一切面处理，本文结合Struts2的拦截器技术，设计一个更加灵活的权限拦截器，不仅可以实现独立于业务处理之外的权限控制，还可以让权限控制做到可以任意“插拔”。

图3 权限控制示意图

拦截器（Interceptor）本身就是AOP思想的典型应用，同时它也是Struts2的一个显著特性，并且Struts2框架的大多数核心功能都是通过拦截器来实现的[6]，像避免表单重复提交、对象组装、验证、上传文件等。通过使用拦截器，能将系统中可以分离的统一处理，全部从系统中解耦，而不是分散到业务处理中，这样的功能类似于个人电脑的组装，变成了可插拔，需要某个功能时就“插入”一个拦截器，不需要某个功能时就“拔出”这个拦截器。了解了AOP及Struts2中拦截器的概念后，就可以实现一个基于Struts2拦截器处理机制的权限拦截器，并将权限拦截器通过配置文件与业务处理组装起来 （注意：不是通过程序固化在一起），这样的权限拦截器是完全独立于业务处理之外的权限控制，需要时就配置上，不需要时就不必配置。

当然，在权限拦截器的权限判断部分，和权限组件一样，也是基于角色进行判断的，先从Session中得到用户的角色，然后判断该角色是否具有对正在请求的地址的访问权限，从而决定是放行，还是直接转向非法访问的错误提示页面。很显然，权限拦截器在实现了独立于业务之外的权限控制功能之外，还具备可重用性，可以将权限拦截器反复“插入”到需要进行权限控制的业务处理之前。

4结语

通过权限组件和权限拦截器，实现了业务逻辑与权限的解耦，让权限完全独立于纯粹的业务功能之外，并且组件的重用性和拦截器的统一处理特性，都让权限控制变得非常简单灵活，利用Struts2框架设计的权限拦截器更可以实现权限控制的任意“插拔”，这一切，都将使系统的开发、维护和扩展也变得更加容易和轻松。

参考文献

[1] 刘强.基于角色的访问控制技术[M].广州：华南理工大学出版社，2010.

[2] Jon Duckett.Web编程入门经典：HTML，XHTML和CSS[M].

2版.北京：清华大学出版社，2010.

[3] 邹化，方卫宁，邹蓉.Servlet/JSP程序设计技术与实现[M].北京：人民邮电出版社，2001.

[4] WALLS Craig， BREIDENBACH Ryan. Spring in Action [M]. [S.l.]： Manning Publications， 2006.

[5] 吴炜煜.面向对象分析设计与编程：OOA/OOD/OOP/AOP[M].

2版.北京：清华大学出版社，2007.

[6] 孙鑫.Struts 2 深入详解[M].北京：电子工业出版社，2008.