Tag Archives: JSON

JSONP – Eine Methode um die Same-Origin-Policy zu umgehen

Die Same-Origin-Policy untersagt clientseitigen Skriptsprachen wie JavaScript Anfragen an Server zu stellen, die nicht der gleichen Herkunft / dem gleichen Speicherort entsprechen. Das ist eigentlich eine gute Sache, da es der Sicherheit beiträgt und gut zur Natur von JavaScript passt. Es gibt aber Fälle, bei denen man beabsichtigt Anfragen an andere Server stellen will. Als offensichtliches Beispiel wäre hier die Datenabfrage bei Diensten wie Twitter oder ähnlichen. Hierfür gibt es zum Beispiel JSONP, JSON with Padding.

Was steckt hinter JSONP

JSONP nutzt eine “Lücke” um eine HTTP-Anfrage an einen Server zu senden, der nicht der gleichen Herkunft (Origin) wie der des JavaScripts entspricht. Die SRC-Attribute im Script-Tag können GET-Anfragen an Server beliebiger Herkunft senden. GET eigentlich im Sinne von: Schick mir mal das JavaScript (meist in Form einer .js-Datei) und nicht im Sinne von; Schick mir mal die JSON Daten.

Was aber beim Script-Tag eigentlich passiert ist, dass der Browser die JavaScript-Datei lädt und ausführt. Aus

<script type="text/javascript" src="http://meinserver.de/meinScript.js"></script>
view raw gistfile1.html hosted with ❤ by GitHub

wird also quasi ein:

<script type="text/javascript">
;(function() {
console.log("Hello World")
})();
</script>
view raw gistfile1.html hosted with ❤ by GitHub

Wie funktioniert nun JSONP?

JSONP nutzt eben beschriebenes Prinzip, indem der Server auf diese GET-Anfrage nicht mit normalen JSON-Daten antwortet, sondern noch ein Extra hinzufügt. Die JSON-Daten werden in einem Funktionsaufruf gehüllt, dieser Funktionsaufruf ist das P für Padding in JSONP. Das ist nicht unbedingt die beste Namenswahl gewesen, da Padding bei Webentwicklern durch CSS mental schon vorbelegt ist. Hier heisst es aber einfach nur, wie gesagt, dass die JSON-Daten in einem Funktionsaufruf gehüllt werden.

JSON: {"Name": "Benny Bennet", "Website": "http://ben.nyben.net"}
JSONP: verarbeiteDaten({"Name": "Benny Bennet", "Website": "http://ben.nyben.net"})
view raw gistfile1.js hosted with ❤ by GitHub

In der Regel teilt man dem Server per Parameter mit, in welchen Funktionsaufruf er die Daten hüllen soll.

<script type="text/javascript" src="http://some.tld/web/service?callback=verarbeiteDaten"></script>
... wird zu
<script type="text/javascript">
verarbeiteDaten({"Name": "Benny Bennet", "Website": "http://ben.nyben.net"})
</script>
view raw gistfile1.html hosted with ❤ by GitHub

Der geneigte JavaScripter müsste jetzt also nur noch irgendwo die Funktion “verarbeiteDaten” implementieren…

function verarbeiteDaten( data ) {
console.log(data["Name"]);
console.log(data["Website"]);
}
view raw gistfile1.js hosted with ❤ by GitHub

…und würde in seiner Console in diesem Beispiel die Ausgaben “Benny Bennet” und “http://ben.nyben.net” erhalten. Als Nachteil ist hier natürlich zu erwähnen, dass man dem Service 100% vertrauen können muss.