Ich habe es zum Laufen gebracht, aber die Lösung ist etwas komplex.
Was ist los
Internet Explorer verleiht IFRAME-Seiten ein geringeres Maß an Vertrauen (IE nennt dies "Inhalte von Drittanbietern"). Wenn die Seite im IFRAME keine Datenschutzrichtlinie enthält, werden ihre Cookies blockiert (was durch das Augensymbol in der Statusleiste angezeigt wird, wenn Sie darauf klicken, wird eine Liste blockierter URLs angezeigt).
(Quelle: piskvor.org )
In diesem Fall wird beim Blockieren von Cookies keine Sitzungskennung gesendet, und das Zielskript gibt den Fehler "Sitzung nicht gefunden" aus.
(Ich habe versucht, die Sitzungskennung in das Formular zu setzen und sie aus POST-Variablen zu laden. Dies hätte funktioniert , aber aus politischen Gründen konnte ich das nicht tun.)
Es ist möglich, die Seite im IFRAME vertrauenswürdiger zu machen: Wenn die innere Seite einen P3P-Header mit einer Datenschutzrichtlinie sendet , die für den Internet Explorer akzeptabel ist, werden die Cookies akzeptiert .
Wie man es löst
Erstellen Sie eine p3p-Richtlinie
Ein guter Ausgangspunkt ist das W3C-Tutorial . Ich habe es durchgesehen, den IBM Datenschutzrichtlinien-Editor heruntergeladen und dort eine Darstellung der Datenschutzrichtlinie erstellt und ihr einen Namen gegeben, auf den sie verweisen kann (hier war es policy1
).
HINWEIS : An diesem Punkt müssen Sie tatsächlich herausfinden, ob Ihre Website über eine Datenschutzrichtlinie verfügt, und wenn nicht, erstellen Sie diese - ob sie Benutzerdaten sammelt, welche Art von Daten, was sie damit macht, wer Zugriff darauf hat, usw. Sie müssen diese Informationen finden und darüber nachdenken . Nur ein paar Tags zusammenzuschlagen, wird es nicht schneiden. Dieser Schritt kann nicht nur in Software ausgeführt werden und ist möglicherweise sehr politisch (z. B. "Sollen wir unsere Klickstatistiken verkaufen?").
(zB "die Site wird von ACME Ltd. betrieben, sie verwendet anonyme Sitzungskennungen für ihren Betrieb, sammelt Benutzerdaten nur, wenn dies ausdrücklich gestattet ist, und nur für die folgenden Zwecke werden die Daten nur so lange wie nötig gespeichert, nur unser Unternehmen hat Zugriff darauf usw. usw. ").
(Beim Bearbeiten mit diesem Tool können Fehler / Auslassungen in der Richtlinie angezeigt werden. Sehr nützlich ist auch die Registerkarte "HTML-Richtlinie": Unten befindet sich eine "Richtlinienbewertung" - eine schnelle Überprüfung, ob die Richtlinie blockiert wird nach den Standardeinstellungen des IE)
Der Editor exportiert in eine .p3p-Datei, die eine XML-Darstellung der obigen Richtlinie ist. Es kann auch eine "kompakte Version" dieser Richtlinie exportieren.
Link zur Richtlinie
Dann wurde eine Richtlinienreferenzdatei ( http://example.com/w3c/p3p.xml
) benötigt (ein Index der von der Site verwendeten Datenschutzrichtlinien):
<META>
<POLICY-REFERENCES>
<POLICY-REF about="/w3c/example-com.p3p#policy1">
<INCLUDE>/</INCLUDE>
<COOKIE-INCLUDE/>
</POLICY-REF>
</POLICY-REFERENCES>
</META>
Das <INCLUDE>
zeigt alle URIs an, die diese Richtlinie verwenden (in meinem Fall die gesamte Site). Die Richtliniendatei, die ich aus dem Editor exportiert habe, wurde in hochgeladenhttp://example.com/w3c/example-com.p3p
Senden Sie den kompakten Header mit Antworten
Ich habe den Webserver auf example.com so eingestellt, dass er den kompakten Header mit folgenden Antworten sendet:
HTTP/1.1 200 OK
P3P: policyref="/w3c/p3p.xml", CP="IDC DSP COR IVAi IVDi OUR TST"
// ... other headers and content
policyref
ist eine relative URI zur Richtlinienreferenzdatei (die wiederum auf die Datenschutzrichtlinien verweist), CP
ist die kompakte Richtliniendarstellung. Beachten Sie, dass die Kombination der P3P-Header im Beispiel möglicherweise nicht auf Ihrer spezifischen Website anwendbar ist. Ihre P3P-Header MÜSSEN Ihre eigenen Datenschutzbestimmungen wahrheitsgemäß wiedergeben!
Profitieren!
In dieser Konfiguration wird der böse Blick nicht angezeigt, die Cookies werden sogar im IFRAME gespeichert und die Anwendung funktioniert.
Bearbeiten: Was NICHT zu tun ist, es sei denn, Sie verteidigen gerne gegen Klagen
Einige Leute haben vorgeschlagen, "nur ein paar Tags in Ihren P3P-Header zu stecken, bis der böse Blick aufgibt".
Die Tags sind nicht nur ein Haufen Bits, sie haben auch reale Bedeutungen und ihre Verwendung gibt Ihnen reale Verantwortlichkeiten !
Wenn Sie beispielsweise so tun, als würden Sie niemals Benutzerdaten erfassen, wird der Browser möglicherweise glücklich. Wenn Sie jedoch tatsächlich Benutzerdaten erfassen, widerspricht der P3P der Realität. Schlicht und einfach, Sie belügen Ihre Benutzer absichtlich , und das kann in einigen Ländern kriminelles Verhalten sein. Wie in "Geh ins Gefängnis, sammle keine 200 Dollar".
Einige Beispiele ( siehe p3pwriter für den vollständigen Satz von Tags ):
- NOI : "Die Website sammelt keine identifizierten Daten." (Sobald es Anpassungen, ein Login oder eine Datenerfassung gibt (***** Analytics, irgendjemand?), müssen Sie dies in Ihrem P3P bestätigen.)
- STP : Informationen werden aufbewahrt, um den angegebenen Zweck zu erfüllen. Dies erfordert, dass Informationen zum frühestmöglichen Zeitpunkt verworfen werden. Websites MÜSSEN über eine Aufbewahrungsrichtlinie verfügen, die einen Zeitplan für die Zerstörung erstellt. Die Aufbewahrungsrichtlinie MUSS in die für Menschen lesbare Datenschutzrichtlinie der Website aufgenommen oder von dieser verlinkt sein. "(Wenn Sie
STP
also eine Aufbewahrungsrichtlinie senden, aber keine haben , begehen Sie möglicherweise Betrug. Wie cool ist das? Überhaupt nicht.)
Ich bin kein Anwalt, aber ich bin nicht bereit, vor Gericht zu gehen, um zu prüfen, ob der P3P-Header wirklich rechtsverbindlich ist oder ob Sie Ihren Benutzern etwas versprechen können, ohne tatsächlich bereit zu sein, Ihre Versprechen einzuhalten.