Ich habe das Vergnügen für meinen aktuellen Kunden DaWanda ein Gadget für StudiVZ zu entwickeln. Ein Gadget besteht aus einer XML Datei, die definiert, um welche Anwendung es sich handelt, wer der Author ist usw. Dazu gehören wahlweise mehrere CSS und Javascript Dateien. Nachdem man alles in eine Zip Datei, die den gleichen namen wie die XML Datei trägt, gepackt hat, kann man die Anwendung in die Sandbox hochladen und ausprobieren. Eine Beispiel Datei könnte so aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs
    title="Example StudiVZ Gadget"
    title_url="http://www.christophbuente.de"
    author="Christoph Bünte"
    author_email="info@christophbuente.de"
    description="Example description"
    screenshot="http://www.christophbuente.de/images/screenshot.jpg"
    thumbnail="http://www.christophbuente.de/images/thumbnail.jpg">
    <Require feature="opensocial-0.8" />
    <Require feature="views" />
  </ModulePrefs>
  <Content type="html" >
    <![CDATA[
      <script>
        function init() {
          // Put initialization code here
        }
        gadgets.util.registerOnLoadHandler(init);
      </script>
    <div id='container'></div>
    ]]>
  </Content>
</Module>

Jede Interaktion des Benutzers mit der Anwendung wird mit Hilfe weiterer Javascript Funktionen behandelt. Dazu stehen eine Reihe eingebauter Funktionen aus dem Opensocial Container bereit. Darüber hinaus haben die Entwickler von StudiVZ eine API Beschreibung der zusätzlichen Funktionen bereit gestellt. Was aber, wenn man nun nicht mit Javascript entwickeln möchte bzw. kann? Es besteht die Möglichkeit Flash Content einzubinden. Man kann aber auch ein beliebiges Backend einbinden. Dieses Backend muss nur 2 Bedingungen erfüllen:

• Es muss auf HTTP Requests reagieren können und beliebiges HTML,CSS und JavaScript zurück liefern
• Es muss im Namen des Applikationsbenutzers einen OAuth signierten Request an die StudiVZ REST API schicken können.

Wie im Schema zu sehen, sendet der User einen Request, um die Applikation zu benutzen. Der Container liest darauf hin den Inhalt der XML Datei aus. Dort ist neben einem DIV Container lediglich ein externes Javascript referenziert. In dem Javascript sind einfache Methoden zum Navigieren und Interagieren definiert. Das rendern des HTML übernimmt ein Ruby Backend. Das braucht zum Render unter Umständen noch zusätzliche Informationen wie zum Beispiel Name und Foto des Benuter usw. Diese Informationen holt es sich mit einem OAuth signierten Request von der abgebildeten REST API. Das vom Ruby Backend erzeugte HTML rendert der Opensocial Container in einem IFrame im Browser des Benutzers. Für eine bessere Übersicht definieren wir im XML einzelne Views, die jeweils einen eigenen Endpunkt im Backend haben. Eine einfache gadget.xml mit 2 definierten Views für Profil und Vollansicht mit Backend Anbindung:

<?xml version="1.0" encoding="UTF-8"?>
<Module>
  <ModulePrefs
    title="Spitzenmässiges StudiVZ Gadget mit Backendanbindung"
    title_url="http://www.christophbuente.de"
    author="Christoph Bünte"
    author_email="info@christophbuente.de">
    <Require feature="opensocial-0.8" />
    <Require feature="views" />
  </ModulePrefs>
  <Content type="html" view="profile" >
    <![CDATA[
      <script type="text/javascript" src="http://www.yourbackend.com/profile.js" ></script>
      <div id='profile'></div>
    ]]>
  </Content>
  <Content type="html" view="canvas" >
    <![CDATA[
      <script type="text/javascript" src="http://www.yourbackend.com/canvas.js" ></script>
      <div id='canvas'></div>
    ]]>
  </Content>
</Module>

Das referenzierte Javascript ist ebenfalls sehr schlank. Darin wird lediglich eine Backend URL aufgerufen und deren Response Body in das profile bzw. canvas div geschrieben.

function init{
  var url = 'http://www.yourbackend.com/profile/'
  var params = {};
  params[gadgets.io.RequestParameters.AUTHORIZATION]=gadgets.io.AuthorizationType.SIGNED;
  gadgets.io.makeRequest(url, requestCallback, params);

}

function requestCallback(obj) {
	document.getElementById('profile').innerHTML = obj.data;
}

Damit die REST API benutzt werden kann, muss man sich an ihr Authentifizieren. Da das Backend aber dumm ist, hat es keine Userdaten, um sich dort anzumelden. Glücklicherweise ist der Request aus dem Javascript mit dem verschlüsselten Authentifierungsdaten des angemeldeten Anwendungsbenutzers signiert. Mit deren Hilfe können wir einen neuen, signierten Request erzeugen, den die API akzeptieren wird. Doch zuerst muss die Glültigkeit der Signatur überprüft werden:

sudo gem install oauth --source http://gemcutter.org

require 'oauth'
require 'oauth/consumer'
require 'oauth/request_proxy/action_controller_request'
require 'oauth/signature/rsa/sha1'
require 'oauth/signature/hmac/sha1'

class ApplicationController < ActionController::Base

  before_filter  auth_required

  def oauth_required
    cert_file = File.join(RAILS_ROOT, 'public', 'public.cer')
    cert_str = File.read(cert_file)
    consumer = OAuth::Consumer.new(ConsumerToken, cert_str)

    begin
      pass = OAuth::Signature.build(request, :consumer => consumer).verify
      logger.info "Signature verification returned: #{pass}"
    rescue OAuth::Signature::UnknownSignatureMethod => e
      logger.error "ERROR "+ e.message
    end

    render :text => "OAuth access denied", :status => :unauthorized  unless pass
  end

Die URL für das öffentliche Zertifikat wird mit jedem Request mit geschickt. Einmal runterladen sollte reichen. Ich denke, man muss es nicht bei jedem Request erneut vom StudiVZ Server laden. Den Consumer Token findet ihr in der OAuth Section eurer Gadget Sandbox (http://www.meinvz.net/GadgetDeveloper/GadgetOAuth/xxx). xxx ist deine Gadget ID.

Sollte der before_filter nicht abbrechen war die Signatur korrekt und der Request kann bearbeitet werden. Aus einem mir nicht bekannten Grund ist der Request des Containers an das Backend mit der RSA-SHA1 Methode signiert. Dafür wird das Zertifikat benötigt. Für den Request an die API muss die HMAC-SHA1 Methode verwendet werden. Dafür wird ein neuer Consumer benötigt:

def get_owner
  consumer = OAuth::Consumer.new(ConsumerToken, ConsumerSecret,
      :signature_method => 'HMAC-SHA1',
      :site => "http://sandbox.gadgets.apivz.net",
      :scheme => :query_string,
      :http_method => :get)
  requestor_param = {:xoauth_requestor_id => params[:opensocial_owner_id]}.to_param
  access_token = OAuth::AccessToken.new(consumer)
  response = access_token.get("/social/rest/people/#{params[:opensocial_owner_id]}/@self?#{requestor_param}")
  owner_attributes = JSON.parse(response.body)['entry']
end

Feedback, Fragen und Kritik sind immer gerne willkommen.

A screenshot of moviepilots trailerquizz on myspace.com

Fast jeder ist schon einmal auf myspace.com gewesen und hat nach Freunden gesucht, oder sich die ein oder andere auffällig bunt blinkende Seite angesehen. Als neues Highlight kann man sich zu seiner myspace Seite nun auch externe Programme, sogenannte Widgets hinzufügen. Dafür hat myspace.com seine Plattform geöffnet und eine API geschaffen. Derzeit ist das noch im Beta Stadium, jedoch gibt es schon einige nette Programme.

Als eines der ersten deutschen Widgets gibt es das Trailerquiz von moviepilot. Erstaunlich viel Spaß macht das Erraten eines Filmes anhand eines max. 10 Sekunden langen Trailers. Wählt man den richtigen der vier vorgegebenen Filmtitel, erhält man dafür Punkte. Hilfe erhält man, indem nach und nach falsche Filmtitel verschwinden. Je mehr Zeit für die Antwort benötigt wird, desto weniger Punkte gibt es. Als zusätzlicher Anreiz werden die Punkte mit einem Bonusfaktor multipliziert, je häufter richtige Antworten in Folge gegeben werden. Allerdings ist das Spiel vorbei, wenn man fünf mal falsch geraten hat.

Wer meint, das wäre kinderleicht, der kann es gerne mal ausprobieren. Die kurzweilige Auswahl der Filme reicht vom aktuellen Blockbuster bis hin zum alltime favourite. Und nun viel Spaß beim raten, es gilt den Highscore von poweruser “zorro” mit 2800 Punkte zu schlagen.

Update: Jetzt ist der Trailerquiz endlich auch ohne ein Myspace Konto benutzbar. Also, gleich mal testen!

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.

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.

• valides XHTML 1.0 strict
• Optimierung des Inhalts für die Suchmaschinenindizierung
• Trennung von Inhalt und Aussehen mit Hilfe von CSS
• Trennung von Inhalt und Verhalten mit Hilfe von Javascript Bibliotheken
• Und selbstverständlich: identisches Aussehen und Verhalten in allen Browsern

[ad#vert-banner]

Soviel zur Theorie, denn jeder Webentwickler wird die Schmerzen bereits kennen, die ich im Moment empfinde. Die freie Auslegung der verabschiedeten Webstandards in den verschiedenen Webbrowsern macht die Entwicklung zu einer Tortour. Lässt sich in Browser f das Aussehen eines bestimmten Elementes definieren, ignoriert Browser e diese Anweisung beflissentlich. Definiert man die Position im externen CSS Stylesheet für ein Element relativ, so muss es für “nicht-Standard-Browser” absolut positioniert werden, um das gleiche Ergebnis zu erzielen. So setzt sich die Quälerei unendlich fort. Und immer öfter zwängt sich mir die Frage auf, wie ein ominöser Mensch namens Bill G. in der Softwarewelt mit konsequent nicht-standardkonformer Software so groß werden konnte. Man sehe mir die Polemik nach, aber es sind wirklich Schmerzen, die ich demütig erdulde.

Für mich als Mac User stellt sich neben dem Unverständnis für die microsoftsche Auslegung von Standards ein weiteres Problem: Wie testet man das entwickelte Produkt im berühmten Internet Exploder? Ich habe mich für die, in meinen Augen einzige, Möglichkeit entschieden, Microsoft Windows XP in einen digitalen Käfig zu sperren. Mit Hilfe von Parallels Desktop läuft das weit verbreitete Betriebssystem als Gast in meiner nativem Umgebung. Wann immer ein neues Feature oder eine weitere Komponente vermeintlich fertig gestellt wurde, werfe ich mein Parallels an. Der schmermütige Atemzug beim Betrachten im IE ist obligatorisch. Doch kleine Tools wie die Internet Explorer Developer Toolbar verhelfen der Weboberfläche mehr oder weniger schnell zum gewünschten Aussehen bzw. Verhalten.

Natürlich ist Parallels nicht auf Microsoft Windows beschränkt, sondern gewährt auch anderen Vertretern der Gattung Betriebssystem temporären Unterschlupf. Ich kann jedem diese Software nur wärmstens ans Herz legen.