12. September 2011 von & gespeichert unter Programmierung, Tipps.

Immer wieder werden Entwickler durch den Internet Explorer, vor allem in den älteren Versionen bis Version 7, vor Herausforderungen gestellt. Meist entstehen Probleme bei der Umsetzung von HTML Layouts mit CSS. Doch auch unter programmiertechnischen Aspekten hat der Internet Explorer zum Teil seine Tücken.

Eine Schwierigkeit ist die, dass eine besondere Sicherheitsmaßnahme des Internet Explorers unter Umständen Cookies aus IFrames blockiert. Gerade für Facebook Apps, die mittlerweile alle in IFrames laufen, soll dieser Artikel Lösungsansätze liefern.

Das Problem

Der Internet Explorer behandelt Inhalte aus IFrames als „third-party“ Inhalte und stuft diese als weniger vertrauenswürdig ein. Wenn die Seite innerhalb des IFrames keine Datenschutzerklärung (Privacy Policy) enthält, werden deren Cookies geblockt. Das führt bei Facebook Apps dazu, dass Cookies, welche unter normalen Umständen bei einer Anfrage über das JavaScript SDK gesetzt würden, blockiert werden.

1
2
3
4
5
6
7
8
9
FB.login(function(login) {
    if (login.session) {
        FB.api('/me?access_token=' + login.session.access_token, function(userObject) {
            if (userObject && !userObject.error) {
                ... Ajax-Anfrage an Server ...
            }
        });
    }
});

Wird innerhalb der JS-Funktion ein Ajax-Aufruf an den Server geschickt, kann über das PHP SDK von Facebook keine Session gefunden werden und Anfragen an die Graph-API schlagen fehl.

Die saubere Lösung

Es ist möglich die IFrame-Inhalte vertrauenswürdiger zu machen. Wenn die Seite im IFrame einen p3p-Header mit einer Datenschutzerklärung sendet, welche vom Internet Explorer akzeptiert wird, können Cookies gespeichert werden.

Eine Anleitung, eine solche p3p policy zu erstellen findet sich unter http://stackoverflow.com/questions/389456/cookie-blocked-not-saved-in-iframe-in-internet-explorer.

In verschiedenen Foren werden außerdem Lösungsansätze beschrieben, bei denen nur folgender Header gesetzt werden muss (zum Teil mit variierenden Attributen):

1
header('P3P: CP="NOI ADM DEV COM NAV OUR STP"');

Von dieser Lösung ist grundsätzlich abzuraten! 

Sie führt zwar in einigen Versionen des Internet Explorers zum gewünschten Erfolg, doch bewegt man sich damit rechtlich auf dünnem Eis. Jedes Attribut in diesem Header hat eine konkrete Bedeutung und es ist wichtig, dass die Seite auch wirklich die Anforderungen erfüllt, die durch den Header deklariert werden. Ansonsten hat der Betreiber im Falle eines Rechtsstreits schlechte Karten.

Ein Workaround

Für einfache Anfragen an den Server, bei denen eine Übertragung der Facebook User ID über JavaScript vermieden werden soll (Verhinderung von Manipulation bei Votings etc.) kann man sich mit einem kleinen Workaround behelfen.

Um auch ohne Cookie vom Server aus auf die aktuelle Session des Facebook Nutzers zugreifen zu können, kann das access_token, welches man als Callback über das JS SDK erhält, mit der Anfrage übermittelt werden.

Serverseitig muss dieses access_token, was die Gültigkeit der Session bestätigt, an alle Graph-API anfragen angehängt werden.

1
$facebook->api('/me','GET',array("access_token" => $access_token));

Die Sicherheit vor Manipulation ist auch in diesem Fall gegeben, da dasaccess_token nur in Verbindung mit dem korrekten application secret die Session als gültig bestätigt.

Diese Lösung ist für einfache Anfragen per Ajax ausreichend. Bei einer Anwendung mit umfangreichem Funktionsumfang ist die Erstellung einer gültigen p3p policy wohl die bessere Lösung, da dann nicht bei jeder Anfrage das access_token übermittelt werden muss.




Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.