Web应用的前景是在不断的演进中的，它已经从最开始作为共享文档和信息的方式演化为业务治理的平台，而在这种应用中，许可和授权是一个要害的特征。Web的应用前景还在不断的演进中，而本文把关注放在面向群体的应用中，例如博可和维基。在这种应用中，由于作者希望有交流和反馈，所以授权不是非常严格的。有时，由于害怕识别，会造成失去一些人可能做出的贡献。但是，缺少授权就会带来诸如垃圾邮件这类的问题。这里有几条在Web上抽取的信息：
·我认为在维基上垃圾邮件是不可避免的。我建立了这个网站维基的一部分，把修改权限
平开放给每个人，以鼓励读者和来访者互相交流。但是，这已经是第二次了，一个发垃圾邮件的人把一堆到中国网站的链接放在这的网页里。（摘自X-Pollen）
·“致所有在维基上发垃圾邮件的人：从1-2-2005起，任何人要做任何操作，包括编辑或增加新页，都要由搜索引擎强制间隔十个小时。由于在这个网站上发的垃圾邮件在一分钟、最多一小时内就会被删除，所以，任何试图在这个网站上建立发垃圾邮件的机制都是徒劳的举动。（摘自C2 Wiki）”
很明显，垃圾邮件发送源必须被识别出来。大多数者类恶意的攻击发生数据匹配模式被识出来之后。一个可能的方法是人工而不是有计算机来停止这种攻击，很显然这是个挑战。通过图灵测试，按一个有名的计算机专家――阿兰。图灵命名的试验，可以确定机器能够实现类似人类操作的能力。者类测试中最有名的一个是CAPTCHA (an acronym for completely automated public Turing test to tell computers and humans apart)。这个测试常用来表明以个典型的情况：混乱或含义模糊的词，人很轻易识别，但对于光学识别软件来讲却很困难。
图1是一个典型的CAPTCHA.
图1一个典型的CAPTCHA.
现在，大多数主要的服务提供商(Yahoo, Hotmail, Google)已经在他们的免费服务中使用CAPTCHA，用来作为区分垃圾邮件和虚假注册的手段。在本文中，我们要描述以下在我们的Web应用中加入基于CAPTCHA授权的方法。
首先，我们快速浏览以下J2EE中Web应用的安全模型。
J2EE安全模型
在java开发中，安全性始终是一个最受关注的领域。毫无疑问，J2EE在构建安全的应用时，采用了同样的原理和健壮的框架。在J2EE中，安全性是一个很大的题目，在这里是不可能叙述细节的。在这方面有好多好的资源。我极力推荐团队和个人花些时间来熟悉这些概念。在这力，我只能极概括的叙述一些最要害的概念。
要害概念
在J2EE应用中，安全性必须采用声明或编程的话方法。就象名字中暗示的，当采用声明方法时，开发者在应用软件代码的外部定义用于应用的安全性约束。这些声明用部署描述符的形式来建造(web.xml， ejb-jar.xml)，并由容器的运行环境来保证它的强制执行。声明的方式容许开发者：
·能够实现基于身份的对资源存取的约束（例如：/admin/* 只能容许有治理员身份的人来操作）
·能够实现对某些URL的存取只能用某种协议的约束（例如：“/customer/*”只能通过HTTPS来访问）
·能够实现基于身份的对某些服务存取的约束（例如：可以限定SiteShutdownServlet只能由具有“god”身份的人来操作）
·能够实现当用户要存取某些受限资源但用户还没有登录到系统的时候，自动重定向到登录页面的功能.而编程的方法能提供查询和调用安全设施的机制，而开发者必须实现这些机制。这个方法的特点是：
·检索出与当前用户相关联的部分：HttpServletRequest.getUserPRincipal or EJBContext.getCallerPrincipal
·查询用户是否具有某种特定的身份：HttpServletRequest.isUserInRole(String role) or EJBContext.isCallerInRole(String role)
这两种方法都有它的局限性，并且是能互相补充的。
Web应用的声明安全的方法
Web应用的声明安全的方法本质上是一种被动的方法。这意味者只有在刚开始访问受保护资源的用户，假如他们没有被受权，才会被重定向到登录页面。假如这个用户已经被授权并有适当的权限，他们就能访问这些资源。
这类方法中有一个最常用的方法是基于规则的受权。应用部署描述符web.xml分两个部分描述了在这个方法中需要的所有元素。
第一部分是适用于整个应用的。它要鉴别出：
·在登录中需要使用的方法。J2EE支持BASIC，DIGEST，FORM，或CERT等几种授权机制。
·用于基于规则受权的登录和错误的页面
·能在应用中使用的所有身份的超集
图2表明了第一部分的要害元素和它们之间的关系
图2 第一部分的要害元素和它们之间的关系
第二部分说明了资源方面的约束。部署描述符可以包含零个或多个类似于下面的声明：
·需要保护的站点。这可以在web-resource-collection内使用url-pattern来配置。
·能够存取资源的身份的集合(auth-constraint)。它通常是第一部分定义的身份集合的一个子集。
·与某个资源相关的传输的保证(user-data-constraint)。
图3表明了第二部分的要害元素和它们之间的关系
图3 第二部分的要害元素和它们之间的关系
现在，我们看一个简单的例子web.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app>
<!-- constrain a section of the site -->
<security-constraint>
<display-name>Anonymous Security Constraint</display-name>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/security/protected/*</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<role-name>anonymous</role-name>
</auth-constraint>
</security-constraint>
<!-- Default login configuration uses form-based authentication -->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Anonymous Form-Based Authentication Area</realm-name>
<form-login-config>
<form-login-page>/security/protected/login.jsp</form-login-page>
<form-error-page>/security/protected/error.jsp</form-error-page>
</form-login-config>
</login-config>
<!-- Security roles referenced by this web application -->
<security-role>
<role-name>anonymous</role-name>
</security-role>
<!-- The Usual Welcome File List -->
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
</web-app>
新闻热点
疑难解答
