Damit der Rocket Rentals Server richtig auf den Request reagieren kann, muss im Admin Frontend ebenfalls eine Subdmain angelegt werden. Dazu logged man sich unter beim Hosting ein. Im oberen Menü wählt man “Sites”. Aus dem linken Menü wählt man dann “Subdomain” aus. Das Host Feld beinhaltet den Namen der Subdomain. Der Redirect Type ist “No flag”. Der Redirect Path ist “/<subdomain>_<domain>_<tld>”. Beispiel: “/staging_wheelmap_org”. Nach dem Speichern dauert es höchstens 15 Minuten, bis die Änderungen aktiv sind. In der Zwischenzeit können wir aber schon eine neue Datenbank anlegen. Das ist besonders wichtig, da wir nicht die Produktivdatenbank versehentlich verändern wollen, wenn die Auftraggeber die neue Version ausprobieren und dabei Daten manipulieren. Auch das kann auf der Admin Seite des Rocket Rentals Frontend geschehen. Usernamen und Passwort für die Datenbank nicht vergessen!

Dann muss auf dem Rechner, der das deployment durchführt eine Capistrano Erweiterung installiert werden:

sudo gem install capistrano-ext

Danach muss die deploy.rb Datei etwas angepasst werden. Füge folgende Zeilen an den Anfang der Datei:

# config/deploy.rb

set :stages,        ['staging', 'production']
set :default_stage, 'staging'
require 'capistrano/ext/multistage'

Jetzt werden für jede Umgebung im Rails Projekt unter config/deploy/ eine eigene Datei mit dem Umgebungsnamen angelegt:

mkdir -p config/deploy
touch config/deploy/staging.rb
touch config/deploy/production.rb

Aus der bisherigen deploy.rb Datei müssen folgende Zeilen in die config/deploy/production.rb kopiert werden:

# config/deploy/production.rb

set :application, 'domain_tld' # Beispiel: wheelmap_org
set :db_names, :production => 'prod_db_name'
set :db_user, 'prod_db_username'
set :db_password, 'prod_db_password'
set :rails_env,   'production'

Anschließend müssen diese Zeilen in der config/deploy.rb auskommentiert oder gelöscht werden.

In der config/deploy/staging.rb Datei müssen jetzt die Angaben für die Staging Umgebung gemacht werden:

# config/deploy/staging.rb

set :application, 'subdomain_domain_tld' #Beispiel: staging_wheelmap_org
set :db_names, :production => 'staging_db_name'
set :db_user, 'staging_db_username'
set :db_password, 'staging_db_password'
set :rails_env,   'staging'

Nun sind alle Vorbereitungen getroffen und wir können die Staging Umgebung einrichten:

cap staging deploy:setup

Danach kann die Anwendung deployed werden:

cap staging deploy:cold

Will man die Live Version deployen führt man folgenden Befehl aus:

cap production deploy

Bei Problemen oder Fragen einfach einen Kommentar hinterlassen.

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.