值得思考的 J2EE 架構的6個最佳實踐

2019-11-18 12:28:15

字體：大中小

來源：轉載

供稿：網友

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

上一篇：基于 J2EE 體系實現多層結構 Blog 平臺（2）

下一篇：企業級應用中開發 J2EE 應用的黃金要領