Sperrobjekt Weblog

Vorhin habe ich etwas mit YQL herumgespielt und versuchsweise das API von last.fm angezapft. Der Aufruf der einzelnen Methoden setzt einen API-Schlüssel ("API Key") voraus, den man problemlos bei last.fm beantragen kann. Ich habe mich lange gefragt, wie ich diese Methoden mit reinem Javascript auf einer öffentlich zugänglichen Webseite aufrufen kann, ohne meinen API Key ebenfalls öffentlich zu machen. Denn beim Testen innerhalb der YQL Console ist er Teil des SELECT-Statements, auf meiner Seite darf er das nicht mehr sein. Im folgenden zeige ich, aufbauend auf einem Artikel von Nagesh Susarla, was zu tun ist, damit man den geheimen API-Schlüssel geheim halten und dennoch für seine YQL-Abfragen nutzen kann.

Damit kann ich beispielsweise meine wöchentlichen Top-Künstler von last.fm abrufen kann, reichen mir ein paar Zeilen Javascript-Code, einen eigenen Webserver benötige ich dafür gar nicht. Als Grundlage dient mir das offizielle YQL-Tutorial First YQL Application, das ihr euch vielleicht ansehen solltet, falls ihr noch nie mit YQL zu tun hattet. Die Daten, sprich meine Top-Künstler, beziehe ich aus der Community Table lastfm.user.getweeklyartistchart (dort auf Test klicken).

Um nun an meine Liste heranzukommen, schicke ich folgende Abfrage ab:

select '*' from lastfm.user.getweeklyartistchart where user = 'numblog' and api_key = 'API_KEY'

In der YQL Console ausführen (ihr benötigt einen gültigen API Key) - Hinweis: Die Hochkommata um das Sternchen bitte weglassen; die stehen da nur, weil sonst das Syntax-Highlighting kaputt geht.

Wollte ich diese Abfrage in meine Webseite einbinden, wäre der API Key für alle lesbar:

Ich will natürlich vermeiden, dass Dritte mit meinem API Key auf last.fm zugreifen. Hier kommt Yahoo! Sherpa ins Spiel, ein Key-Value-Store in der Cloud. Dieser kann ebenfalls via YQL angesprochen werden und bietet die üblichen Vorteile (und Nachteile) einer Cloud-Lösung. Zwei Open Data Tables werden angeboten, yql.storage und yql.storage.admin, wobei yql.storage.admin die Tabelle unserer Wahl ist, weil sie nur nach erfolgter OAuth-Anmeldung oder über die YQL Console befüllbar ist. Mehr Info dazu bietet die Dokumentation.

Aber gehen wir noch einmal einen Schritt zurück. Anstatt den API Key in der WHERE-Bedingung zu übergeben, könnten wir auch folgendermaßen vorgehen und die Variable schon vor unserer Abfrage setzen:

use 'http://www.datatables.org/lastfm/lastfm.user.getweeklyartistchart.xml' as lastfm.user.getweeklyartistchart;
set api_key='API_KEY' on lastfm.user.getweeklyartistchart;
select "*" from lastfm.user.getweeklyartistchart where user = 'numblog';

Wenn wir dies nun mit der Tabelle yql.storage.admin verbinden und in der YQL Console (in eingeloggtem Zustand, ihr benötigt also auch einen Yahoo!-Account) die Daten mit dem entsprechenden Statement in die Cloud schreiben:

insert into yql.storage.admin (value) values ("use 'http://www.datatables.org/lastfm/lastfm.user.getweeklyartistchart.xml' as lastfm.user.getweeklyartistchart;
set api_key='API_KEY' on lastfm.user.getweeklyartistchart;")

dann erhalten wir dem folgenden ähnliches XML zurück:

    
        store://I2KUjXfoobarAzIw0v3vfv
        store://p6QZPnGmgyoafoobarNimz
        store://jTfoobarMLleWbJoMY8phd
    

Dieses Ergebnis solltet ihr euch gleich mal in einen Editor kopieren, denn das benötigen wir gleich wieder zur Abfrage auf unserer Webseite. Kurz erklärt:

• Der execute-Schlüssel kann nur zur Ausführung von Abfragen verwendet werden. Die hinterlegten Daten werden nicht ausgegeben.
• Der select-Schlüssel sollte geheim bleiben, denn damit lassen sich die Einträge aus yql.storage auslesen.
• Der update-Schlüssel erlaubt das Verändern dieser Einträge; somit sollte auch er geheim bleiben.

Mithilfe des execute-Schlüssels, den wir als Umgebungsvariable übergeben, lässt sich unsere Abfrage nun ohne Angabe des API Key ausführen:

Ihr könnt in der YQL Console auch gern die Sicherheit des execute-Schlüssels testen und werdet einen Permission-Error zurückbekommen:

select * from yql.storage where name='store://I2KUjXfoobarAzIw0v3vfv'

In der YQL Console ausführen.

Somit steht dem clientseitigen Anzapfen diverser APIs nichts mehr im Wege, auch wenn ein API Key verlangt wird. Momentan gibt es bereits weit über 800 Open Data Tables, über die Daten von den verschiedensten Diensten abgerufen werden. Viele davon sind frei zugänglich, andere benötigen einen API Key. Fragt ihr diese vom Server aus ab, stellt das kein Problem dar. Eine rein clientseitige Lösung im Browser hat aber auch ihren Charme. Es wird kein Server benötigt und daher auch nicht belastet, Yahoo! übernimmt im Hintergrund viel Arbeit (Caching, Fehlerbehandlung, ...) für euch, und möglicherweise ist alles viel schneller. Und jetzt auch sicher.

Hier die simple Ausgabeliste meines einfachen Beispiels:

<div id="yql_lastfm_results" style="margin-left:1em;"></div>
<script src="http://query.yahooapis.com/v1/public/yql?q=select%20*%20from%20lastfm.user.getweeklyartistchart%20where%20user%20%3D%20'numblog'&format=json&diagnostics=true&env=store%3A%2F%2FI2KUjXc5O0hZAzIw0v3vfv&callback=top_stories"></script>

Two days ago, Benjamin Nowack announced the re-release of Knowee, a distributed social web address book. Knowee started out as a project supported by the W3C Semantic Web Interest Group and will also available for download soon. This means you can install it on your own server, if you like.

Knowee is somewhat similar to NoseRub as it aggregates many of your profiles from popular social networks and applications like Twitter, Identi.ca, or Delicious. But Knowee adds a lot of semantic wizardry to all the data its bots collect over time. Among the technologies employed are FOAF, RDF, Microformats, OpenID, Google's Social Graph API, and SPARQL. The latter makes it easy to re-use the aggregated information in other applications. Without digging too deep into all these formats and APIs, let me say this seems to evolve into a very powerful tool, far more than a simple address book. For more info, read the introductory blog post, or simply take a shot at it.

That being said, I'm a little irritated about how little buzz Knowee has created so far (only 4[!] hits on Technorati?). Is everyone simply fed up with yet another social network aggregator? Or am I just a little bit too impatient? I don't know, but I know that Knowee deserves more attention even if it's still in an early stage. Especially since I'm sure that Benjamin will add more useful features soon, e.g. the integration of MyBlogLog.

My public Knowee profile can be found here.

Magdalena Böttger, Business Development bei Netvibes, stellt uns jetzt Netvibes Widgets und das Universal Widget API vor. Für mich nicht ganz neu, ich habe mich da schonmal eingelesen, und außerdem lerne ich immer wieder ganz viel von Raphael, unserem Diplomanden, der seine Diplomarbeit (die ich betreue *g*) über Netvibes schreibt bzw. sogar eine Applikation auf dieser Basis entwickelt. Sehr spannend das alles.

Wir schauen uns zunächst mal den Quellcode eines Widgets an, haben aber gerade Probleme, ein gutes Beispiel zu finden. Die Diskussion dreht sich im Anschluss an das Demo eines Facebook-Widgets um Datenschutz und Sicherheit von Widgets. Beispielsweise bietet eine Bank aus Luxemburg ein Kontoabfrage-Widget an, das im Endeffekt aber nur einen iframe einbettet. Laangweilig. 18 Millionen Widget-Impressions, das ist schon spannender. Und man kann netvibes als Whitelabel-Lösung ("premium universe") kaufen und bekommt auf diese Weise ein personalisiertes Portal (Bsp.: my.numericable.fr). Auch interessant. Aber insgesamt läuft die Session etwas an meinen Interessen vorbei. Nur irgendwelche Such-, Monitoring- oder Spiel-Widgets, naja. Und alle wollen ihre eigenen Seiten über netvibes pushen. Es geht also nicht wirklich um Widget-Entwicklung. Gleich Mittagessen, immerhin.