值得思考的 J2EE 架構(gòu)的6個最佳實踐

2019-11-18 12:28:15

字體：大中小

供稿：網(wǎng)友

　　作為一位軟件顧問，我曾有機會不但設(shè)計并實現(xiàn)了Web應用程序，而且還評估/審核了許多Web應用程序。在復雜的、并且用javascript客戶端封裝的應用程序內(nèi)，我經(jīng)常碰到對用戶輸入信息執(zhí)行大量檢查的Web頁面。即使Html元素具有數(shù)據(jù)有效性的屬性也如此，例如MAXLENGTH。只有在成功驗證所有輸入信息后，才能提交HTML表單。結(jié)果，一旦服務(wù)器端收到通知表單（請求），便恰當?shù)貓?zhí)行業(yè)務(wù)邏輯。
　　
　　在此，您發(fā)現(xiàn)問題了么？開發(fā)人員已經(jīng)做了許多重要的假設(shè)。例如，他們假設(shè)所有的Web應用程序用戶都同樣老實。開發(fā)人員還假設(shè)所有用戶將總是使用他們測試過的瀏覽器訪問Web應用程序。還有很多其他的假設(shè)。這些開發(fā)人員忘記了利用可以免費得到的工具，通過命令行很輕易地模擬類似瀏覽器的行為。事實上，通過在瀏覽器窗口中鍵入適當?shù)腢RL，您可以發(fā)送任何“posted”表單，盡管如此，通過禁用這些頁面的GET請求，您很輕易地阻止這樣的“表單發(fā)送”。但是，您不能阻止人們模擬甚至創(chuàng)建他們自己的瀏覽器來入侵您的系統(tǒng)。
　　
　　根本的問題在于開發(fā)人員不能確定客戶端驗證與服務(wù)器端驗證的主要差別。兩者的主要差別不在于驗證究竟發(fā)生在哪里，例如在客戶端或者在服務(wù)器端。主要的差別在于驗證背后的目的不同。客戶端驗證僅僅是方便。執(zhí)行它可為用戶提供快速反饋，使應用程序似乎做出響應，給人一種運行桌面應用程序的錯覺。
　　
　　另一方面，服務(wù)器端驗證是構(gòu)建安全Web應用程序必需的。不管在客戶端一側(cè)輸入的是什么，它可以確保客戶端送往服務(wù)器的所有數(shù)據(jù)都是有效的。因而，只有服務(wù)器端驗證才可以提供真正應用程序級的安全。許多開發(fā)人員陷入了錯誤感覺的圈套：只有在客戶端進行所有數(shù)據(jù)的驗證才能確保安全。下面是說明此觀點的一個常見的示例：
　　
　　一個典型的登錄頁面擁有一個用來輸入用戶名的文本框和一個輸入密碼的文本框。在服務(wù)器端，某人在接收servlet中可能碰到一些代碼，這些代碼構(gòu)成了下面形式的SQL查詢：
　　
　　"SELECT * FROM SecurityTable
　　WHERE username = '" +
　　form.getParameter("username")
　　+ "' AND passWord =
　　'" + form.getParameter("password") + "';"
　　
　　并執(zhí)行這些代碼。假如查詢在結(jié)果集的某一行返回，則用戶登錄成功，否則用戶登錄失敗。第一個問題是構(gòu)造SQL的方式，但現(xiàn)在讓我們暫時忽略它。假如用戶在用戶名中輸入“Alice'--”會怎樣呢？假設(shè)名為“Alice”的用戶已經(jīng)在SecurityTable中，這時此用戶（更恰當?shù)恼f法是黑客）成功地登錄。我將把找出為什么會出現(xiàn)這種情況的原因做為留給您的一道習題。
　　
　　許多創(chuàng)造性的客戶端驗證可以阻止一般的用戶從瀏覽器中這樣登錄。但對于已經(jīng)禁用了Javascript的客戶端，或者那些能夠使用其他類似瀏覽器程序直接發(fā)送命令（HTTP POST和GET命令）的高級用戶（或者說黑客）來說，我們又有什么辦法呢？服務(wù)器端驗證是防止這種漏洞類型所必須的。這時，SSL、防火墻等都派不上用場了。
　　
　　安全并非是附加物
　　我發(fā)現(xiàn)所有的JavaServer Page（jsp）都有一個共同的主題，那就是具有類似下面?zhèn)未a的布局：
　　
　　<%
　　User user =
　　session.getAttribute("User");
　　if(user == null)
　　{
　　// redirect to
　　// the logon page…
　　}
　　if(!user.role.equals("manager"))
　　{
　　// redirect to the
　　// "unauthorized" page…
　　}
　　%>
　　
　　<!-
　　HTML, JavaScript, and JSP
　　code to display data and
　　allow user interaction -->
　　
　　假如項目使用諸如Struts這樣的MVC框架，所有的Action Bean都會具有類似的代碼。盡管最后這些代碼可能運行得很好，但假如您發(fā)現(xiàn)一個bug，或者您必須添加一個新的角色（例如，“guest”或者“admin”），這就會代表一場維護惡夢。
　　
　　此外，所有的開發(fā)人員，不管您多年輕，都需要熟悉這種編碼模式。當然，您可以用一些JSP標簽來整理JSP代碼，可以創(chuàng)建一個清除派生Action Bean的基本Action Bean。盡管如此，由于與安全相關(guān)的代碼會分布到多個地方，所以維護時的惡夢仍然存在。由于Web應用程序的安全是強迫建立在應用程序代碼的級別上（由多個開發(fā)人員），而不是建立在架構(gòu)級別上，所以Web應用程序還是很可能存在弱點。
　　
　　很可能，根本的問題是在項目接近完成時才處理安全性問題。最近作為一名架構(gòu)師，我曾在一年多的時間里親歷了某一要實現(xiàn)項目的6個版本，而直到第四版時我們才提到了安全性。即使該項目會將高度敏感的個人數(shù)據(jù)暴露于Web上，我們也沒有注重到安全性。為了更改發(fā)布計劃，我們卷入了與項目資助人及其治理人員的爭斗中，以便在第一版中包含所有與安全相關(guān)的功能，并將一些“業(yè)務(wù)”功能放在后續(xù)的版本中。最終，我們贏得了勝利。而且由于應用程序的安全性相當高，能夠保護客戶的私有數(shù)據(jù)，這一點我們引以為榮，我們的客戶也非常興奮。
　　
　　遺憾的是，在大多數(shù)應用程序中，安全性看起來并未增加任何實際的商業(yè)價值，所以直到最后才解決。發(fā)生這種情況時，人們才匆忙開發(fā)與安全相關(guān)的代碼，而絲毫沒有考慮解決方案的長期可維護性或者健壯性。忽視該安全性的另一個征兆是缺乏全面的服務(wù)器端驗證，這一點是安全Web應用程序的一個重要組成部分。
　　
　　記住：J2EE Web應用程序的安全性并非僅僅是在Web.xml 和ejb-jar.xml文件中使用合適的聲明，也不是使用J2EE技術(shù)，如Java 認證和授權(quán)服務(wù)（Java Authentication and Authorization Service，JAAS）。而是經(jīng)過深思熟慮后的設(shè)計，且實現(xiàn)一個支持它的架構(gòu)。
　　
　　國際化（I18N）不再是紙上談兵
　　當今世界的事實是許多英語非母語的人們將訪問您的公共Web應用程序。隨著電子政務(wù)的實行，由于它答應人們（某個國家的居民）在線與政府機構(gòu)交互，所以這一點非凡真實。這樣的例子包括換發(fā)駕照或者車輛登記證。許多第一語言不是英語的人們很可能將訪問這樣的應用程序。國際化（即：“i18n”，因為在“internationalization”這個單詞中，字母i和字母n之間一共有18個字母）使得您的應用程序能夠支持多種語言。
　　
　　顯然，假如您的JSP頁面中有硬編碼的文本，或者您的Java代碼返回硬編碼的錯誤消息，那么您要花費很多時間開發(fā)此Web應用程序的西班牙語版本。然而，在Web應用程序中，為了支持多種語言，文本不是惟一必須“具體化”的部分。因為許多圖像中嵌有文字，所以圖形和圖像也應該是可配置的。在極端的情況下，圖像（或者顏色）在不同的文化背景中可能有完全不同的意思。類似地，任何格式化數(shù)字和日期的Java代碼也必須本地化。但問題是：您的頁面布局可能也需要更改。
　　
　　例如，假如您使用HTML表格來格式化和顯示菜單選項、應用程序題頭或注腳，則您可能必須為每一種支持的語言更改每一欄的最小寬度和表格其他可能的方面。為了適應不同的字體和顏色，您可能必須為每一種語言使用單獨的樣式表。
　　
　　顯然，現(xiàn)在創(chuàng)建一個國際化的Web應用程序面臨的是架構(gòu)挑戰(zhàn)而不是應用程序方面的挑戰(zhàn)。一個架構(gòu)良好的Web應用程序意味著您的JSP頁面和所有與業(yè)務(wù)相關(guān)的（應用程序特有的）Java代碼都不知不覺地選擇了本地化。要記住的教訓是：不要因為Java、J2EE支持國際化而不考慮國際化。您必須從第一天起就記住設(shè)計具有國際化的解決方案。
　　
　　在MVC表示中避免共同的錯誤
　　J2EE開發(fā)已經(jīng)足夠成熟，在表示層，大多數(shù)項目使用MVC架構(gòu)的某些形式，例如Struts。在這樣的項目中，我常見到的現(xiàn)象是對MVC模式的誤用。下面是幾個示例。常見的誤用是在模型層（例如，在Struts的Action Bean中）實現(xiàn)了所有的業(yè)務(wù)邏輯。不要忘了，表示層的模型層仍然是表示層的一部分。使用該模型層的正確方法是調(diào)用適當?shù)臉I(yè)務(wù)層服務(wù)（或?qū)ο螅┎⒔Y(jié)果發(fā)送到視圖層（view layer）。用設(shè)計模式術(shù)語來說，MVC表示層的模型應該作為業(yè)務(wù)層的外觀（Fa?ade）來實現(xiàn)。更好的方法是，使用核心J2EE模式（Core J2EE Patterns）中論述到的Business Delegate模式。這段自書中摘錄的內(nèi)容出色地概述了將您的模型作為Business Delegate來實現(xiàn)的要點和優(yōu)點：
　　
　　Business Delegate起到客戶端業(yè)務(wù)抽象化的作用。它抽象化，進而隱藏業(yè)務(wù)服務(wù)的實現(xiàn)。使用Business Delegate，可以降低表示層客戶端和系統(tǒng)的業(yè)務(wù)服務(wù).之間的耦合程度。根據(jù)實現(xiàn)策略不同，Business Delegate可以在業(yè)務(wù)服務(wù)API的實現(xiàn)中，保護客戶端不受可能的變動性影響。這樣，在業(yè)務(wù)服務(wù)API或其底層實現(xiàn)變化時，可以潛在地減少必須修改表示層客戶端代碼的次數(shù)。
　　
　　另一個常見的錯誤是在模型層中放置許多表示類型的邏輯。例如，假如JSP頁面需要以指定方式格式化的日期或者以指定方式排序的數(shù)據(jù)，某些人可能將該邏輯放置在模型層，對該邏輯來說，這是錯誤的地方。實際上，它應該在JSP頁面使用的一組helper類中。當業(yè)務(wù)層返回數(shù)據(jù)時，Action Bean應該將數(shù)據(jù)轉(zhuǎn)發(fā)給視圖層。這樣，無需創(chuàng)建模型和視圖之間多余的耦合，就能夠靈活支持多個視圖層（JSP、Velocity、XML等）。也使視圖能夠確定向用戶顯示數(shù)據(jù)的最佳方式。
　　
　　最后，我見過的大多數(shù)MVC應用程序都有未充分應用的控制器。例如，絕大多數(shù)的Struts應用程序?qū)?chuàng)建一個基本的Action類，并完成所有與安全相關(guān)的功能。其他所有的Action Bean都是此基類的派生類。這種功能應該是控制器的一部分，因為假如沒有滿足安全條件，則首先調(diào)用不應該到達Action Bean（即：模型）。記住，一個設(shè)計良好的MVC架構(gòu)的最強大功能之一是存在一個健壯的、可擴展的控制器。您應該利用該能力以加強自己的優(yōu)勢。
　　
　　不要被JOPO束縛住手腳
　　我曾目睹許多項目為了使用EnterPRise JavaBean而使用

上一篇：基于 J2EE 體系實現(xiàn)多層結(jié)構(gòu) Blog 平臺（2）

下一篇：企業(yè)級應用中開發(fā) J2EE 應用的黃金要領(lǐng)