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.

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.

ROAR (Resource Oriented Architecture)

Fast einen ganzen Monat lange habe ich sozusagen den Zirkel zur Seite gelegt und mich mit der technischen Umsetzung der Ginkgo-API in Rails befasst. Die endgültige Wahl des GEMs, was mich dabei unterstützen soll, ist auf ROAR (Resource Oriented Architecture) gefallen. Was hat mich dazu gebracht, ROAR zu nutzen und nicht einen der anderen 6 untersuchten Kandidaten? Im Endeffekt Bidirektionalität!

Mit ROAR werden einfache Ruby-Module definiert, welche das Erscheinungsbild der vom REST-Service gelieferten Repräsentationen bestimmen:

module ProfileRepresenter
include Roar::Representer::JSON

property :name
property :description
property :gender
property :status, :from => :andererName
property :timezone

link :self do
api_user_profile_url user.id
end
end

Some People Understand REST and HTTP…

Im Blog des REST-Hardliners Steve Klabnik habe ich gerade diesen Post gesehen: Dort lobt er die Twilio– und GitHub-Api.

Also unsere ginkgo-API würde er demnach sehr mögen ;-)