Ginkgo API – aber sicher!

7 Feb

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)

Sicherheit ist hier also nicht nur auf Methoden- sondern auch auf Feldbasis zu beachten.
Um das alles umzusetzen, wurde unbedingt OAuth benötigt. Nach einigen (ok eher vielen) Anpassungen, verrichtet das oauth-plugin -GEM nun treu seine Dienste.
App-Entwickler können ihre App registrieren und erhalten die benötigten OAuth2-Parameter:

 

 

 

 

Gemäß dem Authorization Code Grant flow sendet die App seinen Nutzer zur ginkgo-Loginseite, wo er sich einloggt und die App autorisiert, in seinem Namen auf die API zuzugreifen. (Grundsätzlich ist hier sogar ein doppelter OAuth möglich! Also dass sich ein Nutzer über seinen Twitter Account einloggt.)
Nach einem weiteren Token-Austausch erhält die App ein access token, das auf dem Smartphone gespeichert wird und für alle zukünftigen Anfragen Verwendung findet. Ein Nutzer kann dieses Recht jederzeit widerrufen.

 

 

 

Eine App muss mindestens seine bei ginkgo registrierte client ID mitschicken, sonst wird jede Anfrage abgewiesen. Mit dieser ID sind öffentliche Informationen auslesbar. API-intern sind nun alle in der Berechtigungsdatei vom CanCan-GEM definierten Gast-Berechtigungen aktiv.

Sendet die App ein valides access token, gelten die Nutzer-Berechtigungen. Hierbei sind noch weitere Überprüfungen notwendig. Z.b. ob die gerade zu ändernde User-Ressource auch wirklich dem Nutzer gehört, dem das access token zugeordnet ist.

Dass nur änderbare Felder angenommen werden, geschieht über die from_json-Methode des Representers:

def update
update_attrs = []
if params[:username]
update_attrs << :username
end
if params[:email]
update_attrs << :email
end
@user.extend(UserRepresenter).from_json(request.raw_post, :include => update_attrs).save
[..]
end

Außer username und email werden hier jegliche sonst noch in der Anfrage enthaltenen Daten ignoriert (Whitelist-Ansatz).

Dass einzelne Felder für bestimmte Nutzer nicht sichtbar sind, erledigt meine exclude_attrs-Methode nach einem Berechtiguns-Check über CanCan.

def show
@user.extend(UserRepresenter)
@user.exclude_attrs([„email“]) unless can? :update, @user
respond_with @user
end

Mein Liebslinksprogrammierer Nick hat den Mongoid-Bug beseitigt, der mir bestimmt 2 Monate lang auf den Magen geschlagen hat. Danke Nick :)

 
Nächste Ziele:
Caius mit benötigten Daten versorgen
– Masterarbeit weiterschreiben
– Features/Rspec/Cucumber zum Laufen bringen

Eine Antwort to “Ginkgo API – aber sicher!”

  1. caiuspb 8. Februar 2012 um 19:02 #

    Cool :)
    Ich werde es morgen ausprobieren

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: