Konzeption und agile Entwicklung einer REST-Schnittstelle für eine Rails-basierte Scientific Event Management Plattform

Mit der Präsentation ist meine Masterarbeit nun erfolgreich beendet. Ein Konzept, anhand dessen die ginkgo-API komplett entwickelt werden kann, ist im projekteigenen Wiki vorhanden. Der zugehörige Prototyp läuft seit einigen Wochen stabil und setzt Ressourcen in den Bereichen Nutzer, wissenschaftliche Veranstaltungen, private Nachrichten, Kurznachrichten und Activity Stream um.

Die rund 120 Features (dabei handelt es sich um vorhandene und gewünschte Funktionalitäten aus Nutzersicht) waren ein guter Startpunkt, um die für die REST-Schnittstelle benötigten Ressourcen und Repräsentationen herzuleiten.

Kombiniert man das RAILS-Framework mit einer Softwarekomponente, welche die Erstellung der Repräsentationen vereinfacht (z.B. ROAR), ist die Umsetzung einer REST-Schnittstelle sehr elegant möglich.

Mir persönlich hat es sehr viel Spaß gemacht, mit den für mich ganz neuen Technologien Rails und Ruby zu arbeiten und bedanke mich für die Unterstützung aus dem ginkgo-dev-Team!

Hier nun die Folien der Abschlusspräsentation:

 

OAuth2-Request in RSpec testen

Da mich die „Fehlersuche“ insgesamt 2 Tage beschäftigt hat und ich langsam glaube, dass ich für das Testen der ginkgo API insgesamt mehr Zeit gebraucht habe, als für die Implementierung, möchte ich zumindest eine Erkenntnis in die Welt streuen ;-) .

Während es in Cucumber-Tests sehr einfach ist einen authentifizierten OAuth2 HTTP-Request hinzubekommen (einfach nur den Authentication-Header setzen), gestaltet sich das in RSpec-Test schwerer. Das ist auch klar, weil viele helfende Komponenten von Rails richtigerweise nicht zum Einsatz kommen, um wirklich nur die aktuell betrachtete Komponente zu testen.

Um es kurz zu machen, für einen authentifizierten OAuth2 Request in RSpec-Tests benötigt das request-Objekt die beiden Parameter oauth.strategies und token. Also z.B. :

  def prepare_authenticated_access_token_request
# Create a valid, authorized access token
token = Oauth2Token.create :user => @resource_owner, :client_application => @client_application
# Configure the request object so that it is recognized as a OAuth request
request.env[„oauth.strategies“] = [:oauth20_token, :token]
request.env[„oauth.token“] = token
end

Für alle, die OAuth1-Requests erstellen wollen, sei auf configure_oauth eines TestRequests hingewiesen:

    ActionController::TestRequest.use_oauth=true
request.configure_oauth(@resource_owner,token)

Ginkgo-API: Testgetrieben läuft’s am besten

Ginkgo wurde von Beginn an testgetrieben entwickelt. Dieses Verhalten wird auch bei der API-Entwicklung beibehalten.

Bei der testgetriebenen Softwareentwicklung stellt ein Test mehr dar, als nur die Verifikation der Korrektheit von Programm-Quellcode. Ein Test gilt als Startpunkt, von dem ausgehend ein System in kleinen Schritten mit zusätzlichen Funktionalitäten angereichert wird.

Allerdings kann selbst die beste, nach diesen Maßstäben entwickelte Softwarekomponente auch einfach das Falsche umsetzen. Dies kann durch sich teilweise überlagernde Komponenten-und Akzeptanztest verhindert werden. Während Komponententests für einen isoliert betrachteten Programmteil seine technische Lauffähigkeit und fachliche Korrektheit bescheinigen, gewährleisten Akzeptanztests, dass sich das Gesamtsystem (meistens dem Anwender gegenüber) richtig verhält.

Activity Streams in der ginkgo-API

In ginkgo gibt es nutzer- und veranstaltungsspezifische Activity Streams, die über verschiedenste Aktivitäten auf dem Laufenden halten.

Da Activity Streams heutzutage in vielen Bereichen des Webs anzutreffen sind, sollten für dessen Aufbau allgemeingültige Standards eingehalten werden. Nur so kann der Austausch über Programmgrenzen hinweg ermöglicht werden, was natürlich das Hauptziel der ginkgo-API ist. Der Standard, der hier genutzt werden sollte, kommt von der Activity Streams Working Group: JSON Activity Streams 1.0.

Ginkgo API – aber sicher!

Verzeiht mir das kleine Wortspiel… :)

Pünktlich zum Safer Internet Day ist nun eine Möglichkeit gefunden und umgesetzt, um die ginkgo API gegen unberechtigten Zugriff zu schützen.

Die selbst gesteckten Anforderungen waren hart:

• Jede App, die auf die API zugreift, soll erkannt werden (z.B. zwecks Nutzungsauswertungen und Missbrauchsvorbeugung)

• Apps sollen „öffentliche“ Informationen auslesen können, ohne dass ein Nutzer sie dazu autorisiert hätte (Event-Mediastream, Call for Papers)

• Nutzer-spezifische Aktionen sollen nur durch vom Nutzer autorisierte Apps ausgeführt werden können (Freund hinzufügen, Status posten, Nutzerinformationen ändern)

• Apps dürfen keine nur lesbaren oder Systemfelder setzen können (Eventname ändern, Eventcreator ändern)

• Apps dürfen keine „privaten“ Felder auslesen können (E-Mailadresse eines anderen Nutzers lesen)

•  OAuth2.0 -Standard einhalten

Sicherheit ist hier also nicht nur auf Methoden- sondern auch auf Feldbasis zu beachten.