Jeder Webentwickler hat wahrscheinlich schon mit der same-origin policy zu kämpfen gehabt. Im folgenden geht es darum wie man unter bestimmten Umständen mit Window.postMessage
cross-origin Kommunikation erlauben kann. Wir haben schon des öfteren Applikationen/Webpages via iFrame auf einer Seite eingebunden. Wenn hier nun das eingebundene iFrame mit der Webseite über Javascript kommunizieren soll, wird es schwierig, wenn die Domains der beiden Seiten nicht gleich sind. Hier weist uns die same-origin policy in die Schranken – was ja aus Sicherheitsgründen sehr gut ist. Falls man gar keine Möglichkeit hat die beiden Elemente unter die selbe Domain zu bringen wird’s knifflig sie miteinander kommunizieren zu lassen.
Ein simples Beispiel
Wir möchten eine kleine Applikation als iFrame auf einer anderen Webseite einbinden. Wir haben Zugfriff auf das CMS Backend der Webseite und auf unseren Server auf dem die App liegt. Aus diversen Gründen ist es nicht möglich unsere App über die Domain/Server der eigentlichen Webseite zu hosten. Das stellt uns jetzt vor ein Problem, weil wir im iFrame auf bestimmte Koordinaten scrollen möchten. Und hier kommt jetzt Window.postMessage
ins Spiel!
Im Groben funktioniert das Ganze so: Mit postMessage senden wir Daten an die Webseite. Die Webseite wartet darauf, dass wir ihr etwas schicken – wenn sie die Daten von uns erhalten hat, scrollt sie einfach zu einer bestimmten Position. Da wir ja Zugriff auf das CMS Backend haben und die Seite auf der das iFrame eingebunden ist, können wir hier unseren “Ich warte auf Daten und scrolle dann” – Javascript Code einfügen.
Nun wird es technischer
[code language=“javascript“]
parent.postMessage(’scroll‘, ‚http://example.at‘);
[/code]
So könnte unser Aufruf aus dem iFrame heraus aussehen. Mit parent wird die Seite angesprochen die das iFrame einbindet, scroll ist ein einfacher String den wir hinsenden und http://example.at ist die Ziel-origin.
Auf example.at müssen wir nun die Nachricht empfangen. Das könnte zB so aussehen (wir arbeiten hier übrigens auch mit jQuery):
[code language=“javascript“]
window.addEventListener(‚message‘, receiveMessage);
function receiveMessage(event) {
if (event.origin !== ‚http://meine-app.at‘)
return;
if (event.data !== ’scroll‘)
return;
var temp = parseInt(event.data) + 500;
$(‚html,body‘).scrollTop(500);
}
[/code]
Als erstes haben wir hier einen EventListener erstellt der auf Daten warten und dann die Funktion receiveMessage aufruft.
In dieser Funktion ist es zuerst einmal ganz wichtig zu überprüfen wer uns da etwas schickt! Hier checken wir, ob die Daten von http://meine-app.at kommen – wenn nicht, arbeiten wir nicht weiter. Weil es sich hier so schön anbietet, überprüfe ich noch den Inhalt der gesendeten Daten.
Wenn alles passt führen wir die Scroll-Operation auf der “Haupt”-Webseite durch.
Fazit
postMessage ist sicher keine Funktion die man jeden Tag braucht, aber durchaus nützlich wenn man vor den Problemen der cross-origin Kommunikation steht. Hier muss man auch im Kopf behalten, dass es die same-origin policy nicht umsonst gibt und postMessage mit Vorsicht zu genießen ist. Ausführlichere Infos, sowie Daten zur Browser Kompatibilität findet ihr auf developer.mozilla.org, des weiteren gibt es auf dem Treehouse Blog ein Tutorial dazu.
Du willst mit jemanden über das Thema plaudern?
Einen kostenlosen Termin mit CEO Susanne vereinbaren!UX Snacks Vol.09
That’s a wrap on UX Snacks 2024. Am 7. November hat die vierte und letzte Ausgabe in diesem Jahr stattgefunden und wir nehmen mit diesem Recap ganz viel positive UX-Energie mit ins neue Jahr. Und keine Angst: Schon bald verkünden wir die Daten für 2025.
Jetzt lesenFolge #62 mit Susanne Liechtenecker
In Folge 62 besinnt sich Susanne auf die Anfänge dieses Podcasts und begrüßt keinen Gast, sondern erzählt über das Buch "Jäger, Hirten, Kritiker" von Richard David Precht und warum es sie inspiriert hat.
Jetzt anhören