J2EE架构学习者的6个最佳实践

　　虽然许多文章曾经讨论过J2EE最佳实践。那么，为什么我还要再写一篇文章呢？本文究竟与以前的文章有何不同或者说比其他文章好在哪呢？

　　首先，本文的目标读者是正在从事技术工作的架构师。为了避免浪费大家的才智，我会避免讲述一些陈腐的最佳实践，例如"日常构建（build daily）"、"测试一切（test everything）"和"经常集成（ integrate often）。 任何具有称职架构师的项目都有分工明确的、定义良好的团队结构。他们还为进行编码检查、构建代码（每日或在需要时）、进行测试（单元、集成和系统的）、部署和配置/释放管理而具备已记录的过程。

　　其次，我将跳过通常吹捧的最佳实践，例如"基于接口的设计"、"使用著名的设计模型"以及"使用面向服务的架构"等。相反，我将集中讲述我曾学过并且使用了若干年的6（不是很多）个方面的in-the-trench课程。最后，本文的目的是让您思考一下自己的架构，提供工作代码示例或者解决方案超出了本文的范围。下面就让我介绍一下这6课：

　　第1课：切勿绕过服务器端验证

　　作为一位软件顾问，我曾有机会不但设计并实现了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、防火墙等都派不上用场了。

　　第2课：安全并非是附加物

　　如第1课所述，我曾有幸研究过许多Web应用程序。我发现所有的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上，我们也没有注意到安全性。为了更改发布计划，我们卷入了与项目资助人及其管理人员的争斗中，以便在第一版中包含所有与安全相关的功能，并将一些"业务"功能放在后续的版本中。最终，我们赢得了胜利。而且由于应用程序的安全性相当高，能够保护客户的私有数据，这一点我们引以为荣，我们的客户也非常高兴。

　　遗憾的是，在大多数应用程序中，安全性看起来并未增加任何实际的商业价值，所以直到最后才解决。发生这种情况时，人们才匆忙开发与安全相关的代码，而丝毫没有考虑解决方案的长期可维护性或者健壮性。忽视该安全性的另一个征兆是缺乏全面的服务器端验证，如我在第1课中所述，这一点是安全Web应用程序的一个重要组成部分。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有