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

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

2、院 經(jīng)濟(jì)管理學(xué)院 </p><p>　　專(zhuān) 業(yè) </p><p>　　學(xué)生姓名 </p><p>　　導(dǎo)師姓名 </p><p><b>　　摘 要<

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

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

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

6、的訪(fǎng)問(wèn)控制</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 訪(fǎng)問(wèn)控制機(jī)制概述5</p><p>　　2.2 訪(fǎng)問(wèn)控制策略5</p><p>　　2.2.1自主訪(fǎng)問(wèn)控制(Discretionary Ac

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

14、　2.3.1 RBAC基本概念8</p><p>　　2.3.2 基于角色的訪(fǎng)問(wèn)控制基本思想9</p><p>　　2.4 基于角色訪(fǎng)問(wèn)控制RBAC的優(yōu)勢(shì)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工作過(guò)程13</p><p>　　3.1.3 MVC框架的優(yōu)缺點(diǎn)分析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è)計(jì)25</p><p>　　4.1 總體目標(biāo)25</p><p>　　4.2 功能需求26</p><p>　　4.3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

84、　在現(xiàn)代軟件開(kāi)發(fā)中，測(cè)試的重要性已經(jīng)毋庸置疑。Struts1中的Action類(lèi)與Servlet API耦合在一起，它的核心方法execute依賴(lài)于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容器負(fù)責(zé)實(shí)例化的，因此Action類(lèi)的測(cè)試就要依賴(lài)于Web容器，單元測(cè)試很難實(shí)現(xiàn)。當(dāng)然，也可以使用第三方測(cè)試工具—JUnit的擴(kuò)展工具StrutsTestCase來(lái)對(duì)Action進(jìn)行單元測(cè)試。</p><p>　　除了上述兩個(gè)問(wèn)題外，Struts1還存在著一些其他設(shè)計(jì)上的不足，在這里就不一一列舉了。</p><p>　　Struts1開(kāi)發(fā)團(tuán)隊(duì)也意識(shí)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

103、gt;　　攔截器的優(yōu)勢(shì)</b></p><p>　　Struts2將它的核心功能放到攔截器中實(shí)現(xiàn)而不是分散到Action中去實(shí)現(xiàn)，有利于系統(tǒng)的解耦，使得功能的實(shí)現(xiàn)類(lèi)似于個(gè)人電腦的組裝，變成了可插拔的。需要某個(gè)功能就“插入”一個(gè)攔截器，不需要某個(gè)功能就“拔出”一個(gè)攔截器?？梢匀我饨M合攔截器來(lái)為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í)行。在整個(gè)執(zhí)行的過(guò)程中，任何一個(gè)攔截器都可以選擇直接返回，從而終止余下的攔截器、A

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

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