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

核心提示：虽然许多文章曾经讨论过J2EE最佳实践，那么，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）都有一个共同的主题，那就是具有类似下面伪代码的布局：