基于組件和攔截器的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.