iFrame 3rd Cookie werden im Safari blockiert! Safari-Lösung

[th_wolfgang]

Hallo,

meine Problematik ist schnell erklärt, da ich denke hier nicht der einzige zu sein. Es handelt sich um 3rd Cookies im iFrame und zwar beim Safaribrowser. Leider konnte ich wie anfangs gedacht diese Problematik mit iFrame Sandbox-Attribute nicht lösen, um wohl der Beitrag erst vom August ist und Safari angeblich einschließt. Wie z.B. hier erklärt: ulrischa blog » 3rd-Party Cookies bei iFrame in IE und Safari ermöglichen Wer die Problematik mit dem IE 11 haben sollte, Sandbox-Attribute funktionieren da.

Jetzt bin ich auf der Suche das Safari-Problem anderweitig zu lösen, Leider ist mir bis her nichts so recht geglückt. Ich habe z.B. dies Script getestet, leider funktioniert dies nicht so, um wohl hier etliche positive Kommentare zu finden waren. Measurable Wins: Safari: Setting third party iframe cookies Mein Hoster bringt einen 404 Error.

Auch diese versuche waren bis her erfolglos:
Web Development Blog: PHP Session in iFrame in Safari and other browsers.
Is there any workaround to set third party cookie in Iframe for safari? - Stack Overflow
ios - Does the in-app Safari browser support cookies for affiliate links? - Stack Overflow

Es kann sein, das ich auch was falsch gemacht habe.

Momentan hänge ich an diesen Skripts die vielversprechend aussehen, aber da bin ich noch am Basteln… und „Fehler machen“. Safari

Bitte seid so nett und helft mir hier ein wenig weiter, ich bin mit dem JavaScript noch ein wenig auf Kriegsfuß und bastele schon seit langer Zeit an dem Problem rum.

Danke für Eure Hilfestellungen
LG Wolf

 

[mikdoe]

Measurable Wins: Safari: Setting third party iframe cookies Mein Hoster bringt einen 404 Error.

Wie lautet denn der URL, der da gebaut wird?

Es kann sein, das ich auch was falsch gemacht habe.
Bitte seid so nett und helft mir hier ein wenig weiter, ich bin mit dem JavaScript noch ein wenig auf Kriegsfuß und bastele schon seit langer Zeit an dem Problem rum.

Um welchen Code geht es denn jetzt genau? Kannst du mal eine Teststellung aufbauen, wo man testen kann und den Link hier posten?
Ganz allgemein ist das jetzt natürlich schwierig, wenn hier nur Linux und Windows User lesen.
Hast du die Frage auch mal in einem Mac oder Safari Forum gepostet, um die Reichweite zu erhöhen?

Momentan hänge ich an diesen Skripts die vielversprechend aussehen, aber da bin ich noch am Basteln… und „Fehler machen“. Safari

Bei mir funktioniert der Link nicht.

 

[th_wolfgang]

Hallo Micha,

danke

Um welchen Code geht es denn jetzt genau?

ich suche einen der Funktioniert, wenn ich wüsste welcher… Das ist das Problem.

Wie lautet denn der URL, der da gebaut wird?

Hatte lediglich vorab mal mit einer Subdomain zu Testzwecken "gespielt", da geht Anscheines nichts, muss mir jetzt eine Domain zulegen. Bin gerade dabei... Anfangs dachte ich zum Test reicht das mal…!

Hast du die Frage auch mal in einem Mac oder Safari Forum gepostet, um die Reichweite zu erhöhen?

Nein, das habe ich noch nicht, Google und suche. Es gibt einige "Hacks" / Tricks, aber einige sind für mich nicht so verständlich um dies richtig zu realisieren. Daher hoffe ich jemanden hier zu finden, der diese Problematik schon einmal auf dem Schreibtisch hatte.

Bei mir funktioniert der Link nicht.

Bei mir funktioniert der Link, aber hier noch einmal: Safari


PS: Ich teste lediglich mit dem Safari-Browser, den man unter Windows nutzen kann. Das dumme den gibt es für Win lediglich bis Version 5.1.7. Auf einem Apple-Phone oder iPad ist dieser glaub ich bereits bei Version 8.0
Danke & LG
Wolf

- - - Aktualisiert - - -

Hallo nocheinmal,

mit dieser "Spielerei" geht das schon irgendwie...:

// Check if safari
// Check if not chrome, because chrome outputs Safari*
// Check if no cookie/session is set
if (strpos($_SERVER["HTTP_USER_AGENT"], "Safari")
    && !strpos($_SERVER["HTTP_USER_AGENT"], "Chrome")) {
    if (count($_COOKIE) === 0) {
     echo "<script> 
     top.location = 'http://domainB.com/';
     </script>";
     exit(); // need to be there in order not to load the rest of the page
    }
}

ABER, da hat man dann im Browserfenster die URL des iFrames stehen, das brauche ich nicht! Da könnte man ja den iFrame auch weglassen, außerdem fehlt dann etliches der Seite, wenn man sich da die flasche - iFrame location / URL abspeichert. Wenn es aber noch eine Möglichkeit geben sollte, das die Hauptdomain im Browserfenster stehen bleibt und lediglich "im Hintergrund"... Dann wäre ich schon zufrieden!

LG & Danke
Wolf

- - - Aktualisiert - - -

im Zuge der Unendlichen suche nach einer funktionierenden "Geschichte" meines iFrame 3rd-Problemes in Safari, bin ich auf dies gestossen, kann mir dies bitte jemand verdeutlichen:

The idea of this trick is use HTML5 localStorage API. This API is very similar to cookies - it allows managing user’s preferences from javascript and storing it locally on user's box. Why not store user id in localStorage? The first version of code I came up with:

  <script type="text/javascript">
if (typeof navigator != "undefined" && typeof navigator.vendor != "undefined" &&                               navigator.vendor.indexOf("Apple") >= 0 && typeof localStorage != "undefined") {
    //Check if browser is made by Apple (means it's Safari) and local storage is available
    var userId = localStorage.getItem("user_id");
    if (userId == null) {
        //set user is if user is unknown
        userId = Math.random();
        localStorage.setItem("user_id", userId);
    }
    var img = document.createElement('img');
    img.src = "http://pixel.sample-ad-exchange.com/pixel.gif?user_id=" + user_id;
    var body = document.getElementsByTagName('body')[0];
    body.appendChild(img);
}

The idea is pretty straightforward: look for user_id key in local storage (create one if it doesn't exist) and pass user_id to pixel server as GET parameter. Then server will record this id instead firing the cookie.

But this code isn't working well. Each domain has it's own local storage. And if you tracking pixel was fired at my-cool-store.com user_id will be stored in my-cool-store.com local storage. If the same user would visit other-domain.com with tracking code later on it will be treated as new one.

To fix that old good trick with iframe will work. Instead of img tag we will insert iframe tag with source somewhere inside pixel.sample-ad-exchange.com. And place user detection code inside iframe. As iframe is executed "inside" pixel.sample-ad-exchange.com local storage will be the same for all tracked sites. Here's a complete example:

Tracking code:

<script type="text/javascript">
if (typeof navigator != "undefined" && typeof navigator.vendor != "undefined" &&       `navigator.vendor.indexOf("Apple") >= 0 && typeof localStorage != "undefined") {`
    var iframe = document.createElement('iframe');
    img.src = "http://pixel.sample-ad-exchange.com/iframe.html";
    var body = document.getElementsByTagName('body')[0];
    body.appendChild(img);
}
</script>

Iframe code (http://pixel.sample-ad-exchange.com/iframe.html)

<html>
<head></head>
  <body>
  <script type="text/javascript">
var userId = localStorage.getItem("user_id");
if (userId == null) {
    //set user is if user is unknown
    userId = Math.random();
    localStorage.setItem("user_id", userId);
}
var img = document.createElement('img');
img.src = "http://pixel.sample-ad-exchange.com/pixel.gif?user_id=" + user_id;
var body = document.getElementsByTagName('body')[0];
body.appendChild(img);
</script>
</body>
</html>

Legal issue

The interesting question is if this method is legal. Znd if next company using it will get $22.5 million fine. I'm not a lawyer, but from my common sense perspective as Safari settings explicitly says "Block thirdparty cookies from third parties and advertisers" and localStorage isn't a "cookie" the approach above seems legit.

Danke & LG
Wolf

 

[th_wolfgang]

Hallo,

sorry, aber hat den keiner eine Idee? Ich komme nicht weiter.

Danke & LG
Wolf

 

[SteelWheel]

*auch wenn ich mich hier aufgrund des Reizdarm-Begriffes "Apple" gar nicht einklinken will, denn der erzeugt bei mir ständig Sprühwurst*

Hallo.

Um es möglichst "gesund" für mich zu gestalten, meine Fragen:

1. Hast Du das Modell localStorage, was Du oben anwendungsfertig zeigst, für Deinen Fall probiert?
2. Wenn nein, warum nicht?
3. Wenn ja, wie lautet das neue Problem? (gibt Safari via vendor "Apple" raus?)

Persönlich frage ich mich, wo man sowas im legalen Bereich einsetzen würde. Denn: Ich kenne diese Technik mittels iFrame in Verbindung mit Domain-Angriffen und Weiterleitung bis zu etwas namens "another-life.r*". Da wird die Kasse auch kräftig geklingelt haben. Und wenn da schon wieder pseudo-Dollar stehen, fang ich immer an zu lachen ... also was man verdienen würde, wenn man das so macht!!!

Kernaussage ist aber wohl "Safari settings explicitly says "Block thirdparty cookies from third parties and advertisers" and localStorage isn't a "cookie"." - ich wiederhole meine eingangs gestellte Frage: Hast Du das Modell localStorage probiert?

Und meine lustigste Frage zum Schluss: Was passiert, wenn ich domainfremde Cookies nicht annehme, Apple gar nicht verwenden werde, iFrames noch weniger dulde und mich nicht blindlings irgendwie extern Durchreichen lasse?! Ich habe kürzlich meinen exklusiv vergebenen Werbeplatz mit sofortiger Wirkung eingezogen. Der Anbieter meinte dort 17 verschiedene Domains in der Welt bedienen (USA, FRA, CAN, zig Stellen in GER, ...) zu müssen. Performance, hurra ... von den ganzen untergeschobenen Cookies mal ganz abgesehen.

Magst Du mir bitte das geplante Einsatzgebiet sagen? Vielleicht kann ich das dann besser verstehen - denn was in Englisch darunter steht, erzählt eine (mir) klare Absicht.

Danke.

 

[th_wolfgang]

Hallo,
danke dass du mir behilflich sein willst, auch wenn ich deinen Sakasmuss nicht deuten kann.
Es geht mir in erster Linie um die Verwaltung mehrerer Webseiten über einen Hautserver und dessen SQL-Server, nach dem „alles unter einem Dach“ Prinzip. Um dies übersichtlich halten zu können muss ich leider ab und zu mit einer iFrame Einbindung arbeiten, diese stellt aber auch Session-Cookies bereit, diese dann als 3rd-Cookies identifiziert werden (iFrame – Problematik) und von Safari blockiert. Der Arbeitsaufwand wäre täglich zu groß, jede Seite permanent bzw. separat upzudaten. So muss ich bei einer iFrame Einbindung nur eine Seite verwalten und auf dem neusten stand halten, der iFrame erledigt bei weiteren den Rest. Verwaltungstechnisch ist es hier auch einfacher etc.. Zweite Problematik sind Links (diese wären allerdings „nicht so wichtig“ und auch das einbinden der sozialen Netzwerke etc.).

Das mit der localstorage, bekomme ich eben nicht richtig „gebacken“ ich habe da permanent 404 Errors spiele die letzten Tage damit rum, ich glaube, dass ich die URL falsch einbinde. Meine JavaScript Kenntnisse sind auch nicht gerade die besten.

Ich wäre froh, wenn mir das jemand „verdeutlichen kann“, so dass ich was lerne, meine Problematik lösen kann und mehr von dem sehr weitläufigem JavaScript, welches mir immer mehr am Herzen liegt verstehen kann. Jeder fängt mal an, so stehe ich momentan „wie das Schaf vorm Berg“.

LG & Danke
Wolf

 

[SteelWheel]

Hi,

dass Du meinen Sarkasmus nicht deuten kannst, könnte daran liegen, dass es keiner war. *g* Ich habe nur einen Abstecher in die Betriebsamkeint eines meinereiner gegeben - und woher ich das kenne und wie die Branche für Werbung etc. soll, damit pay-per-view direkt auf Anhieb auch wieder abgerechnet werden könne; es gibt kein Cookie und liegt im localStorage, was einfach immer wieder nur überschrieben wird. Jeder neue Betrachter einer Ad (oder nach zirka 60 Minuten) wird abrechnungsfähig - was wohl passiert, wenn einer von Domain 1 nach Domain 10 geleitet wird, 10x die gleiche Werbung präsent ist (bspw. Google AdSense) und nie ein Cookie gefunden werden würde. Aber das ist ja nicht meine Baustelle ... kommen wir also zu Deinem Modell, denn ich glaube Dir in puncto Ausführungen - das ist schon einmal die wichtigste Info. Nicht rumgedruckst, klingt logisch und durchaus nach "Alltag". Ich sehe zwar weitere Gefahren darin (auch für Dich bzw. Deinen Arbeitsplatz), aber wir wollen jetzt mal die Kirche im Dorf lassen oder Dich nicht noch auf gemeine Ideen bringen.

Reden wir über Deinen Source, welchen Du irgendwo ja gefunden hattest - ich übersetze es Dir möglichst zweilenweise:

if (typeof navigator != "undefined" && typeof navigator.vendor != "undefined" && navigator.vendor.indexOf("Apple") >= 0 && typeof localStorage != "undefined") {
WENN das nicht standarisierte (!) NAVIGATOR Objekt zur Verfügung steht UND in diesem Objekt etwas namens "vendor" enthalten ist, was irgendwo den Begriff "Apple" beinhaltet UND die localStorage API im Browser zur Verfügung steht ...

var userId = localStorage.getItem("user_id");
... lies genau diesen localStorage - angesprochen wird ein mögliches Element darin so wie erwartungsgem. hinterlegt!

if (userId == null) {
WENN der localStorage nicht befüllt ist, befülle diesen (zwei Folgezeilen regeln das; mittels setItem).

Der Rest setzt ein IMAGE, via JavaScript erstellt, ins BODY-Tag ein. Beachte, dass die neu generierte user_id hier angehängt wird. ABER - das steht da - ist DAS nicht zu gebrauchen, da jede Domain ihren eigenen localStorage bekommt (waren glaube ich max. 5 MB).

<script type="text/javascript">
if (typeof navigator != "undefined" && typeof navigator.vendor != "undefined" && navigator.vendor.indexOf("Apple") >= 0 && typeof localStorage != "undefined") {
    var iframe = document.createElement('iframe');
    img.src = "http://pixel.sample-ad-exchange.com/iframe.html";
    var body = document.getElementsByTagName('body')[0];
    body.appendChild(img);
}
</script>

Hinweis: Ich habe zwei Ticks (`) aus dem Code entfernt - läuft es deshalb bei Dir nicht, da falsch kopiert?

Die IF-Abfrage ist identisch - doch statt einem IMAGE wird ein Iframe gesetzt. Das Iframe wird genauso ins Body-Tag gesetzt wie zuvor das Image. BTW: waschechtes Denglisch!

Der Clou is' nu, dass durch die Einbindung des Iframes immer die gleiche Antwort erfolgt - damit lässt sich (s. Source) vielleicht (!) tatsächlich ständig das gleiche "Cookie" (es ist keines - es ist ein Eintrag im "localStorage") ausliefern (oder eine Erweiterung, dass Du autorisiert wärst).

Das Iframe kommt also in die Seiten, über die Du "Befehlsgewalt" benötigst. Die Datei, die das Iframe anspricht, liefert den Master-Cookie (wenn ich ihn so nennen kann; ist ja Weihnachtszeit) aus und stellt einen erweiterten Befehlssatz (bspw.) zur Verfügung.

Bedenke, dass Befehle rund um Iframe nur "top-down" funktionieren - Du kommst zwar von parent-dom ins Iframe via JavaScript, aber nicht aus dem Iframe ins umgebende parent-dom (also nicht umgekehrt; nur erwähnt, falls Du Befehle in die andere Richtung haben willst oder später brauchst [aka "auf dem Zettel hast"]).

Ich sehe irgendwie nicht, wie Dir das helfen könnte ... aber vielleicht gehe ich schlichtweg von anderen Einstellungen/Sicherheiten aus. Grob übersetzt, müsste Deine "Admin-Umgebung" diesen localStorage befüllen, während die Domains erfahren können, dass Du da bist bzw. getItem() verwenden und verarbeiten können. Und während ich das noch so schreibe, habe ich noch mehr "dunkle Magie" als Idee damit ...

Vergiss den Garbage Collector auf einem Server nicht, bedenke Zwangstrennungen (unbedingtes Muss in der WWW-Welt!) aus einem Login usw. Aber interessantes Thema - keine Frage!

Grüße

 

[th_wolfgang]

Hallo SteelWheel,

danke für deine sehr ausführliche Erklärung und Zeit die du investiert hast.

Ich werde es gleich einmal ausprobieren, auch wenn ich nicht alles korrekt verstanden habe. Die vom System generierten Session-Cookies gehen so aber nicht verloren, oder (parent-dom)?

Werde mal alles Schritt für Schritt abarbeiten und Updaten.

Vielen Dank & LG
Wolf

- - - Aktualisiert - - -

Hallo SteelWheel,

Ich habe den Code eingebaut, leider gehen die Session-Cookies beim Apple Safari immer noch verloren. Was habe ich hier falsch gemacht, es ist doch keine Kunst dabei, einen JavaScript-Code zu implementieren…

Evtl. kurz noch einmal, Hautserver ist z.B. DomainA.com eine Unterseite ist dann, nennen wir sie mal DomainB.com. DomainA.com wird bzw. ein Teil und auch ein Kundenbereich mit einem iFrame in DomainB.com implantiert. DomainA.com setzt Session-Cookies um z.B. den Kundenbereich überhaupt nutzen zu können. Diese Cookies werden von Safari als 3rd bzw. iFrame-Cross-Cookies erkannt und gesperrt. SQL-Server wird lediglich in DomainA.com als Hauptbereich verwaltet.

Das JavaScript habe ich auf DomainA.com eingebettet. Bei DomainB.com kommen in Safari keine Cookies an. (Andere Browser funktionieren Firefox, IE11 etc.)

Vielen Dank & LG
Wolf

 

[SteelWheel]

Dann verstehe ich Dich korrekt, dass Du indexOf() oben entfernt hast, denn das Beispiel oben soll ja explizit für Apple gewesen sein?! Ansonsten laufen die anderen Browser "irrtümlich". (was heißen würde, dass der Fehler woanders liegt)

Beim ersten Mal hab ich drüber gelesen - jetzt schmunzel ich schon wieder und erwähne es: Du meinst HauPtserver? Oder arbeitest Du tatsächlich in der Kosmetik bzw. Transplantationsmedizin? Kann ja sein ...

So, nun sagst Du, dass alle anderen Browser gehen - nur der doofe Apple-Dreck nicht ... Apple ist irgendwie überall "Vorletzter" (HTML5-Support). Der Safari-Testbrowser in meinem System kommt gerade mal auf 260 Punkte (nicht einmal die Hälfte der möglichen Punkte). Aber wieder genug gelästert über den Kram von denen, denn es hilft ja nicht weiter.

Ich kann Dir schlichtweg nicht sagen, warum Apple das nicht kann/will. Vielleicht gilt "it's not a bug - it's a feature!" - vielleicht ist es eine Einstellung im Browser selbst ... in dem kenne ich mich aber nicht aus. Vielleicht springen hier noch ein paar Apple-Jünger herum, die das beantworten könnten.

Dein jetziges Modell scheint ja funktional (in den wichtigen Browsern) - kann Safari daher unter "Kollateralschaden" fallen (= Nichtfunktion ignorieren)?

Aber solltest Du eine Lösung finden, würde es mich durchaus interessieren (sehe gerade die Safari-Nutzer bei meinem Großprojekt; immerhin 13 %, wobei nicht zu erkennen ist, ob das Mobilgeräte sind, die in Deinem Falle offenbar uninteressant scheinen).

Was bleibt Dir jetzt? Du wirst 'ne Menge alert() und console.log() brauchen, um zu erkennen, warum der Safari zickig ist. Wenn etwas nicht ankommt (woanders aber schon), kann es nur Source oder Browsersetting sein. An letztere kommst Du nicht immer heran.

Viel Erfolg weiterhin.

 

[th_wolfgang]

Hallo SteelWheel,

danke, nein in der Transplantationsmedizin bin ich nicht zuhause ... Das Problem mit dem Safari ist im Internet und diversen Foren ein weitläufiges Problem, wie ich ersehen konnte. Die Problematik hierbei ist, das Safari "von Haus aus" keine 3rd Cookies zulässt. Hierbei ist mit Sicherheit die "Erkennung des iFrames" verantwortlich. Google schon seit langer Zeit nach einer Lösung, da jeder Nutzer eines Apple (Handy / iPod / Tablet) so meine Seiten nicht nutzen kann. Leider wird die Anzahl von Handy-Internetnutzung von Tag zu Tag mehr. Aus diesem Grunde muss ich wohl eine Lösung finden.

Im Firefox funktionierte der iFrame "schon immer". Bis IE 10 konnte ich das Problem mit P3P-Headern lösen. Ab IE 11 gab es hier dann allerdings auch Probleme, diese ich mit einer Sandbox-iFrame Lösung beseitigen konnte.

sandbox=" allow-same-origin allow-forms allow-scripts allow-top-navigation"

Aber der Safari liegt mir noch quer im Magen.

Vielen Dank & LG
Wolf

 

[SteelWheel]

Du redest die ganze Zeit von Cookies. Aber das wäre es via localStorage nicht mehr. Oder ich habe eine falsche Vorstellung von dem, was da oben passiert. Das Iframe übergibt kein Cookie - das war doch eigentlich das Ziel, oder? Dann könnte Safari das 3rd-Cookie Reglement auch nicht anwenden. Denn: localStorage schreibt je Domain - daher das Iframe, was ständig die gleiche Domain anspricht und sich darüber doch die Rechte-Basis gestalten lassen sollte (Dein gefundener Source oben probiert ja was anderes, na klar! Aber vom Ablauf her wäre das doch adaptierbar).

Wenn Apple - so lese ich das von Dir - Iframes aber nun auch noch wieder ganz anders behandelt, so ist das natürlich ... moment, oben hast Du von einer Backend-Lösung geschrieben zur Verwaltung - jetzt erzählst Du von "Mobilgerätnutzern, die mehr werden". Du willst eine domainübergreifende Administrationslösung für den "casual visitor"? Amen. Bist Du sicher, dass es nicht doch was anderes wird?

Ich habe selbst gerade gar keine Zeit Dir da jetzt mit einem Prototyp unter die Arme zu greifen - bzw. es selbst "zu sehen" (zu probieren). Ich stecke gerade in einer größeren Versionsumstellung und schlage mir zu viele Stunden am Tag um die Ohren. Aber ich behalte es im Hinterkopf, falls ich mal ein wenig Luft habe.

Kurze Idee noch: Die Werbebranche verwendet ebenfalls und gern Iframes - bspw., um die Flash-Filmchen (*ätz*) laden zu können. Wie machen die das? Die Track'en ja wie die Beschmierten ... vielleicht nimmst mal Kontakt zu der Branche auf.

 

[j-l-n]

Anmerkung: Benutze in Zukunft bitte die entsprechenden Code-Tags und kennzeichne Zitate!

-Tags sind nicht zum Zitieren da![/B]

 

[SteelWheel]

Bevor der Moderator jetzt so richtig was abledert, hier eine Rückmeldung von mir ... so zwischen Lebkuchen und frischem Kaffee!

Ich habe jetzt mal ein paar Fehler aus Deinem Source oben entnommen - das kann so alles auch nicht klappen. Das hätte Dir aber jede Fehlerkonsole verraten.

So, nun habe ich hier bei mir lokal in meine Testumgebung folgendes eingebunden:

console.log(typeof navigator);
console.log(navigator.vendor);
console.log(navigator.vendor.indexOf('Apple'));
console.log(typeof localStorage);
		
// if(typeof navigator != 'undefined' && typeof navigator.vendor != 'undefined' && navigator.vendor.indexOf('Apple') >= 0 && typeof localStorage != 'undefined'){
var iframe = document.createElement('iframe');
iframe.src = "http://[LIVE-DOMAIN]/demoiframe.html";
var body = document.getElementsByTagName('body')[0];
body.appendChild(iframe);
// }

Mit den console.log()s wollte ich sehen, was mir welcher Browser zeigt bzw. sagt. Danach habe ich direkt das iframe eingebaut. Der Unterschied hier ist bereits "iframe.src"!!!

Serverseitig liegt das hier:

<html>
<head>
	<title>iFrame-Supporter</title>
</head>
<body>
	<script type="text/javascript">
	var userId = localStorage.getItem('user_id');
	if(userId == null){
		userId = Math.random();
		localStorage.setItem('user_id', userId);
	} else alert("found");
	
	var img = document.createElement('img');
	img.src = "http://[LIVE-DOMAIN]/demopixel.gif?user_id=" + userId;
	var body = document.getElementsByTagName('body')[0];
	body.appendChild(img);
	</script>
</body>
</html>

Der alert() soll zünden, wenn er den localStorage anfassen kann. Der Fehler hier war, dass userId in Deinem Beispiel fürs demopixel falsch geschrieben wurde.

Und jetzt rate, was passiert? Ich musste zwar auf meinem Server für die LIVE-Demo-Domain die htaccess kurz mal strippen (ich will da keine iFrame-Manöver; auch nicht von Google), aber alle - auch mein Safari 5.17 - meldet beim zweiten Aufruf ein "found".

JETZT gehe ich davon aus, dass ich mir meinen Lebkuchen verdient habe und Du Dir Deinen Source nochmal anschaust. Denn ...

Ich habe dann (!) den Teil mit dem iframe.src in eine andere Entwicklungsumgebung gepackt. Der Aufruf mittels FF brachte direkt "found" (korrekt!) ... und der Aufruf mit Safari? EBENFALLS! (direkt bei Erstaufruf und über verschiedene Domains hinweg)

Du bist dran ... übrigens: om nom nom nom ... der selbstgemachte Lebkuchen entschädigt via exzentrischem Feuerwerk innerhalb der Geschmacksnerven für die vorig mühseelige Arbeit!

 

[th_wolfgang]

Hallo SteelWheel,

vielen lieben Dank an dich, du machst dir „richtig Arbeit“ mit mir um mir zu helfen.

Selbstgemachte Lebkuchen gibt es bei mir leider nicht, auch bei gekauften sieht es Mau aus… Bin in Asien, wir haben momentan Erdbeerzeit, daher muss ich meinen Kaffee mit einer selbstgemachten Erdbeertorte genießen, welche auch lecker ist…

Werde deine Ausführung gleich einmal Testen, gehe ich richtig in der Annahme, dass der „erste Teil“ wie vorher“ in meine Hauptseite kommt und der Rest in die aufgerufene Seite wo der iFrame der Hauptseite dann eingebettet ist? Würde mich freuen, wenn es mit meinen Session Cookies funktioniert. Da hast du am Anfang evtl. meine Problematik falsch verstanden bzw. werde ich mich nicht richtig ausgedrückt haben. Es geht nicht um ein Backup, sondern eine einfache Verwaltung mehrerer Domains, diese durch einen Hauptserver komplett upgedatet werden können, da so lediglich alle Änderungen durch einen eingebundenen iFrame erfolgen. Dabei ist allerdings das Kundencenter auch so eingebunden um alles unter einem Hauptserver und dessen SQL verwalten zu können. Daher müssen die Session-Cookies, diese von der Hauptdomain generiert werden, auch aus dem iFrame heraus über eine zweite Domain funktionieren.

So, jetzt mach ich mich an die Arbeit, hoffe ich mache alles richtig,…

Vielen Dank & LG
Wolf

 

[SteelWheel]

Hallo erneut,

der erste Teil ist der Teil, den Du in den Domains benötigst, welche Du verwalten willst - quasi der Abholer der Adminbedingungen.

Der zweite Teil liegt an der Stelle, welche die Adminbedingungen verwaltet und liefert die Information für den Client aus.

Grüße nach Asien.

 

[th_wolfgang]

Hallo SteelWheel,

vielen lieben Danke,

leider geht es auch so nicht, der Kundenbereich, erhält keine Cookies übertragen… Kundenbereich kann so nicht genutzt werden. Oben in der Seite nach einem Aufruf dieser steht folgendes: body.appendChild(iframe)://} Aber dies nur bei Safari! Im IE11 kommt oben auch der Code in der Webseite zur Ansicht, das Kundencenter funktioniert allerdings. Schade und dass vor Weihnachten /:

Habe mit der Variante noch einmal gespielt, funktioniert aber leider auch nicht... Evtl. habe ich ja einen Asia-Ghost im Rechner, vielleicht sollte ich mal zu Buddha

http://measurablewins.gregjxn.com/2014/02/safari-setting-third-party-iframe.html

Bitte sei so nett und schaust noch einmal nach

Vielen Dank & LG
Wolf

 

[SteelWheel]

Buddha würde Dir sagen, dass Dein KungFu nicht stark genug ist, Du aber genügend Zeit für Training und Lehre aufbringen musst.

body.appendChild(iframe)://} sagt mir (!), dass :// da nicht hingehört ... ! Auch ist die Aussage "geht nicht" immer so und zu pauschal. Geht es nicht mit dem Smartphone? Reden wir über Safari als Desktop-Browser? Denn nur den habe ich genommen (da als armer Coder schlichtweg keine Mittel für diesen neumodischen NSA-Scheiß zur Verfügung stehen - *und irgendwo lacht Buddha*).

Ich habe Dir das gegeben, womit ich Erfolg hatte - ich hoffe, dass Du auf Screenshots der alert()-Meldung verzichtest (Video würde auch gehen, aber ... neee, dann ist mein Kaffee wieder kalt).

Mit Deinem Link auf den Block kann ich hingegen nichts anfangen (darüber sind wir hinaus).

Checke also mal die Herkunft von :// - das ist mit Sicherheit falsch!

Sayonara (verdammt, japanisch!)

 

[th_wolfgang]

Hallo SteelWheel,

vielen lieben Danke,

ja ja, wo dass her kommt "://" kann ich auch nicht ersehen. Ich habe es auch, da ich kein Apple besitze mit dem Desktop Safari 5.1.7 versucht. Leider ist das Ergebnis genau wie vorher. Hier muss ich nichts anpassen iframe.src = "http://[LIVE-DOMAIN]/demoiframe.html"; oder?

Kann es sein, wegen dem P3P-Header, den ich noch drin habe? Glaube ich allerdings jetzt nicht... Ich werde den mal rausnehmen und es noch einmal versuchen. Wenn es bei dir geht, muss es „ja an was liegen“...

...und Buddah lacht... mich aus :/

Vielen Dank & LG
Wolf

 

[SteelWheel]

*offtopic* Buddha lacht niemanden aus - er ist zwar ein fröhliches Kerlchen gewesen, aber eher auf Vermittlung, Weisheit und Rat getrimmt. Guter Mann ... solche fehlen heute in der Welt sehr spürbar. */offtopic*

Du solltest [LIVE-DOMAIN] natürlich ersetzen! Das erwähne ich nur, falls es Dir jetzt nicht sooo klar scheint. Und auch die .html muss bei Dir nicht zwingend genauso heißen - sollte übrigens auch 'nen 200er Status liefern, wenn man danach sucht.

Ich habe keinen P3P-Header verwendet - hatte nur temporär aus meiner htaccess was entfernt. Steht der Eintrag drin, geht es bei mir natürlich auch nicht. Inwiefern Deine Ziel-Domains also diesen Eintrag manuell setzen (weil der Webmaster 'ne ähnliche Paranoia pflegt wie ich), ist ein unlösbares (!) Problem. Denn dann geht es natürlich nicht. Wäre ja auch schlimm, wenn es dann immer noch gehen würde ... !!!

Aber bis Du :// gefunden hast, gönne ich mir einen größeren Becher Kaffee ... mein Monster-Upgrade ist nämlich fertig, was ich im Oktober startete. Und das ist "leider geil"!

 

[th_wolfgang]

Hallo SteelWheel,
vielen lieben Danke,

freut mich das dein „Monster“ funktioniert!
ich habe die .htaccess weg, den P3P-Header entfernt. Leider geht es immer noch nicht… :/ Kaffee, auch ein grösser hilft da nicht, jedenfalls bei mir nicht. Da muss ich wohl oder übel ein Bier, zum Frust runterspülen aufmachen… Das „://“ kann ich auch leider nicht finden, erscheint aber nur, wenn ich den Code implantiert habe… komisch :/

LG & Danke
Wolf