畢業(yè)設(shè)計-網(wǎng)站系統(tǒng)rbac的設(shè)計與實現(xiàn)

1、<p><b>　　本科畢業(yè)設(shè)計論文</b></p><p>　　題 目 網(wǎng)站系統(tǒng)RBAC的設(shè)計與實現(xiàn) </p><p>　　英文題目 Design and Implementation of </p><p>　　RBAC of Web System </p><p>　　學

2、院 經(jīng)濟管理學院 </p><p>　　專 業(yè) </p><p>　　學生姓名 </p><p>　　導師姓名 </p><p><b>　　摘 要<

3、/b></p><p>　　隨著Internet及信息技術(shù)的飛速發(fā)展，信息共享應(yīng)用日益廣泛與深入，同時網(wǎng)絡(luò)安全問題也日漸突出。安全性問題越來越被大多數(shù)人所重視，保護網(wǎng)絡(luò)資源不被非法使用和非法訪問已經(jīng)成為人們首要考慮的問題之一。為了解決這個矛盾人們提出了許多安全策略，訪問控制策略就是在保障授權(quán)用戶能獲取所需要資源的同時拒絕非授權(quán)用戶的安全機制，是保護網(wǎng)絡(luò)資源在一個相對安全的環(huán)境中進行的一個有效方法。</

4、p><p>　　安全訪問控制策略一般有三種：自主型訪問控制方法、強制型訪問控制方法和基于角色的訪問控制方法(RBAC)。其中，自主式太弱，強制式太強，二者工作量大，不便于管理?；诮巧脑L問控制方法是目前公認的解決大型企業(yè)的統(tǒng)一資源訪問控制的有效方法。本文從基于角色的訪問控制模型的基本理論出發(fā)，闡述了該模型的基本原理和特點，并從軟件的角度分析了網(wǎng)站系統(tǒng)RBAC模式的需求，給出了一套基于RBAC模式的設(shè)計與實現(xiàn)方案，設(shè)

5、計方案在分析RBAC在企業(yè)系統(tǒng)中應(yīng)用的同時，對用戶，角色，以及權(quán)限之間的關(guān)系進行了詳細的論述，并在數(shù)據(jù)庫結(jié)構(gòu)中定義了它們之間的關(guān)系。利用當前最流行的MVC框架struts2對不同用戶所具有的權(quán)限進行了攔截，使網(wǎng)絡(luò)資源在一個合法安全的環(huán)境中被訪問。論文的意義在于提出并實現(xiàn)了一個RBAC模型框架，這對于將來要開發(fā)類似系統(tǒng)的工程具有一定的參考價值。</p><p>　　關(guān)鍵詞：訪問控制 角色 權(quán)限 基于角色

6、的訪問控制</p><p><b>　　Abstract</b></p><p>　　With the rapid development of computer technology, Information sharing has been used widely and in depth, the problem of network security is i

7、ncreasingly highlighted. Security problems are increasingly valued by most people, to protect network resources from unauthorized use and unauthorized access has become one of the primary considerations. To resolve this

8、conflict a number of security policies have been proposed, Access control policy is one of the security mechanisms to protect that the aut</p><p>　　Generally, there exist three kinds of Security access contr

9、ol policy: Autonomous access control, Mandatory access control, Role-based access control. the autonomous is too weak but the Mandatory is too strong, Both the workload is not manageable. Role-based access control method

10、 is widely recognized as an effective way of solving control access to resources of large enterprises. In this paper, we start from the Basic theory of Role-based access control; Set forth the basic principles and charac

11、t</p><p>　　Keywords: Access Control Role Permission Role-based access control</p><p><b>　　目錄</b></p><p>　　第一章 引 言1</p><p>　　1.1研究背景1</p>&l

12、t;p>　　1.2 發(fā)展現(xiàn)狀2</p><p>　　1.3論文組織形式3</p><p>　　第二章RBAC及相關(guān)理論技術(shù)5</p><p>　　2.1 訪問控制機制概述5</p><p>　　2.2 訪問控制策略5</p><p>　　2.2.1自主訪問控制(Discretionary Ac

13、cess Control，DAC)6</p><p>　　2.2.2強制訪問控制(Mandatory Access Control，MAC)6</p><p>　　2.2.3基于角色訪問控制(Role-based access control，RBAC)7</p><p>　　2.3 RBAC訪問控制策略的提出8</p><p>　

14、　2.3.1 RBAC基本概念8</p><p>　　2.3.2 基于角色的訪問控制基本思想9</p><p>　　2.4 基于角色訪問控制RBAC的優(yōu)勢10</p><p>　　第三章 MVC框架與Struts2概述13</p><p>　　3.1 MVC理論概述13</p><p>　　3.1.1

15、MVC概念13</p><p>　　3.1.2 MVC工作過程13</p><p>　　3.1.3 MVC框架的優(yōu)缺點分析14</p><p>　　3.2 MVC框架——Struts216</p><p>　　3.2.1 Struts2的誕生16</p><p>　　3.2.2 Struts2核心工作流程及

16、原理19</p><p>　　3.3 Struts2的攔截器22</p><p>　　3.4 本章小結(jié)23</p><p>　　第四章 RBAC的總體設(shè)計25</p><p>　　4.1 總體目標25</p><p>　　4.2 功能需求26</p><p>　　4.3

17、數(shù)據(jù)庫結(jié)構(gòu)的設(shè)計27</p><p>　　4.4 本章小結(jié)29</p><p>　　第五章 RBAC的詳細設(shè)計與實現(xiàn)31</p><p>　　5.1 Struts2的主要配置文件31</p><p>　　5.2 登錄界面的設(shè)計33</p><p>　　5.3 登錄處理頁面(LoginAction)

18、34</p><p>　　5.4 用戶的CRUD操作請求35</p><p>　　5.5 攔截器部分36</p><p>　　5.6 功能頁面action37</p><p>　　5.7 本章小結(jié)38</p><p>　　第六章 總結(jié)與展望39</p><p><b&g

19、t;　　致謝41</b></p><p><b>　　參考文獻42</b></p><p><b>　　第一章 引 言</b></p><p><b>　　1.1研究背景</b></p><p>　　在Internet的出現(xiàn)和發(fā)展給我們帶來方便的同時，一些安

20、全性問題也突現(xiàn)了出來，因為網(wǎng)絡(luò)平臺的開放性，使得數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸存在許多安全隱患，可能造成信息的丟失，篡改，泄密，以及對信息系統(tǒng)造成的騷擾，破壞等嚴重后果。因此，網(wǎng)絡(luò)信息安全問題己引起人們的廣泛關(guān)注，并且已經(jīng)成為當前網(wǎng)絡(luò)技術(shù)研究的重點。</p><p>　　為了解決這個矛盾，運用好網(wǎng)絡(luò)信息平臺這把雙刃劍，人們提出了許多安全策略。這其中就包括在信息系統(tǒng)中使用訪問控制(Access Control)來保證信息的安全

21、[1]。訪問控制是所有系統(tǒng)都必不可少的模塊，但是各種不同的應(yīng)用系統(tǒng)在訪問控制的方式上各有特色，即使相同類型的系統(tǒng)在控制方式上也各有區(qū)別，這使得訪問控制一直是系統(tǒng)開發(fā)中比較復(fù)雜的部分。現(xiàn)在的電子商務(wù)，電子政務(wù)等商業(yè)系統(tǒng)越來越大型化，協(xié)同化，不但需要保護系統(tǒng)資源不受侵犯，更需要給適當?shù)脑L問者提供最大化的服務(wù)，這就要求系統(tǒng)必須要能夠控制：哪些訪問者能夠訪問系統(tǒng)的信息，訪問者訪問的是“什么信”，訪問者對他所訪問的數(shù)據(jù)擁有什么樣的“權(quán)限”[2]

22、?？梢杂谩癢ho對What(Which)是否能進行How的操作”來表述應(yīng)用系統(tǒng)權(quán)限的需求。</p><p>　　當前，不同領(lǐng)域的權(quán)限管理模塊在具體的實現(xiàn)時具有一定的相似性。對不同的應(yīng)用系統(tǒng)，開發(fā)不同的權(quán)限管理模塊會造成重復(fù)開發(fā)，軟件的重復(fù)利用率低下，并且?guī)碥浖罄^維護困難等問題。在企業(yè)中，不同的應(yīng)用系統(tǒng)都擁有一套獨立的權(quán)限管理系統(tǒng)。每套權(quán)限管理系統(tǒng)只滿足自身系統(tǒng)的權(quán)限管理需要，無論在數(shù)據(jù)存儲、權(quán)限訪問和權(quán)限控制

23、機制等方面都可能不一樣，這種不一致性存在如下弊端：</p><p>　　a.系統(tǒng)管理員需要維護多套權(quán)限管理系統(tǒng)，重復(fù)勞動。</p><p>　　b.用戶管理、組織機構(gòu)等數(shù)據(jù)重復(fù)維護，數(shù)據(jù)一致性、完整性得不到保證。</p><p>　　c.由于權(quán)限管理系統(tǒng)的設(shè)計不同，概念解釋不同，采用的技術(shù)有差異，權(quán)限管理系統(tǒng)之間的集成存在問題，實現(xiàn)單點登錄難度十分大，也給企業(yè)構(gòu)建企

24、業(yè)門戶帶來困難。</p><p>　　RBAC的出現(xiàn)在很大程度上改善了這一狀況，它引入了Role的概念,目的是為了隔離User(即動作主體，Subject)與Privilege(權(quán)限，表示對Resource的一個操作，即Operation+Resource)。Role作為一個用戶(User)與權(quán)限(Privilege)的代理層，解耦了權(quán)限和用戶的關(guān)系，所有的授權(quán)應(yīng)該給予Role而不是直接給User?；诮巧脑L問

25、控制方法(RBAC)有兩大顯著特征是：其一、由于角色/權(quán)限之間的變化比角色/用戶關(guān)系之間的變化相對要慢得多，減小了授權(quán)管理的復(fù)雜性，降低管理開銷。其二、靈活地支持企業(yè)的安全策略，并對企業(yè)的變化有很大的伸縮性。 </p><p>　　因此，本論文決定在現(xiàn)有訪問控制模型的基礎(chǔ)上設(shè)計和實現(xiàn)一個具有良好通用性的、可擴展的權(quán)限管理模塊。這對于將來要開發(fā)或正在開發(fā)類似系統(tǒng)的開發(fā)者具有很高的參考價值。

26、 </p><p><b>　　1.2 發(fā)展現(xiàn)狀</b></p><p>　　RBAC研究最初的學術(shù)文章是1992年美國NIST的研究人員David Ferraiolo和Richard Kulm發(fā)表的[3]。國內(nèi)最早的相關(guān)學術(shù)論文是1994年華中理工大學(現(xiàn)在的華科)馬建平的碩士學位論文《一種無干擾的訪問控制模型》。在RBAC研究過程中，1996年

27、美國George Mason大學的Ravi Sandhu教授在IEEE computer上發(fā)表了一篇學術(shù)文章[4]，在該文中Sandhu教授正式提出了RBAC96模型家族，它是RBAC模型研究的里程碑，為進一步地深入研究奠定了基礎(chǔ)。此后國內(nèi)外研究者在RBAC96模型家族的基礎(chǔ)上提出了許多擴展模型。目前國外RBAC研究機構(gòu)主要是美國NIST和George Mansion Univ．LIST實驗室(Prof．Ravi Sandhu)。NIS

28、T主要是進行RBAC及其相關(guān)模型的標準化工作，LIST側(cè)重于對RBAC、RBDM及其擴展模型的創(chuàng)建、形式化描述，評價分析，以及在web中的應(yīng)用等。國內(nèi)主要是中國科學院軟件研究所和華中科技大學計算機科學與工程系，他們正在對RBAC模型擴展和應(yīng)用方面進行深入的研究。RBAC作為信息安全領(lǐng)域訪</p><p>　　當然，即便理論已經(jīng)趨于成熟，但是依然有研究的空間，對RBAC的理論研究，尤其是RBAC在具體工作背景(體系

29、)下完備的形式化描述工作，依然是今后研究的關(guān)鍵。可以說訪問控制的形式化描述是一項極其重要的、頗有理論意義和研究價值的工作。</p><p>　　1.3論文組織形式</p><p>　　首先提出課題研究的背景及現(xiàn)狀，分析了基于角色的訪問控制(RBAC)在企業(yè)系統(tǒng)中的應(yīng)用以及它給系統(tǒng)管理帶來的便捷。分析了企業(yè)系統(tǒng)的結(jié)構(gòu)，針對系統(tǒng)中用戶(user)，角色(roles)，以及權(quán)限之間的多對多關(guān)系

30、進行了數(shù)據(jù)庫結(jié)構(gòu)的設(shè)計。為了實現(xiàn)不同的角色只能具有相應(yīng)的訪問權(quán)限，使用到了struts提供的攔截器(interceptor)功能，成功的對用戶的訪問權(quán)限進行限制，保證了系統(tǒng)安全。另外文章中還對MVC設(shè)計模式作了簡單的介紹，運用MVC思想對RBAC的各個具體模塊進行了設(shè)計與實現(xiàn)。后續(xù)內(nèi)容需要對RBAC具體的的管理功能作進一步的論述。</p><p>　　論文主要分為六個章節(jié)，第一章是引言部分，簡單的介紹了一下目前R

31、BAC在國內(nèi)外的研究情況和發(fā)展現(xiàn)狀以及它在實際問題中的應(yīng)用情況。在第二章節(jié)中，對訪問控制策略以及RBAC相關(guān)理論技術(shù)作了具體的闡述和說明 。在論文的第三章，穿插了對MVC設(shè)計的介紹，本文主要用到了這一方面的知識，因此有必要對MVC具體的工作過程以及相關(guān)技術(shù)進行一下論述，這里只是對其中之一的Struts2進行了比較系統(tǒng)的介紹。第四章主要是對RBAC進行了總體設(shè)計與分析，具體包括對功能需求的分析，RBAC具體的工作流程以及對數(shù)據(jù)庫結(jié)構(gòu)的設(shè)計

32、。第五章就是對RBAC具體的設(shè)計與實現(xiàn)，包括代碼的編寫以及最后實現(xiàn)的效果。最后一章就是對全文進行一個總結(jié)，分析一下可能存在的不足和需進一步努力的方向。</p><p>　　第二章RBAC及相關(guān)理論技術(shù)</p><p>　　當前信息安全技術(shù)主要包括密碼技術(shù)、身份認證、訪問控制、入侵檢測、風險分析與評估等諸多方面。在實際應(yīng)用中，這些安全技術(shù)相互支持與協(xié)作，各自解決安全問題的某一方面，但目前人

33、們關(guān)注的重點是密碼技術(shù)、身份認證、入侵檢測等，訪問控制技術(shù)沒有得到足夠的重視。事實上訪問控制技術(shù)是一個安全信息系統(tǒng)不可或缺的安全措施，對保護主機系統(tǒng)和應(yīng)用系統(tǒng)的安全都有重要意義[5]。本章主要介紹訪問控制機制和策略，比較了傳統(tǒng)的訪問控制模型：自主訪問控制與強制訪問控制，重點討論基于角色的訪問控制策略和模型，對相關(guān)理論進行研究，并在經(jīng)典RBAC模型的基礎(chǔ)上進行擴展和改進，提出新的模型框架——通用RBAC模型，給出了模型設(shè)計目標，設(shè)計原則和

34、模型定義。</p><p>　　2.1 訪問控制機制概述</p><p>　　訪問控制是計算機網(wǎng)絡(luò)信息安全管理的主要策略，是通過某種途徑顯式的準許或限制信息資源訪問能力及范圍的一種方法[6]，訪問控制技術(shù)是建立在身份認證的基礎(chǔ)上，通過限制用戶對關(guān)鍵資源的訪問，防止非法用戶的入侵或合法用戶對資源的誤用或濫用，因而能保證資源受控地、合法地使用。訪問控制是實施允許被授權(quán)的主體對某些客體的訪問，

35、同時拒絕向非授權(quán)的主體提供服務(wù)的策略。這里主體(subject)可以是人，也可以是任何主動發(fā)出訪問請求的智能體，包括程序、進程、服務(wù)等；客體(object)包括所有受訪問控制保護的資源，在不同應(yīng)用背景下可以有相當廣泛的定義，比如在操作系統(tǒng)中可以是一段內(nèi)存空間，在數(shù)據(jù)庫里可以是一個表中的記錄，在Web上可以是一個頁面。訪問的方式取決于客體的類型，一般是對客體的一種操作，比如請求內(nèi)存空間，修改表中一記錄，瀏覽頁面等。通過對主體的授權(quán)，計算機

36、系統(tǒng)可以在一個合法的范圍內(nèi)被使用，從而保證了客體被正確合理的訪問，同時也維護了被授權(quán)主體的利益。這是訪問控制的目的，同時也是一個安全系統(tǒng)所必須具備的特性。</p><p>　　2.2 訪問控制策略</p><p>　　2.2.1自主訪問控制(Discretionary Access Control，DAC)</p><p>　　DAC是最常用的一類模型，最早出現(xiàn)在

37、70初期的分時系統(tǒng)中，是一種多用戶環(huán)境下最常用的一種訪問控制技術(shù)，在目前流行的UNIX類操作系統(tǒng)中被普遍采用。它是基于客體一主體間的所屬關(guān)系，根據(jù)主體所屬的組來限制對客體的訪問。所謂自主，是指主體可以根據(jù)自己的意愿，將訪問控制權(quán)限授予其它主體，或從其它主體那里收回訪問權(quán)限。也就是說，DAC的基本思想是將用戶作為客體的擁有者，他有權(quán)自主地決定哪些用戶可以訪問他的客體。自主訪問控制是基于用戶的，具有很高的靈活性，適合于各類操作系統(tǒng)和應(yīng)用程序

38、，特別是在商業(yè)和工業(yè)領(lǐng)域。譬如用戶需要在沒有系統(tǒng)管理員介入的情況下，擁有設(shè)定其它用戶訪問其所控制信息資源的能力。在這種情況下，用戶對信息的訪問控制是動態(tài)的，這時采用自主訪問控制就比較合適。但是自主訪問控制策略也存在不能保證信息傳輸?shù)陌踩缘入[患，它無法抵御特洛伊木馬的攻擊。在自主訪問控制中，一旦帶有特洛伊木馬的應(yīng)用程序被激活，系統(tǒng)無法辨別出哪些是用戶所需的正常操作，哪些操作是特洛伊木馬在起作用。 </p>&

39、lt;p>　　自主訪問控制通常包括目錄式訪問控制、訪問控制表、訪問控制矩陣和面向過程的訪問控制等方式。為了保證安全，自主訪問控制策略的默認參考設(shè)置是拒絕訪問的，以提高信息的安全性。</p><p>　　2.2.2強制訪問控制(Mandatory Access Control，MAC)</p><p>　　MAC[7]是一種不允許主體干涉的訪問控制策略。強制訪問控制是根據(jù)客體中信息的敏

40、感標簽和訪問敏感信息的主體的訪問級對客體訪問實行限制的一種方法，通過強加一些不可逾越的訪問控制，系統(tǒng)可以防止某一些類型的特洛伊木馬的攻擊。在強制訪問控制模型中，主體不能修改訪問權(quán)，也不能將自己的訪問權(quán)授予其它主體，而且系統(tǒng)對主體和客體都分配一個特殊的安全屬性，而這一屬性一般不能更改，系統(tǒng)通過比較主體和客體的安全屬性來決定一個主體是否能夠訪問某個客體。用戶的程序不能改變他自己及任何其它客體的安全屬性。例如，在將安全等級作為安全屬性的強制訪

41、問控制模型中，可以將安全等級分為多個級別[8]，譬如：最高秘密級(Top Secret)、秘密級(Secret)、機密級(Confidential)</p><p>　　以及無級別級(unclassified)，并確定它們的高低偏序關(guān)系為TS>S>C>U。這些安全級別可以支配同一級別或低一級別的物件。當一個主體訪問一個客體時，必須符合各自的安全級別要求，特別是如下兩個原則：</p>

42、<p>　　(1)下讀：主體的安全級別必須高于或等于被讀客體的級別；</p><p>　　(2)上寫：主體安全級別必須低于或等子被寫客體的級別。</p><p>　　這些規(guī)則可以防止高級別對象的信息傳播到低級別的對象中，這樣系統(tǒng)中的信息只能在同一層次傳送或流向更高一級。</p><p>　　強制訪問控制在軍事和市政安全領(lǐng)域應(yīng)用較多。例如，某些對安全要求很

43、高的操作系統(tǒng)中規(guī)定了強制訪問控制策略，安全級別由系統(tǒng)管理員按照嚴格程序設(shè)</p><p>　　置，不允許用戶修改。如果系統(tǒng)設(shè)置的用戶安全級別不允許用戶訪問某個文件，那么即使該用戶是該文件的擁有者也不能進行訪問。強制訪問控制的安全性比自主訪問控制的安全性更高，但靈活性要差一些。</p><p>　　2.2.3基于角色訪問控制(Role-based access control，RBAC)&l

44、t;/p><p>　　基于角色訪問控制模型是目前國際上流行的先進的安全訪問控制方法[9]。它通過分配和取消角色來完成用戶權(quán)限的授予和取消，并且提供角色分配以及角色轉(zhuǎn)換規(guī)則。安全管理人員根據(jù)需要定義各種角色，并賦予合適的訪問權(quán)限，而用戶根據(jù)其責任和資歷被指派為不同的角色。這樣，整個訪問控制過程就分成兩個部分，即訪問權(quán)限與角色相關(guān)聯(lián)，角色再與用戶關(guān)聯(lián)，從而實現(xiàn)了用戶與訪問權(quán)限的邏輯分離。由于實現(xiàn)了用戶與訪問權(quán)限的邏輯分離

45、，基于角色的策略極大的方便了權(quán)限管理。例如，如果一個用戶的職位發(fā)生變化，只要將用戶當前的角色去掉，加入代表新職務(wù)或新任務(wù)的角色即可。研究表明，角色與權(quán)限之間的變化比角色與用戶關(guān)系之間的變化相對要慢得多，并且給用戶分配角色不需要很多技術(shù)，可以由行政管理人員來執(zhí)行；而給角色配置權(quán)限的工作比較復(fù)雜，需要一定的技術(shù)，可以由專門的技術(shù)人員來承擔，但是不給予他們?yōu)橛脩舴峙浣巧臋?quán)限，這與現(xiàn)實中的情況正好一致</p><p>

46、　　基于角色訪問控制可以很好的描述角色層次關(guān)系，實現(xiàn)最小特權(quán)原則和職責分離原則。</p><p>　　2.3 RBAC訪問控制策略的提出</p><p>　　RBAC模型在權(quán)限和用戶之間增加了角色，用戶與特定的一個或多個角色相聯(lián)系，角色和一個或多個權(quán)限相聯(lián)系，角色可以根據(jù)實際的工作需要生成或取消，大大降低了系統(tǒng)的復(fù)雜度。同時RBAC還體現(xiàn)了系統(tǒng)的組織結(jié)構(gòu)，簡潔并具有靈活性，大大降低了系統(tǒng)

47、管理員誤操作的可能性。根據(jù)角色的優(yōu)點，通過使用角色很大程度上改進了在管理性和安全性上的不足。</p><p>　　2.3.1 RBAC基本概念</p><p>　　用戶(User)：用戶就是一個可以獨立訪問計算機系統(tǒng)中的數(shù)據(jù)或者用數(shù)據(jù)表示的其它資源的主體，我們用USERS表示一個用戶集合。用戶在一般情況下是指人。</p><p>　　角色(Role)：角色是指一個組

48、織或任務(wù)中的工作或位置，它代表了一種資格、權(quán)利和責任。我們用ROLES表示一個角色集合。</p><p>　　權(quán)限(Privilege)：權(quán)限是對計算機系統(tǒng)中的數(shù)據(jù)或者用數(shù)據(jù)表示的其它資源進行訪問的許可。我們用PRIVILEGE表示一個權(quán)限集合。可分為對象訪問控制和數(shù)據(jù)訪問控制兩種。</p><p>　　主體(Subject)：即可以向應(yīng)用系統(tǒng)發(fā)出應(yīng)用請求的任何實體，包括各種用戶、其它與本

49、系統(tǒng)有接口的應(yīng)用程序、非法入侵者。系統(tǒng)必須具有識別主體的能力，接口實際上也是由用戶登記的，故主要問題是校驗用戶身份的合法性，系統(tǒng)應(yīng)建立用戶鑒別機構(gòu)以驗證用戶身份。</p><p>　　客體(Object)：被訪問的對象。通?？梢允潜徽{(diào)用的程序、進程，要存取的數(shù)據(jù)、信息，要訪問的文件、系統(tǒng)或各種網(wǎng)絡(luò)設(shè)備、設(shè)施等資源。</p><p>　　用戶委派(User Assignment)：用戶委派是

50、USERS與ROLES之間的一個二元關(guān)系，我們用關(guān)系(U,R)來表示用戶U被委派了一個角色R。</p><p>　　權(quán)限配置(Privilege Assignment)：權(quán)限配置是ROLES與PRIVILEGE之間的一個二元關(guān)系，我們用(R,P)來表示角色R擁有一個權(quán)限P。</p><p>　　角色激活(Role Activation)：是指用戶從被授權(quán)的角色中選擇一組角色的過程。用戶訪問

51、的時候?qū)嶋H具有的角色只包含激活后的角色，未激活的角色在訪問中不起作用。相對于靜態(tài)的角色授權(quán)來說，角色激活是一種動態(tài)的過程，提供了相當?shù)撵`活性。</p><p>　　會話(Session)：對應(yīng)于一個用戶和一組激活的角色，表征用戶進行角色激活的過程。一個用戶可以進行幾次會話，在每次會話中激活不同的角色，這樣用戶也將具有不同的訪問權(quán)限。用戶必須通過會話才能激活角色。</p><p>　　它們之

52、間的關(guān)系如圖2.1</p><p>　　圖2.1 RBAC操作關(guān)系圖</p><p>　　2.3.2 基于角色的訪問控制基本思想</p><p>　　RBAC的基本思想可簡單地用圖2.2表示[10]，即把整個訪問控制過程分為兩步：</p><p>　　1)角色指派，即用戶委派(U,R)，使用戶與角色相關(guān)聯(lián)，通過角色使</p>&

53、lt;p>　　用戶與訪問權(quán)限在邏輯上分離。</p><p>　　2)權(quán)限指派，即權(quán)限配置(R,P)，使角色與訪問權(quán)限相關(guān)聯(lián)。</p><p>　　圖2.2 RBAC關(guān)系圖</p><p>　　由于RBAC實現(xiàn)了用戶與訪問權(quán)限的邏輯分離，因此它便于權(quán)限管理。例如，如果一個用戶的職位發(fā)生變化，只要將用戶當前的角色去掉，由代表新職務(wù)或新任務(wù)的角色代替即可，角色／權(quán)限

54、之間的變化比角色／用戶關(guān)系之間的變化相對要慢得多，并且委派用戶為某角色不需要很多技術(shù)，可以由行政管理人員來執(zhí)行，而配置權(quán)限到角色的工作比較復(fù)雜，需要一定的技術(shù)，可以由專門的技術(shù)人員來承擔，但是不給他們委派用戶的權(quán)限，這與現(xiàn)實中情況正好一致。</p><p>　　在兩種傳統(tǒng)訪問控制技術(shù)中，自主訪問控制將賦予或取消訪問權(quán)限的一部分權(quán)力留給用戶個人，這使得管理員難以確定哪些用戶對哪些資源有訪問權(quán)限，不利于實現(xiàn)統(tǒng)一的全局

55、訪問控制，而且容易出錯，也無法執(zhí)行動態(tài)的和復(fù)雜的安全政策；而強制訪問控制過于注重保密性，對系統(tǒng)連續(xù)工作能力、授權(quán)的可管理性等其他方面考慮不足[11]。</p><p>　　基于角色的訪問控制(Role Based Access Control, RBAC)是一種靈活、高效的訪問控制方法，它有效地克服了傳統(tǒng)訪問控制(DAC,MAC等)技術(shù)中存在的不足，可以減少授權(quán)管理的復(fù)雜性，降低管理開銷。RBAC在用戶和權(quán)限之間

56、引入了角色的概念，安全管理員根據(jù)實際需要定義各種角色，并設(shè)置和角色相對應(yīng)的訪問權(quán)限，而用戶根據(jù)其職責被指派為不同的角色[12]。這樣，訪問權(quán)限和角色相關(guān)聯(lián)，角色再與用戶關(guān)聯(lián)，使角色成為訪問控制中訪問主體和受控對象之間的一座橋梁。從而實現(xiàn)了用戶與訪問權(quán)限的邏輯分離。</p><p>　　2.4 基于角色訪問控制RBAC的優(yōu)勢</p><p>　　相比較其它的訪問控制策略，RBAC具有以下幾

57、點優(yōu)勢：</p><p><b>　　(一)便于授權(quán)管理</b></p><p>　　將角色作為一個橋梁，溝通于用戶和資源之間。對用戶的訪問授權(quán)轉(zhuǎn)變?yōu)閷巧氖跈?quán)，然后再將用戶與特定的角色聯(lián)系起來。一旦一個RBAC系統(tǒng)建立起來以后，主要的管理工作即為授權(quán)或取消用戶的角色。用戶的職責變化時，改變授權(quán)給他們的角色，也就改變了用戶的權(quán)限。而當組織的功能變化或演進時，只需刪除

58、角色的舊功能、增加新功能，或定義新角色，而不必更新每一個用戶的權(quán)限設(shè)置。</p><p><b>　　(二)便于角色劃分</b></p><p>　　為了提高效率，避免相同權(quán)限的重復(fù)設(shè)置，RBAC采用了角色繼承的概念，定義了這樣一些角色，它們有自己的屬性，但可能還繼承其它角色的屬性和權(quán)限。角色繼承把角色組織起來，能夠很自然地反映組織內(nèi)部人員之間的職權(quán)、責任關(guān)系。<

59、;/p><p>　　(三)便于賦予最小權(quán)限原則</p><p>　　所謂最小權(quán)限原則是指用戶所擁有的權(quán)力不能超過他執(zhí)行工作時所需的權(quán)限。實現(xiàn)最小權(quán)限原則，需分清用戶的工作內(nèi)容，確定執(zhí)行該工作的最小權(quán)限集，然后將用戶限制在這些權(quán)限范圍之內(nèi)。</p><p><b>　　(四)便于職責分離</b></p><p>　　對于某些特

60、定的操作集，某一個角色或用戶不可能同時獨立地完成所有這些操作，這時需要進行職責分離。職責分離可以有靜態(tài)和動態(tài)兩種實現(xiàn)方式。</p><p><b>　　(五)便于客體分類</b></p><p>　　RBAC可以根據(jù)用戶執(zhí)行的不同操作集來劃分不同的角色，對主體分類，同樣的，客體也可以實施分類。</p><p>　　第三章 MVC框架與Stru

61、ts2概述</p><p>　　MVC設(shè)計模式的出現(xiàn)不僅實現(xiàn)了功能模塊和顯示模塊的分離，同時還給系統(tǒng)的維護提供了很大的便利。</p><p>　　3.1 MVC理論概述</p><p>　　3.1.1 MVC概念</p><p>　　MVC設(shè)計模式中，M是指數(shù)據(jù)模型，V是指用戶界面(即頁面表示層)，C則是控制器。使用MVC的目的是將M和V實

62、現(xiàn)代碼分離，從而使同一個程序可以使用不同的表現(xiàn)形式。比如一批統(tǒng)計數(shù)據(jù)你可以分別用柱狀圖、餅圖來表示。C存在的目的則是確保M和V的同步，一旦M改變，V應(yīng)該同步更新。 </p><p>　　模型－視圖－控制器(MVC)是Xerox PARC在八十年代為編程語言Smalltalk－80發(fā)明的一種軟件設(shè)計模式，至今已被廣泛使用。最近幾年被推薦為Sun公司J2EE平臺的設(shè)計模式，并且受到越來越多的使用 ColdFusion

63、 和 PHP等開發(fā)語言的開發(fā)者的歡迎。模型－視圖－控制器模式是一個有用的工具箱，它有很多好處，但也稍微存在著一些不足。</p><p>　　3.1.2 MVC工作過程</p><p>　　MVC是一個設(shè)計模式，它強制性的使應(yīng)用程序的輸入、處理和輸出分開。使用MVC應(yīng)用程序被分成三個核心部件：模型、視圖、控制器。它們各自處理自己的任務(wù)。 </p><p><b&

64、gt;　　視圖 </b></p><p>　　視圖是用戶看到并與之交互的界面。對以前的Web應(yīng)用程序來說，視圖就是由HTML元素組成的接口，在新式的Web應(yīng)用程序中，HTML依舊在視圖中扮演著重要的角色，但一些新的技術(shù)已層出不窮，它們包括Adobe Flash和象XHTML，XML/XSL，WML等一些標識語言和Web services. </p><p>　　如何處理應(yīng)用程序

65、的接口變得越來越有挑戰(zhàn)性。MVC一個大的好處是它能為你的應(yīng)用程序處理很多不同的視圖。在視圖中其實沒有真正的處理發(fā)生，不管這些數(shù)據(jù)是聯(lián)機存儲的還是一個雇員列表，作為視圖來講，它只是作為一種輸出數(shù)據(jù)并允許用戶操縱的方式。 </p><p><b>　　模型 </b></p><p>　　模型表示企業(yè)數(shù)據(jù)和業(yè)務(wù)規(guī)則。在MVC的三個部件中，模型擁有最多的處理任務(wù)。例如它可能用

66、象EJB和ColdFusion Components這樣的構(gòu)件對象來處理數(shù)據(jù)庫。被模型返回的數(shù)據(jù)是中立的，就是說模型與數(shù)據(jù)格式無關(guān)，這樣一個模型能為多個視圖提供數(shù)據(jù)。由于應(yīng)用于模型的代碼只需寫一次就可以被多個視圖重用，所以減少了代碼的重復(fù)性。 </p><p><b>　　控制器 </b></p><p>　　控制器接受用戶的輸入并調(diào)用模型和視圖去完成用戶的需求。所以

67、當單擊Web頁面中的超鏈接和發(fā)送HTML窗體時，控制器(例如:servlet)本身不輸出任何東西和做任何處理。它只是接收請求并決定調(diào)用哪個模型構(gòu)件去處理請求，然后確定用哪個視圖來顯示模型處理返回的數(shù)據(jù)。 </p><p>　　現(xiàn)在總結(jié)一下MVC的處理過程，首先控制器接收用戶請求，并決定應(yīng)該調(diào)用哪個模型來進行處理，然后模型用業(yè)務(wù)邏輯來處理用戶的請求并返回數(shù)據(jù)，最后控制器用相應(yīng)的視圖格式化模型返回的數(shù)據(jù)，并通過表示層

68、呈現(xiàn)給用戶。</p><p>　　3.1.3 MVC框架的優(yōu)缺點分析</p><p>　　MVC設(shè)計模式受到廣大設(shè)計開發(fā)者的喜愛，主要有以下一些優(yōu)點:</p><p>　　低耦合性:視圖層和業(yè)務(wù)層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容

69、易改變應(yīng)用程序的數(shù)據(jù)層和業(yè)務(wù)規(guī)則。</p><p>　　高重用性和可適用性:隨著技術(shù)的不斷進步，現(xiàn)在需要用越來越多的方式來訪問應(yīng)用程序。MVC模式允許你使用各種不同樣式的視圖來訪問同一個服務(wù)器端的代碼。它包括任何WEB(HTTP)瀏覽器或者無線瀏覽器(wap)，比如，用戶可以通過計算機也可通過手機來訂購某樣產(chǎn)品，雖然訂購的方式不一樣，但處理訂購產(chǎn)品的方式是一樣的。由于模型返回的數(shù)據(jù)沒有進行格式化，所以同樣的構(gòu)件能

70、被不同的接口使用。例如，很多數(shù)據(jù)可能用HTML來表示，但是也有可能用WAP來表示，而這些表示所需要的僅令是改變視圖層的實現(xiàn)方式，而控制層和模型層無需做任何改變。</p><p>　　較低的生命周期成本:MVC使降低開發(fā)和維護用戶接口的技術(shù)含量成為可能。</p><p>　　快速的部署:使用MVC模式使開發(fā)時間得到相當大的縮減，它使程序員(Java開發(fā)人員)集中精力于業(yè)務(wù)邏輯，接口程序員(H

71、TML和JSP開發(fā)人員)集中精力于表現(xiàn)形式上。</p><p>　　可維護性:分離視圖層和業(yè)務(wù)邏輯層也使得WEB應(yīng)用更易于維護和修改。</p><p>　　有利于軟件工程化管理:由于不同的層各司其職，每一層不同的應(yīng)用具有某些相同的特征，有利于通過工程化、工具化管理程序代碼。</p><p>　　MVC也存在一些不足之處，但是相對其優(yōu)勢來說可以忽略不予考慮:</

72、p><p>　　MVC的缺點是由于它沒有明確的定義，所以完全理解MVC并不是很容易。使用MVC需要精心的計劃，由于它的內(nèi)部原理比較復(fù)雜，所以需要花費一些時間去思考領(lǐng)會。</p><p>　　你將不得不花費相當可觀的時間去考慮如何將MVC運用到你的應(yīng)用程序，同時由于模型和視圖要嚴格的分離，這樣也給調(diào)試應(yīng)用程序到來了一定的困難。每個構(gòu)件在使用之前都需要經(jīng)過徹底的測試。一旦你的構(gòu)件經(jīng)過了測試，你就可

73、以毫無顧忌的重用它們了。</p><p>　　根據(jù)開發(fā)者經(jīng)驗，由于開發(fā)者將一個應(yīng)用程序分成了三個部件，所以使用MVC同時也意味著你將要管理比以前更多的文件，這一點是顯而易見的。這樣好像我們的工作量增加了，但是這比起它所能帶給我們的好處是不值一提。</p><p>　　MVC并不適合小型甚至中等規(guī)模的應(yīng)用程序，花費大量時間將MVC應(yīng)用到規(guī)模并不是很大的應(yīng)用程序通常是得不償失的。</p&

74、gt;<p>　　MVC設(shè)計模式是一個很好創(chuàng)建軟件的途徑，它所提倡的一些原則，像業(yè)務(wù)邏輯層和表示層互相分離可能比較好理解。但是如果要隔離模型、視圖和控制器的構(gòu)件，就可能需要重新思考你的應(yīng)用程序，尤其是應(yīng)用程序的構(gòu)架方面。如果你肯接受MVC，并且有能力應(yīng)付它所帶來的額外的工作和復(fù)雜性，MVC將會使你的軟件在健壯性，代碼重用和結(jié)構(gòu)方面上一個新的臺階。</p><p>　　3.2 MVC框架——Stru

75、ts2</p><p>　　Apache Struts(這里指Struts1.x) 作為最成功的 MVC Web 框架早已得到了廣泛的應(yīng)用，但是其自身也暴露出不少缺點，從而引出了Struts 2 。Struts2號稱是一個全新的框架，但這僅僅是相對Struts 1而言。Struts 2 與Struts 1相比，確實有很多革命性的改進，但它并不是新發(fā)布的新框架，Struts 2 摒棄了原來 Struts 1 的設(shè)計

76、，是在另一個赫赫有名的框架—WebWork的基礎(chǔ)上發(fā)展起來的。從某種程度上來講，Struts2沒有繼承Struts 1的血統(tǒng)，而是繼承WebWork的血統(tǒng)。或者說，WebWork衍生出了Struts2，而不是Struts1衍生了Struts2。因為Struts2是WebWork的升級，因此穩(wěn)定性、性能等各方面都有很好的保證：而且吸收了Struts 1和WebWork兩者的優(yōu)勢，因此，是一個非常值得期待的框架[13]。</p>

77、<p>　　Apache Struts2是一個優(yōu)雅的，可擴展的JAVA EE web框架?？蚣茉O(shè)計的目標貫穿整個開發(fā)周期，從開發(fā)到發(fā)布，包括維護的整個過程。</p><p>　　3.2.1 Struts2的誕生</p><p>　　由于Struts1設(shè)計上的缺陷，使得它越來越無法滿足開發(fā)人員要求高效，靈活的開發(fā)需求，很多開發(fā)人員開始選擇其他優(yōu)秀的Web開發(fā)框架。</p&

78、gt;<p>　　Struts1存在的問題主要有兩個：</p><p>　　(1)令人頭痛的ActionForm；</p><p><b>　　(2)單元測試困難</b></p><p>　　下面具體看一下Struts1的這兩個問題。</p><p>　　1. 令人頭痛的ActionForm</p&g

79、t;<p>　　使用Struts1框架開發(fā)過大型Web應(yīng)用程序開發(fā)人員說起ActionForm，都是頭痛加無奈。要理解ActionForm為什么讓人頭痛，就要從現(xiàn)代軟件開發(fā)的分層結(jié)構(gòu)說起。</p><p>　　在現(xiàn)代企業(yè)軟件開發(fā)中，分層與解耦是兩個必須考慮的要素，經(jīng)典的軟件分層結(jié)構(gòu)如圖3.1所示。其中，數(shù)據(jù)訪問層實現(xiàn)對數(shù)據(jù)庫操作的封裝，以隔離具體業(yè)務(wù)和數(shù)據(jù)庫之間的聯(lián)系；而業(yè)務(wù)邏輯層則實現(xiàn)對業(yè)務(wù)邏輯的

80、封裝，隔離用戶操作的界面和具體業(yè)務(wù)邏輯；表現(xiàn)層即用戶界面層，提供用戶操作接口。這種封層封裝的好處是分化了復(fù)雜的系統(tǒng)，同時也提高了系統(tǒng)的可維護性，使得開發(fā)過程中的分工協(xié)作更加方便快捷。采用這種層次結(jié)構(gòu)，上層應(yīng)該只依賴于它的下層結(jié)構(gòu)，而不應(yīng)該跨層依賴；同時，下層不應(yīng)該依賴于它的上層結(jié)構(gòu)，也就是說，業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層絕對不要依賴于表現(xiàn)層。在業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層的代碼中，不要出現(xiàn)調(diào)用表現(xiàn)層代碼的情況。遵循這個原則將簡化在相同的基礎(chǔ)上替換表

81、現(xiàn)層的代價，也使得表現(xiàn)層的修改所帶來的連鎖反應(yīng)盡可能小。</p><p>　　圖3.1 經(jīng)典的軟件分層結(jié)構(gòu)</p><p>　　Struts是屬于表現(xiàn)層的技術(shù)，在Struts中，為了接收表單的數(shù)據(jù)，我們必須編寫一個從Struts的ActionForm類繼承的類，否則你就只能自己從HttpServletRequest中提取數(shù)據(jù)了。然而，不使用ActionForm，意味著你需要自己對表單數(shù)據(jù)做

82、初始化，以及自己編寫代碼對表單數(shù)據(jù)進行驗證。使用從ActionForm繼承的類，如果更換Web框架，這個類也將被廢棄。ActionForm中的數(shù)據(jù)往往需要傳遞給業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層處理，為了避免業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層依賴于Struts，通常會再編寫一個和ActionForm類具有相同屬性 的普通JavaBean類，在ActionForm對象接收到數(shù)據(jù)后，將其中的數(shù)據(jù)原封不動地復(fù)制到JavaBean對象中，然后將這個JavaBean對象

83、向下層傳遞。想一想，如果能夠直接使用普通對象的JavaBean對象來接收表單數(shù)據(jù)該多好，既可以避免多余的數(shù)據(jù)復(fù)制步驟，又可以不依賴于Struts框架?？紤]到程序中可能還會存在著PO(Persistent Object，持久化對象，位于數(shù)據(jù)訪問層，對應(yīng)著數(shù)據(jù)庫表中一條記錄)和JavaBean對象之</p><p><b>　　2.單元測試困難</b></p><p>　

84、　在現(xiàn)代軟件開發(fā)中，測試的重要性已經(jīng)毋庸置疑。Struts1中的Action類與Servlet API耦合在一起，它的核心方法execute依賴于Servlet API中的HttpServletRequest和HttpServletResponse，其方法簽名如下：</p><p>　　Public ActionForword execute(ActionMapping mapping,</p>&

85、lt;p>　　ActionForm form,</p><p>　　javax.servlet.http.HttpServletRequest request,</p><p>　　javax.servlet.http.HttpServletResponse response)</p><p>　　我們知道，HttpServletRequest和HttpSer

86、vletResponse是由Servlet容器負責實例化的，因此Action類的測試就要依賴于Web容器，單元測試很難實現(xiàn)。當然，也可以使用第三方測試工具—JUnit的擴展工具StrutsTestCase來對Action進行單元測試。</p><p>　　除了上述兩個問題外，Struts1還存在著一些其他設(shè)計上的不足，在這里就不一一列舉了。</p><p>　　Struts1開發(fā)團隊也意識

87、到了這一點，開始考慮Struts1的后續(xù)發(fā)展，于是WebWork進入了Struts1開發(fā)團隊的視線。</p><p>　　WebWork1.0是在2002年3月發(fā)布的，Rickard Oberg在研究了其他的Java Web開發(fā)框架之后創(chuàng)建了WebWork，引入了不少新的思想，概念和功能。2004年2月，WebWork2.0發(fā)布，從此WebWork拆分為XWork和WebWork兩個項目。XWork完全脫離了We

88、b層，成為一個可重用的組件，可供其他項目使用，WebWork2建立在XWork之上,負責處理HTTP請求和響應(yīng)。WebWork解決了Struts1的ActionForm的問題，在WebWork中的Action沒有和Servlet API耦合在一起，所以單元測試更加容易。</p><p>　　雖然WebWork設(shè)計思想先進，功能強大，但市場占有率并不理想，Struts開發(fā)團隊看中了WebWork的技術(shù)，而WebWo

89、rk開發(fā)團隊看中了Struts的人氣和市場占有率，由于有共同的需求，于是一拍即合，決定合并開發(fā)。</p><p>　　2006年，WebWork與Struts這兩個優(yōu)秀的Java Web框架(Web Framework)的開發(fā)團隊，決定合作共同開發(fā)一個新的，整合了WebWork與Struts的優(yōu)點，并且更加優(yōu)雅、擴展性更強的框架，命名為“Struts2”，原先的Struts1.x版產(chǎn)品稱為“Struts1”。&l

90、t;/p><p>　　Struts2是在WebWork2的基礎(chǔ)上進行開發(fā)的，Struts2.0其實就是WebWork2.3，它和Strut1并沒有多大關(guān)系。</p><p>　　3.2.2 Struts2核心工作流程及原理</p><p>　　Struts2的體系結(jié)構(gòu)如圖3.2所示[14]：</p><p>　　請求在Struts2框架中的處理大

91、概分為以下幾個步驟： </p><p>　　一個初始的請求到達Servlet容器(例如Tomcat或者Resin等)后，如在瀏覽器中輸入http://localhost:8080/xxx.action就是一個(HttpServletRequest)請求。將被傳遞給一個標準的過濾器鏈。這個過濾器鏈包括了可選的ActionContextCleanUp過濾器、其他過濾器(SiteMesh等)。ActionContext

92、CleanUp這個在集成插件方面非常有用，當在Struts2 Web應(yīng)用程序中集成SiteMesh時，將會用到這個過濾器。接下來，必須的FilterDispatcher被調(diào)用。調(diào)用FilterDispatecher會去查找相應(yīng)的ActionMapper，如果找到了相應(yīng)的ActionMapper它將會將控制權(quán)限委派給ActionProxy，ActionProxy將會通過ConfigurationManager來查找配置struts.xml

93、，</p><p>　　接下來，ActionProxy創(chuàng)建一個實現(xiàn)了命令模式的ActionInvocation。ActionInvocation在調(diào)用Action之前會依次調(diào)用所有配置的攔截器。 一旦action執(zhí)行返回，ActionInvocation就要查找這個action的結(jié)果碼所對應(yīng)的result視圖，然后執(zhí)行這個result。通常情況下result會調(diào)用JSP或FreeMarker模板來呈現(xiàn)頁面(但不總

94、是這樣，例如result也可以是一個Action鏈)。當呈現(xiàn)頁面時，模板可以使用框架提供的Struts標簽。其中一些組件可以和ActionMapper一起工作來為后面的請求呈現(xiàn)正確的URL。 攔截器被再次執(zhí)行(執(zhí)行順序和開始相反)，最后響應(yīng)被返回給在web.xml中配置的這些過濾器。如果已經(jīng)設(shè)置了ActionContextCleanUp過濾器，那么FilterDispatcher就不會清理ThreadLocal中的ActionConte

95、xt信息；如果沒有設(shè)置ActionContextCleanUp過濾器，則</p><p>　　FilterDispatcher會清理掉所有的ThreadLocal。</p><p>　　圖3.2 struts2的體系結(jié)構(gòu)</p><p>　　Struts2框架的調(diào)用流程</p><p>　　為了更好的理解Struts2框架的結(jié)構(gòu)，下面以序列圖

96、的方式給出了一個請求經(jīng)過Struts2框架和action的調(diào)用，最后向用戶顯現(xiàn)結(jié)果頁面的調(diào)用過程。Struts2框架的調(diào)用流程序列圖如圖3.3所示。</p><p>　　當Servlet容器接收到一個請求后，將請求交給你在web.xml文件中配置的過濾器FilterDispatcher，調(diào)用它的doFilter()方法。</p><p>　　FilterDispatcher詢問Action

97、Mapper，以便確定這個請求是否有對應(yīng)的action調(diào)用。</p><p>　　ActionMapper返回一個描述了action調(diào)用的ActionMapping對象。</p><p>　　FilterDispatcher調(diào)用Dispatcher類的serviceAction()方法。</p><p>　　Dispatcher調(diào)用ActionProxy的execu

98、te()方法。</p><p>　　ActionProxy設(shè)置ActionInvocation對象的執(zhí)行上下文，然后調(diào)用其invoke()方法。</p><p>　　ActionInvocation的invoke()方法從攔截器映射中查找尚未執(zhí)行的攔截器，調(diào)用它的intercept(invocation)方法，并將自身對象的引用作為參數(shù)傳遞給攔截器。</p><p>

99、;　　攔截器完成某些預(yù)處理工作后，反過來調(diào)用ActionInvocation的invoke()方法。ActionInvocation維護著自己的狀態(tài)，所以它知道哪些攔截器已經(jīng)被執(zhí)行，如果還有沒執(zhí)行的攔截器，就繼續(xù)執(zhí)行它的intercept(invocation)方法。</p><p>　　如果所有的攔截器都已經(jīng)執(zhí)行過了，就調(diào)用action實例的execute()方法(如果在struts.xml文件中沒有被設(shè)置成其

100、他的方法)。</p><p>　　ActionInvocation根據(jù)action執(zhí)行返回的結(jié)果碼，查找對應(yīng)的Result，調(diào)用Result的execute(invocation)方法，將結(jié)果頁面呈現(xiàn)給用戶。</p><p>　　ActionInvocation的invoke()方法將控制權(quán)返回給攔截器映射中的最后一個攔截器，該攔截器完成所有必須的后期處理工作，然后從intercept(i

101、nvocation)方法返回，允許前一個攔截器執(zhí)行它自己的后處理工作。如此反復(fù)，知道所有的攔截器都成功返回。</p><p>　　ActionInvocation的invoke()方法執(zhí)行完畢后，向ActionProxy返回一個String類型的結(jié)果碼，最后，ActionProxy清理狀態(tài)并返回。</p><p>　　圖3.3 Struts2框架調(diào)用流程序列圖</p><

102、;p>　　3.3 Struts2的攔截器</p><p>　　攔截器(Interceptor)是Struts2的一個重要特性。Struts2框架的大多數(shù)核心功能都是通過攔截器來實現(xiàn)的，像避免表單的重復(fù)提交、類型轉(zhuǎn)換、對象組裝、驗證、文件上傳等，都是在攔截器的幫助下實現(xiàn)的。攔截器之所以稱為“攔截器”，是因為它可以在Action執(zhí)行之前和執(zhí)行之后攔截調(diào)用。</p><p><b&

103、gt;　　攔截器的優(yōu)勢</b></p><p>　　Struts2將它的核心功能放到攔截器中實現(xiàn)而不是分散到Action中去實現(xiàn)，有利于系統(tǒng)的解耦，使得功能的實現(xiàn)類似于個人電腦的組裝，變成了可插拔的。需要某個功能就“插入”一個攔截器，不需要某個功能就“拔出”一個攔截器?？梢匀我饨M合攔截器來為Action提供附加的功能，而不需要修改Action的代碼。</p><p><b

104、>　　攔截器的工作方式</b></p><p>　　攔截器圍繞著Action和Result的執(zhí)行而執(zhí)行，其工作方式如圖3.4所示。從圖可以看到，在Action和Result執(zhí)行之前，為Action配置的攔截器將首先執(zhí)行，在Action和Result執(zhí)行之后，攔截器將重新獲得控制權(quán)，然后按照與先前調(diào)用相反的順序依次執(zhí)行。在整個執(zhí)行的過程中，任何一個攔截器都可以選擇直接返回，從而終止余下的攔截器、A

105、ction和Result的執(zhí)行。例如，當一個未授權(quán)的用戶訪問受保護 的資源時，執(zhí)行身份驗證的攔截器可以直接返回。</p><p><b>　　攔截器類的編寫</b></p><p>　　在Struts2中要編寫攔截器類，必須實現(xiàn)</p><p>　　com.opensymphony.xwork2.interceptor.Interceptor接

106、口，該接口定義了如下的三個方法：</p><p>　　void init()</p><p>　　該方法在攔截器實例創(chuàng)建之后、intercept()方法被調(diào)用之前調(diào)用，用于初始化攔截器所需要的資源，例如數(shù)據(jù)庫連接的初始化。該方法只執(zhí)行一次。</p><p>　　void destroy()</p><p>　　該方法在攔截器實例被銷毀之前調(diào)用