基于MVC架構(gòu)的網(wǎng)站RBAC訪問控制框架設(shè)計與實(shí)現(xiàn)

1、基于基于 MVCMVC 架構(gòu)的網(wǎng)站架構(gòu)的網(wǎng)站 RBACRBAC 訪問訪問控制框架設(shè)計與控制框架設(shè)計與實(shí)現(xiàn)實(shí)現(xiàn)蘇州科技學(xué)院蘇州科技學(xué)院畢業(yè)設(shè)計論文畢業(yè)設(shè)計論文姓名：周霖欽姓名：周霖欽專業(yè)：計算機(jī)科學(xué)與技術(shù)專業(yè)：計算機(jī)科學(xué)與技術(shù)指導(dǎo)老師：陸指導(dǎo)老師：陸 悠悠摘摘要要一個實(shí)際的商務(wù)網(wǎng)站系統(tǒng)除了需要關(guān)注于功能需求之外，還需要考慮很多非功能性需求，安全性就是其中一個非常重要的方面。訪問控制是幾乎所有的應(yīng)用系統(tǒng)都不可缺少的一部分。本文從 MVC 架構(gòu)商務(wù)管理系統(tǒng)的需求出發(fā)，首先分析了幾種訪問控制的優(yōu)缺點(diǎn)，在此基礎(chǔ)上提出了利用 RBAC 模型來進(jìn)行系統(tǒng)的訪問控制。并將其用于某一具體的商務(wù)系統(tǒng)中，給出了實(shí)現(xiàn)過

2、程。關(guān)鍵詞關(guān)鍵詞：MVC、RBAC、訪問控制、角色、權(quán)限。AbstractWhen functional requirements are chiefly paid attention to by people in a commercial application system, many nonfunctional requirements are also taken into account. Security is one of the most important aspects of the nonfunctional requirements. Access control a

3、lmost is a necessary part in all application systems. This paper analyses the requirements of comprehensive commercial information management system based on MVC. It analyses the merits and demerits among the common access controls, and proposes process access control based on RBAC model. Finally, i

4、t describes how to realize the model in a material commercial system.Key words： MVC，RBAC，Access Control， Role，Permission. 目錄引引言言 .1第一章第一章 課題背景課題背景 .21.1 MVC 概述.21.2 RBAC 模型概述.3原理簡介.3適用性分析.51.3 RBAC 在 MVC 中的應(yīng)用現(xiàn)狀.6第二章第二章 系統(tǒng)框架分析與設(shè)計系統(tǒng)框架分析與設(shè)計 .92.1 基于 MVC 架構(gòu)的 WEB系統(tǒng).92.2 RBAC 模型的建立.112.3 RBAC 模型在 MVC 網(wǎng)站中的

5、應(yīng)用.12第三章第三章 設(shè)計實(shí)現(xiàn)設(shè)計實(shí)現(xiàn) .143.1 RBAC 框架實(shí)現(xiàn).143.2 RBAC 模型在系統(tǒng)中的實(shí)現(xiàn).17系統(tǒng)功能模塊的實(shí)現(xiàn).17系統(tǒng)權(quán)限模塊的實(shí)現(xiàn).21系統(tǒng)角色模塊的實(shí)現(xiàn).23為用戶設(shè)置角色.25用戶權(quán)限功能樹的生成.26第四章第四章 系統(tǒng)測試系統(tǒng)測試 .294.1 系統(tǒng)測試.29測試環(huán)境.29測試方案.294.2 總結(jié)與展望.324.3 致謝.33參考文獻(xiàn)參考文獻(xiàn) .34附錄附錄 A A：英文原文：英文原文 .35附錄附錄 B B：中文翻譯：中文翻譯 .41引引言言本此畢業(yè)設(shè)計將基于角色訪問控制（Role-Based Access Control，RBAC）作為研究課題，來

6、實(shí)現(xiàn)一個企業(yè)內(nèi)部管理系統(tǒng)中的權(quán)限管理部分。本文在RBAC2001 建議標(biāo)準(zhǔn)的參考模型(下稱 NIST RBAC 模型)的基礎(chǔ)上，結(jié)合綜合信息管理系統(tǒng)以及軟件系統(tǒng)集成的要求和特點(diǎn)，將 RBAC 訪問控制框架應(yīng)用到一個已有的以 MVC 為架構(gòu)建立而成的商務(wù)網(wǎng)站中去。第一章第一章 課題背景課題背景1.11.1 MVCMVC 概述概述由于 Internet 的普及和網(wǎng)絡(luò)技術(shù)的發(fā)展，大部分的企業(yè)或單位都擁有了自己的 Web 站點(diǎn)。通過 Internet 或 Intranet，企業(yè)的管理變得更加方便；企業(yè)的信息發(fā)布變得更加便捷；企業(yè)的市場開拓變得更加簡便。企業(yè)網(wǎng)站大部分屬于商務(wù)網(wǎng)站，企業(yè)通過利用 Web

7、系統(tǒng)，可以方便的發(fā)布產(chǎn)品信息，管理訂單信息，管理內(nèi)部的諸如人事、員工薪酬信息等。從而在一定程度上提高工作和管理效率，降低生產(chǎn)和管理成本。現(xiàn)在用來建立 Web 站點(diǎn)的工具和編程語言主要有 ASP、PHP 和 JSP，使用的設(shè)計模式是 MVC。MVC 作為構(gòu)建網(wǎng)站系統(tǒng)的主流設(shè)計模式，有其自身的特點(diǎn)和優(yōu)勢，具體表現(xiàn)在：（1）可以為一個模型在運(yùn)行時同時建立和使用多個視圖。變化-傳播機(jī)制可以確保所有相關(guān)的視圖及時得到模型數(shù)據(jù)變化，從而使所有關(guān)聯(lián)的視圖和控制器做到行為同步。 （2） 視圖與控制器的可接插性，允許更換視圖和控制器對象，而且可以根據(jù)需求動態(tài)的打開或關(guān)閉、甚至在運(yùn)行期間進(jìn)行對象替換。 （3） 模

8、型的可移植性。因?yàn)槟Ｐ褪仟?dú)立于視圖的，所以可以把一個模型獨(dú)立地移植到新的平臺工作。需要做的只是在新平臺上對視圖和控制器進(jìn)行新的修改。 （4） 潛在的框架結(jié)構(gòu)。可以基于此模型建立應(yīng)用程序框架，不僅僅是用在設(shè)計界面的設(shè)計中?；?MVC 模式建設(shè) Web 站點(diǎn)系統(tǒng)，可以提高代碼的重用性；可以提高代碼的可維護(hù)性；可以提高編寫程序的效率。所以目前，越來越多的網(wǎng)站開始采用MVC 模式來進(jìn)行架構(gòu)，但是在這其中，對于系統(tǒng)安全性問題的研究還進(jìn)行的不多。在構(gòu)建 Web 系統(tǒng)之初，就要考慮系統(tǒng)的安全性，考慮用戶對系統(tǒng)的訪問控制。通過訪問控制，一方面只有合法的用戶才可以安全、正確的使用系統(tǒng)，非法的用戶是無法登陸系統(tǒng)

9、進(jìn)行操作；的；另一方面合法的用戶登錄系統(tǒng)之后，由于用戶的類型不同，就會存在不用的用戶在訪問系統(tǒng)時具有不同的權(quán)限，比如一個企業(yè)或公司的經(jīng)理往往會比企業(yè)或公司的員工具有更多的權(quán)限和功能，相應(yīng)的用戶登錄系統(tǒng)之后，他們只能行使系統(tǒng)準(zhǔn)許他們的權(quán)限。縱觀現(xiàn)在的 Web 系統(tǒng)，大都存在這樣的問題：功能雖強(qiáng)大，但是卻存在很多的安全隱患。系統(tǒng)中的不同類型的用戶對信息都具有相同的權(quán)限，可以任意的修改和刪除，這對于一些重要的信息是非常危險的。對信息的科學(xué)管理，應(yīng)該是最高層的用戶擁有對信息最高的權(quán)限，而處于底層或次底層的用戶僅擁有對信息最少的權(quán)限。此外，現(xiàn)在大部分 Web 系統(tǒng)中都缺少一個良好的訪問控制模塊。在該模塊

10、中，可以為系統(tǒng)設(shè)定不同的用戶，分配不同的權(quán)限。將系統(tǒng)中的用戶和系統(tǒng)中的權(quán)限關(guān)聯(lián)起來，形成一種有效的系統(tǒng)安全管理。綜上所述，企業(yè)在構(gòu)建自身的商務(wù) Web 系統(tǒng)時，在考慮功能完整性和操作簡便性的同時，還應(yīng)重點(diǎn)考慮構(gòu)建的 Web 系統(tǒng)的安全性。只有在保證了安全性的前提下，功能的完整性和操作的簡便性才變得有意義。1.21.2 RBACRBAC 模型概述模型概述 RBACRBAC 原理簡介原理簡介1992 年，美國國家標(biāo)準(zhǔn)與技術(shù)研究所（NIST）的 David Ferraiolo 和Rick Kuhn 在綜合了大量的實(shí)際研究之后，率先提出基于角色的訪問控制模型框架，并給出了 RBAC 模型的一種形式化定

11、義。該模型第一次引入了角色的概念并給出其基本語義，指出 RBAC 模型實(shí)現(xiàn)了最小權(quán)限原則（the least privilege）和職責(zé)分離原則（separation of duty） 。該模型中給出了一種集中式管理的 RBAC 管理方案。1995 年他們以一種更直觀的方式對該模型進(jìn)行了描述。Ravi Sandhu 和他領(lǐng)導(dǎo)的位于 George Mason 大學(xué)的信息安全技術(shù)實(shí)驗(yàn)室（LIST）于 1996 年提出了著名的 RBAC96 模型，將傳統(tǒng)的 RBAC 模型根據(jù)不同需要拆分成四種嵌套的模型并給出形式化定義，極大的提高了系統(tǒng)靈活性和可用性。1997 年他們更進(jìn)一步，提出了一種分布式 RB

12、AC 管理模型 DRBAC97，實(shí)現(xiàn)了在 RBAC 模型基礎(chǔ)上的分布式管理。這兩個模型清晰的表征了 RBAC 概念并且蘊(yùn)涵了他人的工作，成為 RBAC 的經(jīng)典模型。絕大多數(shù)基于角色的訪問控制研究都以這兩個模型作為出發(fā)點(diǎn)。在 RBAC 中，涉及到的基本概念如下：用戶（User）：系統(tǒng)的使用者?？梢允侨恕⒂嬎銠C(jī)、機(jī)器人等，一般指人。角色（Role）：一定數(shù)量的權(quán)限的集合。權(quán)限分配的單位與載體，目的是隔離用戶與權(quán)限的邏輯關(guān)系。對應(yīng)于組織中某一特定的職能崗位，代表特定的任務(wù)范疇。角色的例子有：經(jīng)理、采購員、推銷員等。權(quán)限（Permission）：表示對系統(tǒng)中的客體進(jìn)行特定模式訪問的操作許可，例如對數(shù)據(jù)

13、庫系統(tǒng)中關(guān)系表的選擇、插入、刪除。在應(yīng)用中，許可受到特定應(yīng)用邏輯的限制。用戶指派（User Assignment）：用戶與角色之間的關(guān)系是多對多的關(guān)系。用戶指派指根據(jù)用戶在組織中的職責(zé)和能力被賦為對應(yīng)角色的成員。用戶通過被指派到角色間接獲得訪問資源的權(quán)限。權(quán)限指派（Permission Assignment）：角色與權(quán)限之間的關(guān)系也是多對多的關(guān)系。權(quán)限指派指角色按其職責(zé)范圍與一組操作權(quán)限相關(guān)聯(lián)。進(jìn)行權(quán)限分配時，應(yīng)遵循最小特權(quán)原則（the Least Privilege Rule） ，即分配的權(quán)限集既能保證角色充分行使其職權(quán)，又不能超越職權(quán)范圍。角色激活（Role Activation）：是指用

14、戶從被授權(quán)的角色中選擇一組角色的過程。用戶訪問的時候?qū)嶋H具有的角色只包含激活后的角色，未激活的角色在訪問中不起作用。相對于靜態(tài)的角色授權(quán)來說，角色激活是一種動態(tài)的過程，提供了相當(dāng)?shù)撵`活性。會話（Session）：用戶是一個靜態(tài)的概念，會話則是一個動態(tài)的概念。一次會話是用戶的一個活躍進(jìn)程，它代表用戶與系統(tǒng)進(jìn)行交互，也叫主體（Subject） 。用戶與會話是一對多關(guān)系，一個用戶可同時打開多個會話。活躍角色集（ARS）：一個對話構(gòu)成一個用戶到多個角色的映射，即會話激活了用戶授權(quán)角色集的某個子集，這個子集被稱為活動角色集，ARS 決定了本次會話的許可集。在 RBAC 中，它遵循如下的基本原則：角色繼承

15、（Role Inheritance）為了提高效率，避免相同權(quán)限的重復(fù)設(shè)置，RBAC 采用了“角色繼承”的概念，定義了這樣的一些角色，他們有自己的屬性，但可能還繼承其他角色的屬性和權(quán)限。角色繼承把角色組織起來，能夠很自然地反映組織內(nèi)部人員之間的職權(quán)、責(zé)任關(guān)系。最小權(quán)限原則（the Least Privilege Rule）所謂最小權(quán)限原則是指：用戶所擁有的權(quán)力不能超過他執(zhí)行工作時所需的權(quán)限。實(shí)現(xiàn)最小權(quán)限原則，需分清用戶的工作內(nèi)容，確定執(zhí)行該項(xiàng)工作的最小權(quán)限集，然后將用戶限制在這些權(quán)限范圍之內(nèi)。在 RBAC 中，可以根據(jù)組織內(nèi)的規(guī)章制度、職員的分工等設(shè)計擁有不同權(quán)限的角色，只有角色需要執(zhí)行的操作才

16、授權(quán)給角色。當(dāng)一個主體預(yù)訪問某資源時，如果該操作不在主體當(dāng)前活躍角色的授權(quán)操作之內(nèi)，該訪問將被拒絕。職責(zé)分離（Separation of Duty）對于某些特定的操作集，某一個角色或用戶不可能同時獨(dú)立地完成所有這些操作。職責(zé)分離的概念包括：多路共享資源，用功能分解命名互相區(qū)分的權(quán)限集，對用戶進(jìn)行強(qiáng)制分類，允許層次性的分解權(quán)限。 RBACRBAC 適用性分析適用性分析在 RBAC 模型中，一個用戶通過用戶授權(quán)獲得一個或者幾個角色，但角色不能被同時激活；一個角色可以被同時授予多個用戶；每個角色有一個或多個節(jié)點(diǎn)，一個節(jié)點(diǎn)也可以被賦予多個角色；每個節(jié)點(diǎn)有一個或者多個功能，一個功能可以被同時掛在不同的節(jié)

17、點(diǎn)上，而節(jié)點(diǎn)可以有子節(jié)點(diǎn)，子節(jié)點(diǎn)也可以再有子節(jié)點(diǎn)；一個功能對應(yīng)一個或多個頁面；一個頁面有一個或多個操作。這樣每個用戶登錄時就可以根據(jù)角色得到一棵功能樹從而使用系統(tǒng)中的資源。為更真實(shí)的描述現(xiàn)實(shí)， RBAC 模型還有許多的控制機(jī)制。如對 Web 頁面多維度和細(xì)粒度控制，對角色、功能、節(jié)點(diǎn)的靜態(tài)限制和對角色的動態(tài)限制。對頁面的限制主要是限制用戶在特定時間和特定地點(diǎn)所能看到的功能和所能進(jìn)行的操作。其他限制主要是在功能被賦予節(jié)點(diǎn)時、節(jié)點(diǎn)被賦予角色時和角色被賦予用戶時的限制。模型中有了這些限制才更完整、更真實(shí)地反應(yīng)現(xiàn)實(shí)，從而使實(shí)際模型細(xì)化的過程更加平滑，現(xiàn)實(shí)和計算機(jī)實(shí)現(xiàn)策略達(dá)到較好的融合。頁面是 Web

18、應(yīng)用系統(tǒng)中最重要的元素，控制頁面訪問是整個系統(tǒng)安全的重要條件。對頁面的訪問控制可以從時間和空間兩個方面來進(jìn)行，對頁面功能和數(shù)據(jù)的訪問，可以通過用戶登錄后所帶 session 中的信息進(jìn)行控制。時間約束分為一般時間約束和周期時間約束兩種。一般時間約束是指從一個時間點(diǎn)持續(xù)到另一時間點(diǎn)之間可以訪問某個頁面，例如，企業(yè)商務(wù)系統(tǒng)中的商品招標(biāo)頁面，它在某一指定時間段內(nèi)開放，對這種約束可以在用戶訪問網(wǎng)頁的時候判斷訪問時間是否在允許范圍內(nèi)。周期時間約束是指對那些功能和數(shù)據(jù)周期性開放的頁面進(jìn)行訪問控制?？臻g約束主要是對用戶在不同地方（網(wǎng)段）登錄所能看到的頁面以及頁面能提供的信息進(jìn)行控制。例如，管理部門內(nèi)部事務(wù)所

19、對應(yīng)的頁面通常對用戶所在的訪問位置有較嚴(yán)的限制。一般系統(tǒng)的高層用戶都有一個固定的 IP 段，就可以對那些重要的頁面設(shè)置允許訪問的 IP 范圍來達(dá)到對關(guān)鍵資源的保護(hù)。對頁面的空間約束可以分成分網(wǎng)段、分樓層、分房間、分 IP 地址等不同層次的控制。對頁面功能和數(shù)據(jù)的訪問需要知道用戶的大概類型，主要包括管理員、部門管理員、一般職工、游客（企業(yè)或單位以外的人員）等。用戶登錄后將用戶的類型保存到 session 中，在用戶訪問頁面時就可以根據(jù)用戶的不同類型，以及他們對時間、空間等硬性約束的滿足情況來顯示相應(yīng)的功能和數(shù)據(jù)。通過了解 RBAC 模型的原理和 RBAC 模型中對訪問控制的支持，我們可以看出，R

20、BAC 模型可以很好的應(yīng)用于已有或?qū)⒁_發(fā)的企業(yè)商務(wù) Web 系統(tǒng)中。通過在系統(tǒng)中使用 RBAC 模型，可以很好的解決如下的問題：權(quán)限管理混亂的問題。通過在系統(tǒng)中增加角色這個概念，很好的解決了這個問題。在 RBAC 模型中，可以利用角色與系統(tǒng)中的所有權(quán)限關(guān)聯(lián)，使得某種角色具有某種特定的權(quán)限，從而在為用戶設(shè)定好相應(yīng)的角色之后，也就意味著得到了相應(yīng)的系統(tǒng)權(quán)限。控制邏輯混亂的問題。通過使用 RBAC 模型，可以避免在系統(tǒng)中書寫負(fù)責(zé)的控制邏輯來進(jìn)行訪問控制。尤其當(dāng)系統(tǒng)設(shè)計的用戶和角色比較多時，單純的依靠代碼進(jìn)行訪問控制將變得相當(dāng)困難。換句話說，RBAC 模型為我們提供了良好的訪問控制支持。在企業(yè)商務(wù)

21、Web系統(tǒng)中利用 RBAC 模型，可以簡便、科學(xué)、清晰地進(jìn)行訪問控制，從而在一定程度上提高了整個 Web 系統(tǒng)的安全性。1.31.3 RBACRBAC 在在 MVCMVC 中的應(yīng)用現(xiàn)狀中的應(yīng)用現(xiàn)狀 網(wǎng)站程序的安全是系統(tǒng)開發(fā)人員必須考慮的重要因素之一，因?yàn)檫@涉及到網(wǎng)站的建設(shè)者、網(wǎng)站用戶的諸多安全問題，如果不處理好，可能會給系統(tǒng)的使用者和管理者帶來嚴(yán)重問題?，F(xiàn)在普遍在使用的安全措施有如下幾種：（1）防止 SQL 注入比如 URL、表單等提交信息時，通過一段防止 SQL 注入的過濾代碼即可防止出錯信息暴露，或者通過轉(zhuǎn)向，當(dāng)系統(tǒng)出錯時轉(zhuǎn)到一個提示出錯的頁面等。對于文本型輸入，如果要進(jìn)行檢查，就得根據(jù)字

22、段本身的性質(zhì)進(jìn)行。例如如果是年齡，就得限定必須是數(shù)字，大小必須限定在一個范圍之間，比如說18-120 之間。對于用戶名，應(yīng)該建立一個集合，這個集合里存放有被允許的字符，或被禁止的字符。（2）驗(yàn)證碼技術(shù)所謂驗(yàn)證碼，就是將一串隨機(jī)產(chǎn)生的數(shù)字或符號，生成一幅圖片，圖片里加上一些干擾象素，由用戶肉眼識別其中的驗(yàn)證碼信息，輸入表單提交網(wǎng)站驗(yàn)證，驗(yàn)證成功后才能使用某項(xiàng)功能。放在會員注冊、留言本等所有客戶端提交信息的頁面，要提交信息，必須要輸入正確的驗(yàn)證碼，從而可以防止不法用戶用軟件頻繁注冊，頻繁發(fā)送不良信息等。（3）MD5 加密技術(shù)MD5 的全稱是 Message-Digest Algorithm 5，當(dāng)

23、用戶登錄的時候，系統(tǒng)把用戶輸入的密碼計算成 MD5 值，然后再去和保存在文件系統(tǒng)中的 MD5 值進(jìn)行比較，進(jìn)而確定輸入的密碼是否正確。通過這樣的步驟，系統(tǒng)在并不知道用戶密碼的明碼的情況下就可以確定用戶登錄系統(tǒng)的合法性。這不但可以避免用戶的密碼被具有系統(tǒng)管理員權(quán)限的用戶知道，而且還在一定程度上增加了密碼被破解的難度。（4）數(shù)據(jù)備份一般采用數(shù)據(jù)庫系統(tǒng)自動定時備份、定時自動刪除幾天以前的數(shù)據(jù)等，即可完成數(shù)據(jù)的備份功能。而圖片、文件一般是不能自動備份，需要手工操作，所以我們必須要定期手工對網(wǎng)站的圖片、文件進(jìn)行備份操作。訪問控制技術(shù)是由美國國防部（Department of Defense, DoD）資

24、助的研究和開發(fā)成果演變而來的。這一研究導(dǎo)致兩種基本類型訪問控制的產(chǎn)生：自主訪問控制（Discretionary Access Control, DAC）和強(qiáng)制訪問控制（Mandatory Access Control, MAC） 。最初的研究和應(yīng)用主要是為了防止機(jī)密信息被未經(jīng)授權(quán)者訪問，近期的應(yīng)用主要是把這些策略應(yīng)用到為商業(yè)領(lǐng)域。自主訪問控制，允許把訪問控制權(quán)的授予和取消留給個體用戶來判斷。為沒有訪問控制權(quán)的個體用戶授予和廢除許可。自主訪問控制機(jī)制允許用戶被授權(quán)和取消訪問其控制之下的任何客體（object） ，換句話說，用戶就是他們控制下的客體的擁有者。然而，對于多數(shù)組織來說，最終用戶對所訪問

25、的信息沒有擁有權(quán)。對于這些組織，公司或代理機(jī)構(gòu)是事實(shí)上的系統(tǒng)客體和處理他們的程序的擁有者。訪問優(yōu)先權(quán)受組織控制，而且也常常基于雇員功能而不是數(shù)據(jù)所有權(quán)。強(qiáng)制訪問控制，在美國國防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定義如下：“一種限制訪問客體的手段，它以包含在這些客體中的信息敏感性和訪問這些敏感性信息的主體的正式授權(quán)信息（如清除）為基礎(chǔ)” 。強(qiáng)制訪問控制是“強(qiáng)加”給訪問主體的，即系統(tǒng)強(qiáng)制主體服從訪問控制政策。強(qiáng)制訪問控制（MAC）的主要特征是對所有主體及其所控制的客體（例如：進(jìn)程、文件、段、設(shè)備）實(shí)施強(qiáng)制訪問控制。為這

26、些主體及客體指定敏感標(biāo)記，這些標(biāo)記是等級分類和非等級類別的組合，它們是實(shí)施強(qiáng)制訪問控制的依據(jù)。系統(tǒng)通過比較主體和客體的敏感標(biāo)記來決定一個主體是否能夠訪問某個客體。用戶的程序不能改變他自己及任何其它客體的敏感標(biāo)記，從而系統(tǒng)可以防止特洛伊木馬的攻擊。強(qiáng)制訪問控制一般與自主訪問控制結(jié)合使用，并且實(shí)施一些附加的、更強(qiáng)的訪問限制。一個主體只有通過了自主與強(qiáng)制性訪問限制檢查后，才能訪問某個客體。用戶可以利用自主訪問控制來防范其它用戶對自己客體的攻擊，由于用戶不能直接改變強(qiáng)制訪問控制屬性，所以強(qiáng)制訪問控制提供了一個不可逾越的、更強(qiáng)的安全保護(hù)層以防止其它用戶偶然或故意地濫用自主訪問控制。以上訪問控制策略對于處

27、理一些無需保密但又敏感的信息的政府和行業(yè)組織的需求并不是特別的適合。在這樣的環(huán)境下，安全目標(biāo)支持產(chǎn)生于現(xiàn)有法律、道德規(guī)范、規(guī)章、或一般慣例的高端組織策略。這些環(huán)境通常需要控制個體行為的能力，而不僅僅是如何根據(jù)信息的敏感性為其設(shè)置標(biāo)簽從而訪問這一信息的個人能力。就基于角色訪問控制而言，訪問決策是基于角色的，個體用戶是某個組織的一部分。用戶具有指派的角色（比如醫(yī)生、護(hù)士、出納、經(jīng)理） 。定義角色的過程應(yīng)該基于對組織運(yùn)轉(zhuǎn)的徹底分析，應(yīng)該包括來自一個組織中更廣范圍用戶的輸入。訪問權(quán)按角色名分組，資源的使用受限于授權(quán)給假定關(guān)聯(lián)角色的個體。例如，在一個商務(wù)管理系統(tǒng)中，經(jīng)理角色可能包括人事管理、工資管理、分

28、配項(xiàng)目等；而一般員工的角色則被限制為僅能瀏覽自己的一些信息，如基本信息、工資信息和工程項(xiàng)目信息等?；诮巧脑L問控制模型 RBAC 比傳統(tǒng)的自主訪問控制和強(qiáng)制訪問控制更優(yōu)越，同時也提供了更高的靈活性和擴(kuò)展性。RBAC 訪問控制模型實(shí)現(xiàn)了用戶與訪問權(quán)限的邏輯分離，減少了授權(quán)管理的復(fù)雜性，降低了管理開銷和管理的復(fù)雜度。對于現(xiàn)在規(guī)模日益增大的基于 MVC 架構(gòu)的商務(wù)信息管理系統(tǒng)來說，采用RBAC 訪問控制模型的訪問控制模塊將會起到越來越大的作用。綜上分析，控制訪問角色的運(yùn)用是一種開發(fā)和加強(qiáng)企業(yè)特殊安全策略，進(jìn)行安全管理過程流程化的有效手段。運(yùn)用 RBAC 模型可以很好的解決 Web 系統(tǒng)中提出的訪問

29、控制要求，而 DAC、MAC 等等訪問控制技術(shù)由于各種各樣的局限性和特性，都不是 WEB 系統(tǒng)下實(shí)現(xiàn)訪問控制的最好選擇。從目前的應(yīng)用現(xiàn)狀來看，以 MVC 為架構(gòu)而建成的 WEB 網(wǎng)站特別是商務(wù)網(wǎng)站的數(shù)量較為龐大，而由于其自身的管理特性，對安全措施的要求也越來越高，這就要求我們找到一種更為有效的權(quán)限管理方法去適應(yīng)網(wǎng)站對訪問控制技術(shù)的要求。而 RBAC 作為一種科學(xué)、合理、靈活、成熟的訪問控制技術(shù)，最適合于在WEB 環(huán)境下使用，所以如何使它應(yīng)用到那些基于 MVC 架構(gòu)的網(wǎng)站中去，會是一個具有相當(dāng)研究價值的課題。第二章第二章 系統(tǒng)框架分析與設(shè)計系統(tǒng)框架分析與設(shè)計2.12.1 基于基于 MVCMVC

30、架構(gòu)的架構(gòu)的 WebWeb 系統(tǒng)系統(tǒng)在當(dāng)前開發(fā)的商務(wù)系統(tǒng)中，一般都會包括部門管理功能模塊，員工管理功能模塊，工程項(xiàng)目管理功能模塊和員工薪水管理功能模塊，以及包括針對員工使用的信息查看模塊。先下面給出一個已經(jīng)設(shè)計完善的基于 MVC 架構(gòu)的 WEB 網(wǎng)站，系統(tǒng)的功能模塊圖如圖 2-1 所示。系統(tǒng)的功能模塊部門管理模塊員工管理模塊工程項(xiàng)目管理模塊員工工資管理模塊信息查看模塊系統(tǒng)功能管理模塊系統(tǒng)用戶管理模塊系統(tǒng)角色管理模塊圖 2-1 系統(tǒng)功能模塊圖部門管理模塊：針對公司內(nèi)部的所有的部門進(jìn)行管理，用戶可以方便地添加部門、修改部門信息、刪除某一部門和查詢某一部門的信息。員工管理模塊：針對公司內(nèi)部的所有的員

31、工進(jìn)行管理，用戶可以方便地添加員工信息、修改員工信息、刪除某一員工信息和查詢某一部門的所有員工信息。工程項(xiàng)目管理模塊：針對公司的工程項(xiàng)目進(jìn)行管理，用戶可以方便地添加工程項(xiàng)目信息、修改某一工程項(xiàng)目的信息、刪除某工程項(xiàng)目的信息和查詢某一工程項(xiàng)目信息。員工工資管理模塊：針對公司內(nèi)部的所有的員工的薪酬進(jìn)行管理，用戶可以方便地添加工資信息、修改工資信息、刪除工資信息和查詢某一員工在某段時間內(nèi)的所有工資信息。信息查看模塊：針對公司員工設(shè)計的功能模塊，通過該模塊員工可以方便的查看自己的基本信息，工資信息以及所負(fù)責(zé)的工程項(xiàng)目信息。系統(tǒng)功能管理模塊：用戶可以通過該模塊管理系統(tǒng)中涉及到的所有功能，可以添加、刪除和

32、修改。系統(tǒng)用戶管理模塊：用戶可以通過該模塊管理系統(tǒng)中涉及到的所有用戶，可以添加、刪除和修改。系統(tǒng)角色管理模塊：用戶可以通過該模塊為系統(tǒng)中的不同的用戶設(shè)置不同的權(quán)限，并能夠修改某一用戶所賦予的權(quán)限。在上述的商務(wù)系統(tǒng)中，在安全性上一般會有如下的要求：能夠很好的實(shí)現(xiàn)訪問控制。在一個企業(yè)中，存在著很多種不同的用戶，如經(jīng)理、董事長、一般職工，系統(tǒng)維護(hù)人員等。當(dāng)所有的用戶面對同一個系統(tǒng)時，就應(yīng)該做到用戶之間要有區(qū)分，即進(jìn)入系統(tǒng)后不同的用戶只能實(shí)行自身擁有的權(quán)限，不可以越權(quán)。部分信息的保密。公司中存在著一些決定企業(yè)利益的信息，這些信息只能由公司的管理人員來查看和管理，任何非法的侵入都有可能造成不良的后果?，F(xiàn)

33、代主流的 Web 系統(tǒng)的體系架構(gòu)設(shè)計基于 J2EE 平臺上的 MVC 設(shè)計模式，應(yīng)用 Struts 框架，采用 B/S 模式，具體的架構(gòu)設(shè)計如圖 2-2 所示。ActionActionActionHTMLJSPsStruts Tags(JSTL)Style SheetActionServletRequestProcessorWeb ContainerControllerModelPresentationLayerHttp ResponseHttp RequestBusinessManagement_MessagerRpertiesStruts-config.xmlVie

34、wJavaBeanBusinessObjectsDatabase LayerWeb.xmlBusiness LayerClientLayer圖 2-2 商務(wù)管理系統(tǒng)架構(gòu)圖在圖 2-2 中，系統(tǒng)架構(gòu)可以細(xì)分為以下 4 個層次：客戶層（Client Layer）：運(yùn)行在用戶機(jī)器的瀏覽器中，處理與用戶的交互。表現(xiàn)層（Presentation Layer）：運(yùn)行在 J2EE Web 容器中，產(chǎn)生系統(tǒng)的表現(xiàn)邏輯，處理用戶的請求并做出響應(yīng)；整個 Web 層建立在 Struts 框架基礎(chǔ)上，其中 View 由 HTML 和 JSP 頁面組成，其數(shù)據(jù)表示是 ActionForm Oracle 9iBrowse

35、rBean；Controller 由 ActionServlet 組合 Struts-config.xml 和 Action 類組成；而 Model 則交由業(yè)務(wù)邏輯層來實(shí)現(xiàn)。業(yè)務(wù)邏輯層（Business Layer）：運(yùn)行在 J2EE Web 容器中，完成系統(tǒng)的業(yè)務(wù)需求，為 Web 層提供所需的業(yè)務(wù)方法，由 JavaBean 構(gòu)成系統(tǒng)的 Business Objects（BO） ，并使用 DAO 模式把數(shù)據(jù)訪問封裝起來，以供在其他應(yīng)用層中統(tǒng)一調(diào)用。數(shù)據(jù)源層（Database Layer）：即數(shù)據(jù)庫層，存放系統(tǒng)的應(yīng)用數(shù)據(jù)，系統(tǒng)采用 Oracle9i 作為數(shù)據(jù)庫服務(wù)器。系統(tǒng)的架構(gòu)可以表示為 JSP

36、+Struts+Database。使用這種架構(gòu)一方面便于系統(tǒng)的開發(fā)和管理；另一方面，層與層之間的開發(fā)幾乎是完全獨(dú)立的，從而降低了數(shù)據(jù)在各層之間的耦合性，提高了系統(tǒng)的可維護(hù)性和可擴(kuò)展性。此外，系統(tǒng)是由 Java 來開發(fā)實(shí)現(xiàn)的，Java 的跨平臺特性實(shí)現(xiàn)了系統(tǒng)的可移植性。2.22.2 RBACRBAC 模型的建立模型的建立根據(jù)上述商務(wù)系統(tǒng)對安全性的需求，通過在 Web 系統(tǒng)中使用 RBAC 模型可以很好的滿足各項(xiàng)需求。RBAC 的核心思想就是：根據(jù)用戶需求，給用戶分派各種角色，為不同的角色分配各種權(quán)限，用戶通過自己所屬的角色獲得操作權(quán)限許可。其核心模型如圖 2-3 所示。圖 2-3 RBAC 模型

37、核心 RBAC 模型的組成部分是：Users：用戶集u1，u2，u3 ，un；Roles：角色集r1，r2，r3， ，rn；OPS：操作集op1，op2，op3，opnOBJ：客體集obj1，obj2，obj3，objnP= OPS X 0BJ：權(quán)限集是不同客體上不同操作的描述pl，p2，p3，. ，pnRolesUsersUA*：用戶角色分配關(guān)系：多對多；Assigned-users：，角色與用戶的映射，將一個角色與一組用戶相映射；：權(quán)限-角色分配關(guān)系，多對多；Assigned privileges ： ，角色與權(quán)限的映射，將一個角色與一組權(quán)限相映射；Session ：會話集s1，s2，s3

38、，sn User_sessions ：，用戶與會話的映射，將一個用戶與一個會話相映射；Session_roles ：，會話與角色的映射，將一個會話與一組角色相映射；Avail_session_privilege ：，在一次會話中一個用戶允許的權(quán)限；用戶：不僅指人，也可以指機(jī)器，網(wǎng)絡(luò)或智能代理。角色：管理員依據(jù)安全策略劃分出來的操作集合，表示該角色成員所授予的職權(quán)和責(zé)任?？腕w：指系統(tǒng)需要保護(hù)的資源。權(quán)限：對系統(tǒng)中的客體進(jìn)行特定存取的許可。權(quán)限是與客體緊密相關(guān)的，不同的系統(tǒng)，其權(quán)限規(guī)定是不同的，既可以指網(wǎng)絡(luò)的應(yīng)用，如對某個子網(wǎng)的訪問權(quán)限，也可以指對數(shù)據(jù)庫的表單等的訪問。權(quán)限的粒度大小取決于實(shí)際系統(tǒng)

39、的定義。會話：為了對系統(tǒng)資源進(jìn)行操作，用戶需要建立會話，每個會話將一個用戶與他所對應(yīng)的角色集中的一部分建立映射關(guān)系，這一角色子集成為被會話激活的角色，在這次會話中，用戶可以執(zhí)行的操作就是該會話激活的角色對應(yīng)的權(quán)限所允許的操作。上述 RBAC 模型是 RBAC 核心模型，此模型保留了 RBAC 的最小特征集，是每個 RBAC 系統(tǒng)都需要的元素。2.32.3 RBACRBAC 模型在模型在 MVCMVC 網(wǎng)站中的應(yīng)用網(wǎng)站中的應(yīng)用由需求分析可知，需要為企業(yè)內(nèi)部網(wǎng)管理系統(tǒng)設(shè)計一個用戶權(quán)限管理的功能模塊，從而達(dá)到對用戶權(quán)限進(jìn)行管理的目的。當(dāng)今的大型的信息管理系統(tǒng)都具有功能復(fù)雜，用戶眾多的特點(diǎn)，如果仍采用

40、傳統(tǒng)的權(quán)限管理方式，直接將權(quán)限分配給用戶，對具有相同權(quán)限的一類用戶同樣的授權(quán)操作將被重復(fù)很多遍，一旦用戶工作崗位有變化，則對其權(quán)限的調(diào)整將非常復(fù)雜，而基于 RBAC 模型的權(quán)限控制方法則大大簡化了這種授權(quán)管理的復(fù)雜度，降低了系統(tǒng)管理的開銷。RBAC 模型描述了一種良好的訪問控制方法和原理。通過在商務(wù) Web 系統(tǒng)中使用 RBAC 模型可以方便、科學(xué)、合理地進(jìn)行訪問控制，有了良好的訪問控制，不同的用戶在使用系統(tǒng)的時候僅能訪問自身被賦予的權(quán)限，用戶之間不能越權(quán)訪問，從而保證了信息的安全性和一致性，從而提高了系統(tǒng)的安全性。通過以下幾個步驟，可以將 RBAC 模型應(yīng)用在 MVC 網(wǎng)站中。（1）建立功能

41、的概念。功能，即操作。在系統(tǒng)中，如對員工的添加、刪除和修改的操作，都可以描述為一個功能。（2）建立權(quán)限節(jié)點(diǎn)的概念。權(quán)限節(jié)點(diǎn)，顧名思義，它對應(yīng)著一個或一組功能操作菜單，表示了該節(jié)點(diǎn)可以進(jìn)行系統(tǒng)操作的范圍。（3）建立角色的概念。將角色與節(jié)點(diǎn)對應(yīng)起來，一個角色可以對應(yīng)多個節(jié)點(diǎn)，一個節(jié)點(diǎn)也可以對應(yīng)多個角色，這是一個多對多的關(guān)系。角色與節(jié)點(diǎn)對應(yīng)好之后，也就意味著角色與某一個或某一組功能操作菜單建立了關(guān)聯(lián)。系統(tǒng)中存在不同類型的用戶，也即不同的用戶隸屬于不同的角色。（4）將系統(tǒng)的用戶和角色關(guān)聯(lián)起來。一旦一個用戶被設(shè)置了某個角色，那么也就意味著該用戶具有了某些權(quán)限。具有了某些權(quán)限，也就意味著擁有了某些功能（對

42、系統(tǒng)的操作和管理） 。舉例來說，假設(shè)系統(tǒng)中存在兩個權(quán)限節(jié)點(diǎn) 1 和 2，兩個角色 A 和 B，用戶有甲（經(jīng)理）和乙（部門經(jīng)理） ，很顯然甲和乙在登陸系統(tǒng)后應(yīng)該具有不同的權(quán)限，甲可以管理整個公司的信息，而乙僅能管理所在部門的信息。這時，設(shè)定權(quán)限節(jié)點(diǎn) 1 下包含了管理整個公司信息的所有功能，權(quán)限節(jié)點(diǎn) 2 下包含了管理某個部門信息的所有功能；將角色 A 與節(jié)點(diǎn) 1 進(jìn)行關(guān)聯(lián)，將角色 B 與節(jié)點(diǎn) 2 進(jìn)行關(guān)聯(lián)。最后，將用戶甲的角色設(shè)定為角色 A，用戶乙的角色設(shè)定為角色 B。在用戶甲和乙登陸系統(tǒng)后，就會看到自己所具有的功能菜單，其他用戶的功能菜單是非可見的，從而實(shí)現(xiàn)了訪問控制。簡言之，通過在系統(tǒng)中設(shè)置功

43、能、權(quán)限和角色的概念，就可以在系統(tǒng)中實(shí)現(xiàn) RBAC 模型，并讓它很好地為 Web 系統(tǒng)提供訪問控制功能。第三章第三章 設(shè)計實(shí)現(xiàn)設(shè)計實(shí)現(xiàn)3.13.1 RBACRBAC 框架實(shí)現(xiàn)框架實(shí)現(xiàn)數(shù)據(jù)存儲是個非常重要的功能需求。系統(tǒng)中很多的地方都要存儲數(shù)據(jù)，并且其格式要求也不相同，數(shù)據(jù)量也差別較大。良好的設(shè)計不但能減少因數(shù)據(jù)保存不當(dāng)造成的對系統(tǒng)的損害，而且能顯著地提高系統(tǒng)的性能。在考慮數(shù)據(jù)存儲方案時，有三種可行的選擇，分別是文件方式、數(shù)據(jù)庫方式、LDAP 方式，這三種方式都有各自的優(yōu)缺點(diǎn)。文件方式的好處在于簡單直觀，存取速度最快，但不夠安全，在 RBAC 的早期版本中，我們采用的就是文件方式。LDAP 方式

44、可以保證數(shù)據(jù)的安全和完整性，但使用不方便，普及程度也不高；數(shù)據(jù)庫方式是業(yè)界比較認(rèn)可的主流存儲方案，而且現(xiàn)在的數(shù)據(jù)庫技術(shù)也比較成熟，是較為理想的選擇。有鑒于此，我們在系統(tǒng)中采用了數(shù)據(jù)庫方式作為本系統(tǒng)數(shù)據(jù)存儲方案。以下為數(shù)據(jù)存儲的表結(jié)構(gòu)：1、P_YHB 用戶表用于記錄用戶基本信息。如表 3-1 所示。表表 3-13-1 用戶表用戶表編號列名類型長度說明約束1*YHIDVARCHAR8用戶 ID2YHMCVARCHAR20用戶名稱3YHMMVARCHAR25用戶密碼4SSBMVARCHAR5用戶所屬部門5YHMSVARCHAR500用戶描述2、P_JSB 角色表記錄和角色相關(guān)和信息。如表 3-2 所

45、示。表表 3-23-2 角色表角色表編號列名類型長度說明約束1*JSIDVARCHAR5角色 ID2JSMCVARCHAR50角色名稱3JSMSVARCHAR200角色描述可為空4JSXYHZDSNUMBER10此角色下的用戶最大數(shù)可為空5JSLXVARCHAR1角色類型3、P_YHJSB 用戶角色表用于記錄用戶角色指派的內(nèi)容，即記錄每個角色被賦予了哪些用戶。如表3-3 所示。表表 3-33-3 用戶角色表用戶角色表編號列名類型長度說明約束1*YHIDVARCHAR8用戶 ID1.12*JSIDVARCHAR5角色 ID2.14、P_GNB 功能表存放權(quán)限，一條記錄就是一個權(quán)限，一個權(quán)限指的是

46、一個用戶可以使用的一個功能項(xiàng)，在表中記錄了該權(quán)限對應(yīng)的主 URL。如表 3-4 所示。表表 3-43-4 功能表功能表編號列名類型長度說明約束1*GNIDVARCHAR5功能 ID2GNMCVARCHAR50功能名稱3GNMSVARCHAR500功能描述可為空4ZURLVARCHAR200主 URL5CZVARCHAR1操作（只讀、讀寫、執(zhí)行）5、P_JSJDB 角色節(jié)點(diǎn)表記錄權(quán)限角色指派的內(nèi)容，即記錄每個角色所擁有的權(quán)限信息。如表 3-5所示。表表 3-53-5 角色節(jié)點(diǎn)表角色節(jié)點(diǎn)表編號列名類型長度說明約束1*JSIDVARCHAR5角色 ID2.12*JDIDVARCHAR5節(jié)點(diǎn) ID6.

47、16、P_JDB 節(jié)點(diǎn)表記錄每個節(jié)點(diǎn)信息。如表 3-6 所示。表表 3-63-6 節(jié)點(diǎn)表節(jié)點(diǎn)表編號列名類型長度說明約束1*JDIDVARCHAR5節(jié)點(diǎn) ID2.JDMCVARCHAR50節(jié)點(diǎn)名稱3.FJDIDVARCHAR5父節(jié)點(diǎn) ID4JDMSVARCHAR500節(jié)點(diǎn)描述5JDNXHVARCHAR2節(jié)點(diǎn)內(nèi)序號7、P_JDGNB 節(jié)點(diǎn)表記錄每個節(jié)點(diǎn)所包含的權(quán)限信息。如表 3-7 所示。表表 3-73-7 節(jié)點(diǎn)功能表節(jié)點(diǎn)功能表編號列名類型長度說明約束1IDVARCHAR1節(jié)點(diǎn)層次2*GNIDVARCHAR5節(jié)點(diǎn) ID3*JDIDVARCHAR5節(jié)點(diǎn) ID8、P_DEPARTMENT 企業(yè)部門表記

48、錄每個企業(yè)部門所包含的部門信息。如表 3-8 所示。表表 3-83-8 企業(yè)企業(yè)部門表部門表編號列名類型長度說明約束1*DEPBMVARCHAR3部門編號2DEPMCVARCHAR100部門名稱3DEPLXDHVARCHAR25部門聯(lián)系電話4DEPMANAGERVARCHAR8部門負(fù)責(zé)人9、P_PROJECT 企業(yè)工程項(xiàng)目表記錄每個工程項(xiàng)目所包含的工程項(xiàng)目信息。如表 3-9 所示。表表 3-93-9 企業(yè)工程項(xiàng)目表企業(yè)工程項(xiàng)目表編號列名類型長度說明約束1*PRJBHVARCHAR20項(xiàng)目編號2PRJNAMEVARCHAR100項(xiàng)目名稱3PRJMANVARCHAR20項(xiàng)目負(fù)責(zé)人11.14PRJM

49、ONEYVARCHAR40項(xiàng)目資金5PRJDATEDATE立項(xiàng)日期10、P_SALARY 企業(yè)員工工資表記錄每個企業(yè)員工的工資信息。如表 3-10 所示。表表 3-103-10 企業(yè)員工工資企業(yè)員工工資表表編號列名類型長度說明約束1*IDNUMBER工資帳單序號2SALARY_NUMVARCHAR10工資帳單金額3WORKERBMVARCHAR10員工編號11.14SALARY_DATEDATE工資帳單發(fā)放日期11、P_WORKER 企業(yè)員工信息表記錄每個企業(yè)員工的信息。如表 3-11 所示。表表 3-113-11 企業(yè)員工表企業(yè)員工表編號列名類型長度說明約束1*WORKERBMVARCHAR

50、10員工編號2WORKERMCVARCHAR50員工姓名3WORKERAGEVARCHAR3員工年齡4WORKERSEXVARCHAR1員工性別5WORKERADDRESSVARCHAR200員工地址6WORKERLXDHVARCHAR50員工聯(lián)系電話7WORKERZJHMVARCHAR50員工證件號碼8WORKERDEPBMVARCHAR5員工所在部門 RBACRBAC 模型在系統(tǒng)中的實(shí)現(xiàn)模型在系統(tǒng)中的實(shí)現(xiàn) 系統(tǒng)功能模塊的實(shí)現(xiàn)系統(tǒng)功能模塊的實(shí)現(xiàn)在功能管理模塊中，用戶可以進(jìn)行的操作有：功能添加、修改和刪除。系統(tǒng)功能添加的實(shí)現(xiàn)過程可以描述為：瀏覽器ActionForm 類Act

51、ion 類提交表單Struts-config.xml封裝表單數(shù)據(jù)調(diào)用查找JavaBean轉(zhuǎn)向圖 3-1 系統(tǒng)功能模塊實(shí)現(xiàn)的流程圖從圖 3-1 可以看出，用戶在試圖添加一個系統(tǒng)功能時，應(yīng)該首先填寫表單，填寫好表單后，點(diǎn)擊表單的提交按鈕之后，會觸發(fā)一個請求事件（Action） ，該數(shù)據(jù)庫事件由頁面的表單指定。在 Struts-config.xml 文檔中找到相應(yīng)的 Action，同時得到該 Action 使用的 ActionForm 類。此時表單的數(shù)據(jù)將會保存到該ActionForm 類中，在 Action 中就可以得到表單中的數(shù)據(jù)。為了完成最終的功能添加，在相應(yīng)的 Action 實(shí)現(xiàn)類中，還需要

52、調(diào)用模型層中的業(yè)務(wù)功能函數(shù)，來完成此次的業(yè)務(wù)邏輯。在相應(yīng)的 JavaBean 中，完成與數(shù)據(jù)庫的交互，實(shí)現(xiàn)對數(shù)據(jù)的添加。用到的 ActionForm 類是 GnoperatorForm 類，該類繼承 ActionForm 類，并具有 gnid,cz,ljxjd,gnmc,gnms,zurl 等屬性。GnoperatorForm 的部分實(shí)現(xiàn)代碼如下：public class GnoperatorForm extends ActionForm private static final long serialVersionUID = 1L；private String gnid；private St

53、ring cz；private String ljxjd；private String gnmc；private String gnms；private String kfgb；private String zurl；public String getGnmc() return gnmc；public void setGnmc(String gnmc) this.gnmc = gnmc；public String getGnms() return gnms；public void setGnms(String gnms) this.gnms = gnms；實(shí)現(xiàn)功能添加的 Action 類 Gn

54、operatorAction.java,部分實(shí)現(xiàn)代碼如下：public class GnoperatorAction extends Action public ActionForward execute(ActionMapping mapping, ActionForm form,HttpServletRequest request, HttpServletResponse response) ActionForward nextdisplay = new ActionForward()； / 生成一個 ActionForward 對象String actionmappingpara = m

55、apping.getParameter()； / 接收 ActionMaping 的參數(shù)if (gnoperator.equalsIgnoreCase(actionmappingpara) nextdisplay = gnoperator(mapping, form, request, response)； else if (gnoperator_update.equalsIgnoreCase(actionmappingpara) nextdisplay = gnoperator_update(mapping, form, request, response)； else if (gnoper

56、ator_getgn.equalsIgnoreCase(actionmappingpara) nextdisplay = gnoperator_getgn(mapping, form, request, response)；return nextdisplay；/完成功能添加的實(shí)現(xiàn)方法public ActionForward gnoperator(ActionMapping mapping,ActionForm form,HttpServletRequest request, HttpServletResponse response) GnoperatorForm gnof = (Gnoper

57、atorForm) form；ActionForward forward = new ActionForward()；String method = (String) request.getParameter(method)；dbOp db = new dbOp()；response.setCharacterEncoding(gbk)；if (method.equalsIgnoreCase(insert) / 新增功能if (db.insertintoGnb(gnof) gnof.setGnmc()；gnof.setGnms()；gnof.setZurl()；gnof.setZimc(null

58、)；gnof.setZims(null)；gnof.setZiurl(null)；request.setAttribute(result, success)；forward = mapping.findForward(success)； else request.setAttribute(result, failure)；forward = mapping.findForward(failure)； else if (method.equalsIgnoreCase(update) / 更新功能if (db.UpdateGnb(gnof) request.setAttribute(result,

59、 更新成功)；forward = mapping.findForward(successupdate)； else request.setAttribute(result, 更新失敗)；forward = mapping.findForward(failureupdate)；db.close()；return forward；完成功能添加的業(yè)務(wù)函數(shù)存放在 dbOp 類中，它的部分實(shí)現(xiàn)代碼如下：public class dbOp extends DBOperator /* * 插入一個新的功能 */public boolean insertintoGnb(GnoperatorForm gnof)

60、 String gnmc = this.toGBK(gnof.getGnmc()；String zurl = this.toGBK(gnof.getZurl()；String gnms = this.toGBK(gnof.getGnms()；String ljxjd = gnof.getLjxjd()；boolean b = false；String sql = insert into p_gnb(gnid, gnmc, gnms, zurl, cz, ljxjd, sfglip, kfgb) + values (p_gnidxl.nextval,+ gnmc+ ,+ gnms + ,+ zu