J2EE架构的6个最佳实践.docVIP

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 dat