Rainers Horen
Dienstag, den 22.05.2012 [10:33]
Die Woche hat sonnig begonnne und bist jetzt hält es sich. Leider ist die LuminiumApp von Apple wegen Belanglosigkeit abgelehnt worden. Solch ein Kleinod sollte eben mehr als eine mobile Webseite sein und damit meint Apple eben nicht die Technik, sondern den Inhalt. Eine einfache Sammlung von Videos (auch wenn es pfiffig gemacht ist) reicht eben nicht aus. Leider ist diese Woche keine Zeit zum Gedankenmachen – das ¬OAuth-Thema braucht die volle Aufmerksamkeit. Es gibt wie im Q&A-Beitrag beschrieben mindestens die fünf Möglichkeiten dieses Prozedere abzubilden und eigentlich muss nur eines funzen, aber es verschlingt Zeit. Die meiste Zeit braucht wohl das innere Verständnis des ganzen Vorgangs. Ist das im Kasten, kann auch eine mögliche Lösung evaluiert werden. Alle großen Webdienste nutzen das, damit von „außen“ auf das System zugegriffen werden kann. Und alle diese Dienste bieten Erklärungen an. Es sollte also möglich sein die Zusammenhänge zu raffen.

Yahoo (ja, die gibt es auch noch)hat diesen schönen Plan in seinem Dokubaum:



So auf dem ersten Blick erscheint das Schema erst einmal beeindruckend. Es löst sich aber beim näheren Hinsehen auf.

Der erste Schritt passiert weit vor dem ersten Start der App. Der AppEntwickler holt sich vom Anbieter eine AppID und ein Passwort dazu, das hier Secret heißt. Diese beiden kurzen Textschnipsel trägt er in seine App ein. Sie gelten qusi „ewig“ und weisen die App gegenüber dem Anbieter aus. Wer also Kenntnis von diesem Geheimnis hat, könnte also eine andere, böse App schreiben, die dann beispielsweise mittels Flutung auf der Gegenseite Engpässe auslöst.

Beim zweiten Schritt ist der Endnutzer noch nicht im Spiel. Die App schickt die beiden obigen Werte (AppId und AppSecret) auf die Reise. Der Server testet, ob das passend ist und antwortet mit einem RequestToken, dem dann auch noch Parameter wie die Gültigkeitsdauer beigegeben werden. Das alles passiert ohne Zutun des Nutzers. Jetzt sind sich also App und Server einig: – da geht was.

Jetzt nimmt die App im dritten Schritt diesen temporären RequestToken und fordert eine Loginmaske an. Der Nutzer gibt brav beispielsweise Login/Passwort ein. Das könnte aber auch ein anderes Identifikationsmerkmal sein. Es könnte sich die Kamera einschalten, die das Gesicht abtastet usw.

Soweit war das jetzt alles zu verstehen. Jetzt wird es allerdings mystisch: im vierten Schritt schickt der Server den Nutzer nach erfolgreicher Identifizierung zu einer neuen Seite. Die App fummelt jetzt den vom Server mitgelieferten OauthVerifier raus, nimmt noch seinen RequestToken und stellt eine nochmalige Anfrage zum Server. Wenn alles klappt, bekommt die App jetzt vom Server einen AccessToken und ein TokenSecret. In Besitz dieses temporären Geheimnisses darf die App jetzt tun, was sie möchte und was ihr erlaubt ist.

Nun bleibt das Umsetzerproblem eine passende Library rauszusuchen, die obiges Spiel abbildet. Nach längerem Stöbern im Netz kristallisieren sich zwei Lösungen heraus. ¬Rob Griffiths hat sein Baby ¬jsOAuth genannt. Es ist scheinbar gut dokumentiert, läuft auf dem iPhone sofort ohne Hadern, auf dem Android will es einfach nicht laufen. Haben wir diese Erfahrungen nicht schon öfters gemacht? Rob hat zwei Varianten im Angebot. Die eine Ausprägung ist in der klassischen Variante, bei der man die Library einbindet und dann die entsprechende Klasse aufruft. Wie gesagt, klappt sofort auf dem iPhone. Der androide Javascriptinterpreter kommt mit der speziellen Klasseneinbindesyntax nicht zurecht. Die andere Variante kommt aus der commonJS-Welt. In diesem Fall wird die Datei mit require eingebunden und liefert als Rückgabewert eine Instanz der Klasse. Soweit die Theorie. Klappt aber auf keinem Gerät. Es gibt im Manual auch keinen Verweis auf die zweite Variante. Eine Nachfrage deswegen bei Rob ist im ¬Forum abgesetzt.

Die zweite Lösung nennt sich ¬Birdhouse und ist von Joe iEntry gebaut. Bisher fällt es noch schwer, von der jsOAuth-Lösung Abschied zu nehmen - stecken da doch jetzt auch schon zwei Tage Mühe darin.
Beitrag kommentieren