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>