Die Dokumentation für Stripes Unit tests beschreibt sehr ausführlich, wie man mit Hilfe des MockServletContext eine Testinfrastruktur aufbaut, die es ermöglicht die ActionBeans ausserhalb des JEE-Containers zu testen. Dies funktioniert für klassische ActionBeans ganz wunderbar. Doch beim schreiben von Tests für ActionBeans im Wizard Mode fiel auf, dass die Simulation eines Submits nicht funktionierte. Im Wizard Modus erzeugt das Stripes FormTag ein zusätzliches verstecktes Formularfeld mit dem Namen “__fp”, welches alle Feldnamen des aktuellen Formulars in verschlüsselter Form enthält. Ohne dieses Feld verweigert der Stripes Dispatcher die Arbeit! Nimmt man nun einen beliebigen Wert und legt ihn in diesem Feld ab, so erzeugt das ebenfalls einen Fehler:(Der Rechtschreibfehler ist tatsächlich aus dem Framework.)

Stripes attmpted and failed to decrypt the non-null value in the 'fields present' field.

Auch ist es nicht sinnvoll, einen beliebigen Text mit Hilfe des CryptoUtil zu verschlüsseln. Der Submit kann dann zwar erfolgreich simuliert werden, jedoch werden sämtliche Validierungsregel ignoriert. Mit folgenden Zeilen Code, kann ein korrekter Wert für das “__fp” Feld erzeugt werden:

// Alle Feldnamen des aktuellen Formulars in eine Liste aufnehmen
   List fields = new ArrayList();
   fields.add("username");
   fields.add("password");
// Alle Feldnamen mit Trennzeichen zusammenfassen
   String hiddenFieldValue = HtmlUtil.combineValues(fields);
// servlet engine configurieren
   MockServletContext ctx = TestFixture.getServletContext();
   MockRoundtrip trip = new MockRoundtrip(this.ctx, YourCustomActionBean.class);
   HttpServletRequest request = (HttpServletRequest) trip.getRequest();
   hiddenFieldValue = CryptoUtil.encrypt(hiddenFieldValue, request);
   trip.setParameter(StripesConstants.URL_KEY_FIELDS_PRESENT, hiddenFieldValue);

Für das Testen der Feldvalidierung ist es wichtig, dass die Feldnamen mit dem Wert des <input name="" /> Name Attributes in dem jeweiligen Formular übereinstimmen. Denn es werden tatsächlich nur die Felder validiert, die aus dem decodiertem Inhalt des “__fp” Feldes ausgelesen werden können.

Angenommen der oben abgebildete Code wird in der setup() Methode eines Unit Tests ausgeführt und speichert das MockRoundtrip Object in einem privaten Member, könnte ein Beispieltest könnte dann so aussehen:

@Test
public void testLogin() throws Exception {
	trip.setParameter("username", "christophbuente");
	trip.setParameter("password", "secret");
	trip.execute("login");
	YourCustomActionBean bean = trip.getActionBean(YourCustomActionBean.class);
	Assert.assertTrue("Destination", "/account", trip.getDestination());
}

Ich hoffe, dass diese Informationen ausreichen, um sinnvolle Unit Tests für ActionBeans im Wizard Modus zu schreiben. Bei Fragen helfe ich gerne weiter. Und wie immer sind Kommentare sehr willkommen.

Canoo Webtest bietet dem Benutzer die Möglichkeit, eine Web-Anwendung automatisch zu testen. Basierend auf der Ant Technologie können Tests in einem menschenlesbaren XML-Dialekt deklariert werden. Ein simples Beispiel könnte so aussehen:

<steps>
  <invoke
    description="Loginseite aufrufen"
    url="/login" />
  <verifyTitle
    description="Seitentitel sollte folgender sein: "
    text="Anmeldung" />
  <setInputField
    description="Setze Benutzernamen"
    name="username"
    value="max.mustermann" />
  <setInputField
    description="Setze Passwort"
    name="password"
    value="mypassword" />
  <clickButton
    description="Klick den login Knopf"
    name="login" />
  <verifyTitle
    description="Seitentitel sollte folgender sein:"
    text="Willkommen"  />
</steps>

Doch als erstes muss Canoo Webtest heruntergeladen und installiert werden. Keine Angst, das geht schnell und unkompliziert. Für den produktiven Einsatz empfehle ich die neueste, stabile Version. Von den Snapshots muss ich leider abraten, da beim erzeugen eines Projektes wichtige Dateien fehlten. Nach dem herunterladen der build.zip Datei kann das Archiv in ein beliebiges Verzeichnis entpackt werden. In diesem Verzeichnis muss sich danach ein bin Verzeichnis befinden, welches die Ausführungsskripte für Windows und Unix beinhaltet.

Dieses Verzeichnis muss dem Ausführungspfad bekannt gemacht werden, sodass Canoo Webtest einwandfrei verwendet werden kann.

• Unter Windows geht das wie folgt:
  • In den Systemeinstellungen (Windows-Taste + Pause) wählt man den Reiter “Erweitert”.
  • Dort drückt man den Knopf “Umgebungsvariablen” und fügt eine neue Variable WEBTEST_HOME mit der entsprechenden Pfadangabe hinzu: “C:\Programme\Webtest” hinzu.
  • Anschließend bearbeitet man die Variable “Path” und fügt am Ende folgendes an: “;%WEBTEST_HOME%\bin”.
• Unter Linux/Unix:
  • setenv WEBTEST_HOME /usr/local/webtest
setenv PATH $PATH:$WEBTEST_HOME/bin in der ~/.login (tcsh)
  • export WEBTEST_HOME=/usr/local/webtest
export PATH=$PATH:$WEBTEST_HOME/bin in der ~/.bashrc oder ~/.bash_login (bash)

Canoo Webtest generiert auf Wunsch ein Beispielprojekt, mit dem man sofort loslegen kann. Auf der Kommandozeile führt man folgenden Befehl aus:

webtest.sh -f pfad/zur/webtest/installation/webtest.xml wt.createProject

Während der Ausführung wird man nach einem Projektnamen gefragt. Ein gleichnamiges Verzeichnis wird nach der Eingabe im aktuellen Verzeichnis angelegt. Das neu angelegte Projekt enthält ein paar Beispieltests und Vorlagen. Um die Tests auszuprobieren ruft man lediglich webtest.sh im Verzeichnis des neu erstellten Projektes auf. Nach Abschluß aller Tests wird im Verzeichnis results ein HTML Report erzeugt, der automatisch angezeigt wird.

Um eigene Tests zu verwenden, löscht man im Verzeichnis tests am besten alle Dateien bis auf allTests.xml und eine weitere beliebige Datei. In der Datei allTests.xml werden alle vorhandenen Testdateien aufgerufen. Sie stellt das Verzeichnis aller auszuführenden Tests dar.

<?xml version="1.0"?>
<project name="allTests" default="test">
  <target name="test" description="führt alle tests aus">
    <ant antfile="loginTest.xml"/>
  </target>
</project>

Der anderen Datei gibt man einen sprechenden Namen, in diesem Fall loginTest.xml. In dieser Datei wird ein Testfall deklariert, welcher so aussehen könnte:

<?xml version="1.0"?>
<!DOCTYPE project SYSTEM "../dtd/Project.dtd">
<project name="loginTest" default="test">
  <target name="test">
    <webtest name="loginTest">
      &config;
      <steps>
        <invoke
          description="Loginseite aufrufen"
          url="/login" />
        <verifyTitle
          description="Seitentitel sollte folgender sein: "
          text="Anmeldung" />
        <setInputField
          description="Setze Benutzernamen"
          name="username"
          value="max.mustermann" />
        <setInputField
          description="Setze Passwort"
          name="password"
          value="mypassword" />
        <clickButton
          description="Klick den login Knopf"
          name="login" />
        <verifyTitle
          description="Seitentitel sollte folgender sein:"
          text="Willkommen"  />
      </steps>
    </webtest>
  </target>
</project>

Sicher ist aufgefallen, dass in dieser Datei kein Server deklariert ist, der getestet werden soll. Jedoch steht als erstes Element im <webtest> Element folgender Text: &config;
Dieser verweist auf die Datei includes/config.xml, welche alle Einstellungen enthält. Hier können nun der Name, Port und Protokoll des zu testenden Server eingetragen werden:

<!--
Wie alle Dateien dieses Ordners, ist dieser Inhalt als DTD Entität verfügbar (in diesem Fall &config;)
-->;
<config
  host="www.meinserver.de"
  port="8080"
  protocol="http"
  basepath=""
  summary="true"
  saveresponse="true"
  resultfile="${wt.resultfile}"
  resultpath="${wt.resultpath}"
  haltonfailure="false"
  haltonerror="false" />

Um eine möglichst vollständige Testabdeckung zu erreichen, fügt man in separaten Dateien für alle erdenklichen Anwendungsfälle Tests hinzu und trägt Sie in die Datei allTests.xml ein. Eine Dokumentation der zur Verfügung stehenden Schritte (Steps) findet man in der Anleitung für die Canoo Webtest Core Steps. Über mehr oder weniger generische Anwendungsfälle und deren sinnvolle Abtestung kann gerne in den Kommentaren berichtet werden.

Der grundlegende Mechanismus für Subscriptions ist denkbar einfach. An einer beliebigen Stelle in unserer Webapplikation wird der Benutzer per link oder submit button an die Paypal Seite geleitet. Alle relevanten Daten für die Zahlung werden entweder als GET Parameter (Link) oder POST Parameter (Button) übertragen. Dazu zählen vor allem folgende Angaben:

• Abonnementinterval (1 Tag, 4 Wochen oder 12 Monate)
• Betrag pro Abonnementinterval
• Währung
• Paypal Id des Verkäufers
• Rechnungsnummer
• Automatische Verlängerung (ja/nein)
• Beliebige zusätzliche Informationen

Sollte der Benutzer noch kein Paypal Kunde sein, muss er sich bei Paypal erst registrieren. Um dies so einfach wie möglich zu gestalten können wir zusätzlich Benutzerinformationen mitsenden, die Paypal in das Registrierungsformular einfügt.

• Name, Nachname
• Adress(Strasse, PLZ, Stadt, Land)
• Email Adresse

Damit wir zum Testen unserer Applikation kein Vermögen hinblättern müssen, stellt Paypal eine sogenannte Sandbox zur Verfügung. Eine eigene Developer Sandbox kann man sich hier einrichten. Diese Sandbox stellt die kompletten Funktionen von Paypal zur Verfügung. Mit zwei Unterschieden: Es fließt kein echtes Geld und es gibt nur die Benutzer, die wir selbst angelegt haben. Um also einen Zahlungsfluss zu simulieren müssen in der Sandbox mindestens zwei Benutzer angelegt sein (Verkäufer und Käufer). Zum Erzeugen eines einfachen Bezahlknopfes eignet sich die Paypal Button Factory, welche unter Merchant Services im Paypal Menü des Verkäufers erreichbar ist. Doch es gibt auch Gründe gegen einen statischen Bezahlknopf auf der Webseite. Angenommen wir wollen mehrere Abonnements verkaufen, die sich je nach Laufzeit im Preis unterscheiden. Wäre es da nicht besser ein eigenes Formular zu erstellen, welches dem Benutzer die komplette Auswahl unserer Produkte anzeigt? Nachdem sich der Benutzer für eines unserer Abonnements entschieden hat, überträgt er seine Auswahl per druck auf den Bezahlknopf. Unsere Webapplikation wertet diese Informationen aus und leitet den Benutzer per redirect auf die Paypal Seite um. Dazu muss die URL mit sämtlichen Zahlungsinformationen dynamisch erzeugt werden. Hier eine Beispielimplementierung:

public String getPurchaseUrl() throws EncoderException {
	StringBuffer urlBuffer = new StringBuffer("https://www.sandbox.paypal.com/cgi-bin/webscr");
	urlBuffer.append("?no_note=1"); // Abonnements unterstützen keine Notizen
	urlBuffer.append("&a3=9.99"); // Der Preis des Abonnements
	urlBuffer.append("&t3=M"); // Intervall Einheit = Monate
	urlBuffer.append("&p3=1"); // Intervall Länge = 1 (Monat)
	urlBuffer.append("&business=verkaeufer@deine.url.de"); // Die email adresse für den verkäufer account bei paypal
	urlBuffer.append("&cmd=_xclick-subscriptions"); // Wir wollen eine abonnement
	urlBuffer.append("&src=1"); // Abonnement verlängert sich automatisch
	urlBuffer.append("&currency_code=EUR"); // Wir nehmen Zahlungen in Euro entgegen
	urlBuffer.append("&invoice=Rechnungsnummer"); // Hier kann eine Rechnungsnummer vergeben werden
	urlBuffer.append("&lc=DE"); // Die Zielseite soll in deutscher Sprache angezeigt werden
	urlBuffer.append("&no_shipping=1"); // Wir brauchen keine Versandadresse, denn wir verkaufen virtuelle Güter oder Dienstleistungen
	URLCodec encoder = new URLCodec();
	return encoder.encode(urlBuffer.toString());
}

Für das URL Encoding, welches alle Sonderzeichen in übertragbare Zeichen umwandelt, verwende ich die commons-codec Bibliothek von Apache Commons.

Die geladene Paypal Seite enthält nun alle Zahlungsinformationen. Der Potentielle Käufer muss sich lediglich mit seinem Paypal Benutzernamen anmelden und die Zahlung bestätigen. Ist die Automatische Rückleitung aktiviert, landet der Benutzer danach wieder auf unserer Seite. Die Aktivierung kann im Paypal Menu des Verkäufers unter “Profile ->Website Payment Preferences” eingestellt werden. Dazu wählt man den Radiobutton “Auto Return ON” und trägt unter “Return URL” die entsprechende Url ein, an die der Benutzer weitergeleitet werden soll. Mit dieser URL überträgt Paypal eine Transaktions Id, wenn in den Einstellungen zusätzlich noch “Payment Data Transfer” auf “On” gesetzt wurde. Die Dokumentation für PDT finden man auf der Paypal Developer Seite. Paypal erwartet darauf hin, dass unsere Webapplikation folgende Informationen zurück sendet:

• TransaktionsId
• Identitätstoken
• Kommando

Die TransaktionsId ist die eben empfangene Id. Der Identitätstoken kann an der Stelle eingesehen werden, wo “Payment Data Transfer” angeschaltet wurde. Dies stellt sicher, dass Zahlungsinformationen nicht an unberechtigte Personen gesendet werden. Das Kommando muss den den Wert “_notify-synch” enthalten. Hier ein Beispiel, wie die Implementierung aussehen könnte. Für den Post Request zurück an Paypal habe ich die commons-httpclient Bibliothek von Apache Commons verwendet.

/**
 * Verabeitet Paypals Payment Data Transfer
 *
 * @param txId The transactionId
 * @return
 */
public void handleCallback(long txId) {
	Map<String,Object> params = new HashMap<String, Object>();
	params.put("cmd","_notify_synch");
	params.put("tx", txId);
	params.put("at", "IDENTITY_TOKEN");
	try {
		PostMethod method = doPostRequest("https://www.sandbox.paypal.com/cgi-bin/webscr", params);
		String responseBody = method.getResponseBodyAsString();
		if(responseBody != null) {
			if(responseBody.startsWith("SUCCESS")) {
				// Super, alles hat geklappt
				// Erfolgsnachricht anzeigen
			} else if(responseBody.startsWith("FAIL")) {
				// Die Zahlung war nicht korrekt durchgeführt
				// Fehlernachricht anzeigen
			} else {
				// Irgendwas ging richtig in die Hose
				// Fehlerbehandlung
			}
		} else {
 			// Das war auch nicht korrekt
	 		// Fehlerbehandlung
 		}
	} catch (HttpException e) {
		// Error sending PDT response
	} catch (IOException e) {
		// Error sending PDT response
	}
}
/**
 * Does a POST request to the given url and the given parameter map
 *
 * @param url
 * @param params
 * @return The method containing the response
 * @throws HttpException
 * @throws IOException
 */
public PostMethod doPostRequest(String url, Map<String, Object > params)
 	throws HttpException, IOException {
		HttpClient client = new HttpClient();
		HttpConnectionManager conManager = client.getHttpConnectionManager();
		HttpClientParams clientParams = client.getParams();
		clientParams.setConnectionManagerTimeout(2000);
		HttpConnectionManagerParams managerParams = conManager.getParams();
		managerParams.setConnectionTimeout(5000);
		managerParams.setSoTimeout(5000);
		PostMethod method = new PostMethod();
		method.setURI(new URI(url, false));
		HttpMethodParams paramsM = method.getParams(); // Wiederholungen unterdrücken
		paramsM.setParameter(HttpMethodParams.RETRY_HANDLER,
	 		new DefaultHttpMethodRetryHandler(0, false));
	Set<String> keys = params.keySet();
	for (String key : keys) {
		String value = (String) params.get(key);
		method.addParameter(key, value); // Setze Url Parameter
	}
	client.executeMethod(method); // Http Post ausführen
	return method;
}

Der Benutzer merkt vom Austausch der Zahlungsinformationen nichts, Es wird lediglich eine einfache Bestätigungsseite angezeigt. Auf dieser Seite wird dem Benutzer mitgeteilt wird, dass die Zahlung erfolgreich oder nicht erfolgreich war, und dass er von Paypal per Mail darüber benachrichtigt werden wird.

Paypal bietet zusätzlich die Möglichkeit, unsere Webapplikation asynchron über eingehende Zahlungen und/oder Kündigungen zu informieren. Die Mechanismus nennt sich IPN, was soviel bedeutet wie “sofortige Zahlungsavisierung”. Dieser Mechanismus ist deutlich robuster, als “Payment Data Transfer”. Doch dazu in später mehr.

[ad#vert-banner]

Als Mittel der Wahl hat sich seit Jahren das sogenannte CAPTCHA etabliert. Dabei werden Bilder erzeugt, die auf unebendem Hintergrund verzerrte Zeichen darstellen. Der Benutzer muss diese sogenannte Challenge lösen, in dem er die Zeichenfolge in ein Formularfeld eingibt. Stimmen die eingegebenen Zeichen und die Zeichen auf dem Bild übereinstimmen. Hier macht man sich zu nutze, dass der Mensch besser abstrahieren kann, und die Buchstaben trotz widriger Umstände erkennen kann, wo eine Maschine scheitert.

Da ich das Rad nicht neu erfinden will, habe ich mich einer Bibliothek bedient, die diese Funktionalität zur Verfügung stellt, und sehr einfach in das aktuelle Projekt einzubinden ist. Meine Wahl fiel auf JCaptcha. Wie der Name vermuten läßt ist JCaptcha eine Java basierte Implementierung. Sie läßt sich in Java basierte Webprojekte sehr einfach integrieren.

Folgende Schritte sind notwendig:

1. Implementierung eines eigenen Servlets, welches mit der Auslieferung der generierten Bilder beauftragt wird.
2. Eintrag des Servlets und des Mappings in die web.xml
3. Implementierung eines Singleton, welches den CaptchaService zur Verfügung stellt.
4. Erstellen einer validierungsmethode zum Überprüfen der Benutzereingabe.

Der generelle Ablauf ist recht einfach. Das in der JSP mit Hilfe des <img src=”img.captcha”> referenzierte Bild wird von unserem Servlet bedient. Dieses erzeugt mit Hilfe des CaptchaService ein neues Bild und gibt es als jpg zurück. Der CaptchaService speichert in einer internen Map unter dem Schlüssel der jeweiligen session id das captcha response. Die Methode validateResponseForID des CaptchaService prüft, ob der eingegebene Text mit dem Bild übereinstimmt.

Das Servlet wird wie folgt implementiert:

import java.awt.image.BufferedImage;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.util.Locale;import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import com.octo.captcha.service.CaptchaServiceException;
import com.sun.image.codec.jpeg.JPEGCodec;
import com.sun.image.codec.jpeg.JPEGImageEncoder;
/**
 * @author Christoph Bünte
 *
 * @version $Revision: 1.5 $
 *
 * @created 11.10.2007
 *
 */
public class CaptchaServlet extends HttpServlet {

/**
  * The serial id for this class
  */
 private static final long serialVersionUID = -5555311841435084305L;

@Override
 public void init(ServletConfig servletConfig) throws ServletException {

super.init(servletConfig);
}

/**
  * Generiert das Captcha image in form eines bytearrays
  *
  * @param token
  *            SessionId
  * @param loc
  *            Locale Object für die Sprache des Benutzers
  * @return
  */
 private synchronized byte[] getCaptchaChallenge(String token, Locale loc) {

byte[] captchaChallenge = null;

try {
 		// create the captcha challenge
 		BufferedImage challenge = CaptchaServiceSingleton.getInstance()
 				.getImageChallengeForID(token, loc);

		// transform image data into jpeg byte array
 		ByteArrayOutputStream jpegOutputStream = new ByteArrayOutputStream();

		JPEGImageEncoder jpegEncoder = JPEGCodec
 				.createJPEGEncoder(jpegOutputStream);

		jpegEncoder.encode(challenge);

		captchaChallenge = jpegOutputStream.toByteArray();

 	} catch (IOException e) {
 		//TODO: Fehlerbehandlung
 	} catch (CaptchaServiceException e) {
 		//TODO: Fehlerbehandlung
 	}

	return captchaChallenge;

 }

@Override
 protected void doGet(HttpServletRequest request,

 		HttpServletResponse response) throws ServletException, IOException {

			// Hier benutzen wir die session id und das Locale Objekt des requests
			String token = request.getSession().getId();
 			Locale loc = request.getLocale();

			// hole das CAPTCHA challenge als JPEG
			byte[] captchaAsJpeg = getCaptchaChallenge(token, loc);

			// falls nicht verfügbar, sende http code 404 (resource not available)
			if (captchaAsJpeg == null) {
				response.sendError(HttpServletResponse.SC_NOT_FOUND);
			return;
			}

			// gibt ein response Objekt mit dem jpeg bild zurück
			// (für den browser: benutze keinen cache und verwirf den inhalt sofort)
			// set header

			response.setHeader("Cache-Control", "no-store");
			response.setHeader("Pragma", "no-cache");
			response.setDateHeader("Expires", 0);
			response.setContentType("image/jpeg");

			// sende bilddaten
			ServletOutputStream responseOutputStream = response.getOutputStream();
			responseOutputStream.write(captchaAsJpeg);
			responseOutputStream.flush();
			responseOutputStream.close();
 		}

}

Der Eintrag in die web.xml sieht so aus:

<servlet>
	<servlet-name>jcaptcha</servlet-name>
	<display-name>JCaptcha</display-name>
	<servlet-class>your.package.path.CaptchaServlet</servlet-class>
	<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
	<servlet-name>jcaptcha</servlet-name>
	<url-pattern>*.captcha</url-pattern>
</servlet-mapping>

Das CaptchaService als Singleton implementiert:

import com.octo.captcha.engine.image.ListImageCaptchaEngine;
import com.octo.captcha.service.captchastore.CaptchaStore;
import com.octo.captcha.service.captchastore.FastHashMapCaptchaStore;
import com.octo.captcha.service.image.DefaultManageableImageCaptchaService;
import com.octo.captcha.service.image.ImageCaptchaService;

/**
 *
 * @author Christoph Bünte
 *
 * @version $Revision: 1.6 $
 *
 * @created 11.10.2007
 *
 */
public class CaptchaServiceSingleton {

	private static ImageCaptchaService instance = new DefaultManageableImageCaptchaService();

	/**
	  * Gibt die einzige Instanz einnes CaptchaService zurück.
	  *
	  * @return
	  */
	 public static ImageCaptchaService getInstance() {

		return instance;
	 }
}

Im Formular für die Eingabe der Captcha Response, wird das Bild wie folgt eingebunden:

<img src="img.captcha"  class="captcha">

Je nachdem, welches Webframework man verwendet, differiert die Implementierung einer Validierungsmethode. Letztlich könnte sie wie folgt aussehen. Es ist ein Beispiel, wie es im stripes framework verwendet wird.

/**
 * Validating capture input
 *
 * @param errors
 */
@ValidationMethod(on = { "sendRecommendation" }, when = ValidationState.ALWAYS)

public void validateCaptcha(ValidationErrors errors) {
 try {
 	String sessionId = context.getRequest().getSession().getId();
 	if (!CaptchaServiceSingleton.getInstance().validateResponseForID(
 			sessionId, captchaResponse)) {
 		errors.add("captchaResponse", new LocalizableError(
 				"captchaResponse.invalidValue"));
 	}
 } catch (CaptchaServiceException e) {
 	// ungültige Session id, Fehlerbehandlung
 }
}

Das Ergebnis ist schon ganz ansehnlich. Im Formular wird mit der Default Engine ein mehr oder weniger schönes Captcha Bild erzeugt. Jedoch fällt Ästheten sofort auf, dass das Bild überhaupt nicht in das Design der Seite passt. Um solche Anforderungen zu erfüllen, implementiert man am besten eine CaptchaEngine. Dazu müssen wir die Singleton Klasse noch etwas modifizieren, doch das schnell erledigt. Wird sind doch agil, oder?

Die unten gezeigte Engine erzeugt ein Captcha Bild mit hellblauem Hintergrund und grauer und schwarzer Schrift. Für die Schrift werden nur Großbuchstaben verwendet. Man hätte als Alternative auch die Informationen zum Rendern des Bildes auch direkt in der Singleton Klasse zu einer vorhandenen Engine hinzufügen können. Unangenehmer Nebeneffekt ist aber, dass es immer eine Default engine gibt. Beim Rendern der Bilder wird dann eine verfügbare Engine zufällig ausgewählt, so dass in unregelmässigen Abständen eine Bild mit grün-rot-gelb gesprenkeltem Hintergrund erscheint. Dieses, für mich anfänglich, merkwürde Verhalten hat mich zwei Stunden aufgehalten. Wer unterschiedliche Captcha Bilder erzeugen möchte implenentiert entsprechend mehr Klassen. Hier ein Beispiel:

import java.awt.Color;import com.octo.captcha.component.image.backgroundgenerator.BackgroundGenerator;
import com.octo.captcha.component.image.backgroundgenerator.UniColorBackgroundGenerator;
import com.octo.captcha.component.image.fontgenerator.DeformedRandomFontGenerator;
import com.octo.captcha.component.image.fontgenerator.FontGenerator;
import com.octo.captcha.component.image.textpaster.RandomTextPaster;
import com.octo.captcha.component.image.textpaster.TextPaster;
import com.octo.captcha.component.image.wordtoimage.ComposedWordToImage;
import com.octo.captcha.component.image.wordtoimage.WordToImage;
import com.octo.captcha.component.word.wordgenerator.RandomWordGenerator;
import com.octo.captcha.component.word.wordgenerator.WordGenerator;
import com.octo.captcha.engine.CaptchaEngine;
import com.octo.captcha.engine.image.ListImageCaptchaEngine;
import com.octo.captcha.image.ImageCaptchaFactory;
import com.octo.captcha.image.gimpy.GimpyFactory;

/**
 * Das ist unsere spezielle {@link CaptchaEngine} Implementierung.
 * @author Christoph Bünte
 *
 * @version $Revision: 1.2 $
 *
 * @created 12.10.2007
 *
 */
final public class CustomCaptchaEngine extends ListImageCaptchaEngine {

@Override
 protected void buildInitialFactories() {

// RGB: #4C4E42
 	Color textColor = new Color(0x4c, 0x4e, 0x42);
 	Color textColor2 = Color.BLACK;
 	Color[] colors = new Color[2];
 	colors[0]=textColor;
 	colors[1]=textColor2;

// RGB: #F4F8FB
 	Color backgroundColor = new Color(0xf4, 0xf8, 0xfb);

// Einheitlicher Hintergrund mit der gegeben Breite, Höhe und Farbe
 	BackgroundGenerator bgGenerator = new UniColorBackgroundGenerator(250,
 			70, backgroundColor);

// Der Text hat die Min-und Maxlänge mit den gegeben Farben
 	TextPaster paster = new RandomTextPaster(6, 6, colors);

// Schriftgrößen 10 bis 30
 	FontGenerator fontGenerator = new DeformedRandomFontGenerator(
 			10, 30);

// Benutze einen einfachen Mechanismus zum Mischen von Hintergrund und Text
 	WordToImage wordToImage = new ComposedWordToImage(fontGenerator,
 			bgGenerator, paster);

// Benutze zufällige Worte aus den gegebenen Buchstaben
 	WordGenerator wordGenerator = new RandomWordGenerator(
 			"ABCDEFGHIJKLMNOPQRSTUVWXYZ");

ImageCaptchaFactory factory = new GimpyFactory(wordGenerator,
 			wordToImage);

 	this.addFactory(factory);
 }
}

Und hier die neue Singleton Implementierung:

import com.octo.captcha.engine.image.ListImageCaptchaEngine;
import com.octo.captcha.service.captchastore.CaptchaStore;
import com.octo.captcha.service.captchastore.FastHashMapCaptchaStore;
import com.octo.captcha.service.image.DefaultManageableImageCaptchaService;
import com.octo.captcha.service.image.ImageCaptchaService;

/**
 *
 * @author Christoph Bünte
 *
 * @version $Revision: 1.6 $
 *
 * @created 11.10.2007
 *
 */

public class CaptchaServiceSingleton {

	private static ImageCaptchaService instance = initializeService();

	/**
	  * Gibt die einzige Instanz einnes CaptchaService zurück.
	  *
	  * @return
	  */
	 public static ImageCaptchaService getInstance() {
	 	return instance;
	 }

	/**
	  * Initialisiert den {@link ImageCaptchaService}
	  *
	  * @return
	  */
	 private static ImageCaptchaService initializeService() {

	// Wir brauchen eine Instanz unser eigenen Engine
	 	ListImageCaptchaEngine engine = new CustomCaptchaEngine();

		CaptchaStore captchaStore = new FastHashMapCaptchaStore();
 		captchaStore.empty();

		ImageCaptchaService service = new DefaultManageableImageCaptchaService(
 			captchaStore, engine, 180, 100000, 75000);

		return service;

 	}

}

Kommentare und Anregungen sind wie immer willkommen. Beispiele für die kreativsten Bilder nehme ich auch gerne entgegen. Viel Spass beim ausprobieren.