nicht angemeldet klawischnigg
Felix Riesterer
Rolf B
klawischnigg
Rolf B
klawischnigg
Rolf B
klawischnigg
klawischnigg
Rolf B
klawischnigg
Rolf B
Hi there,
ich hab folgendes Problem:
ich binde in eine Anwendung externe JS-Dateien, die zT. serverseitig genererierten Inhalt haben ein. Das klappt auch problemlos. Eingebunden wird mit:
JürgenB<script src="unterverzeichnis/javascriptdatei.js.php" type="text/javascript"></script>
Leider muß die Anwendung auf Kundenwunsch nun in einem Iframe (der von einer anderen Domain geladen wird) laufen. Und da machen die jüngsten Chrome-Browser leider Zicken und geben in der JS-Console eine Fehlermeldung "Failed to load resource: the server responded with a status of 500 (internal server error)" aus. "Reine" JS-Dateien werden übrigens problemlos geladen.
Es hat klarerweise etwas mit "same-origin"-etc. zu tun, aber ich finde über dieses spezielle Problem leider nichts. (Dem Firefox ist das übrigens völlig wurscht, bei dem funktionierts problemlos, ebenso bei älteren Chrome-Browsern). Das Weiterreichen der $_SESSION-Variable hat auch Probleme (selbe Ursache, selbe Browser) gemacht, aber das konnte ich mit diversen Cookie-Einstellungen in der php.ini-Konfigurationsdatei lösen. Aber da steh' ich jetzt im Walde - hat jemand eine Idee oder mit dem gleichen Problem kämpfend selbiges gelöst?
Lieber klawischnigg,
Dein PHP-Script sollte die generierte JS-Datei mit passenden Headern versenden:
protected function allow_cross_origin_ajax () {
header('Access-Control-Allow-Headers: *');
header('Access-Control-Allow-Methods: GET, POST');
header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Credentials: true');
}
Liebe Grüße
Felix Riesterer
Hi there,
Dein PHP-Script sollte die generierte JS-Datei mit passenden Headern versenden:
Danke, aber leider nein. Das funktioniert nicht. Ausserdem hat das mit Ajax eigentlich nichts zu tun, ich schreib' damit lediglich mit PHP erzeugten Content in Javascript-Variablen...
Lieber klawischnigg,
Danke, aber leider nein. Das funktioniert nicht.
warum nicht? Fehlermeldungen...?
Ausserdem hat das mit Ajax eigentlich nichts zu tun, ich schreib' damit lediglich mit PHP erzeugten Content in Javascript-Variablen...
Ich habe nur "mal eben schnell" die Methode in meinem PHP-Projekt gesucht, mit der ich die ausgelieferten JavaScripte CORS-kompatibel mache. Und damit habe ich jetzt keine Same-Origin-Probleme mehr.
Liebe Grüße
Felix Riesterer
Hi there,
Danke, aber leider nein. Das funktioniert nicht.
warum nicht? Fehlermeldungen...?
Die gleiche wie vorher. Interner Server Error 500, resource kann nicht geladen wird (jetzt einmal im verschiedenen Sprachen-Kauderwelsch😉)
Ausserdem hat das mit Ajax eigentlich nichts zu tun, ich schreib' damit lediglich mit PHP erzeugten Content in Javascript-Variablen...
Ich habe nur "mal eben schnell" die Methode in meinem PHP-Projekt gesucht, mit der ich die ausgelieferten JavaScripte CORS-kompatibel mache. Und damit habe ich jetzt keine Same-Origin-Probleme mehr.
Ja eh, man muß eh alles probieren. Ich tüftle halt weiter, wenn ich eine Lösung finde, dann poste ich sie selbstverständlich...
Lieber klawischnigg,
Die gleiche wie vorher. Interner Server Error 500, resource kann nicht geladen wird (jetzt einmal im verschiedenen Sprachen-Kauderwelsch😉)
also ein Syntax-Fehler. Im Fehlerlog sagt Dir PHP genau was dazu?
Ja eh, man muß eh alles probieren. Ich tüftle halt weiter, wenn ich eine Lösung finde, dann poste ich sie selbstverständlich...
Wie wäre es, wenn Du einfach alles Wesentliche hier postest? Error-Log wäre so ein Ding, wo man einen ganzen Tag vertun kann, weil man herumprobiert, anstatt den Fehler nachzuschlagen.
Mich beschleicht der Verdacht, dass Du meinen Code schlicht mit copy&paste in Deinen hineingeklatscht hast. Das Schlüsselwort protected zeigt ja, dass die Funktionsdefinition aus einer Klasse stammt. Wenn Du jetzt aber keine Objektschreibweise nutzt... Du sagst ja nicht viel zu dem, was Du hast! Da muss man wohl aufhören, Dir zu helfen.
Liebe Grüße
Felix Riesterer
Hi there,
Mich beschleicht der Verdacht, dass Du meinen Code schlicht mit copy&paste in Deinen hineingeklatscht hast.
Geklatscht hat's nicht, das war ziemlich geräuschlos.
Das Schlüsselwort protected zeigt ja, dass die Funktionsdefinition aus einer Klasse stammt.
Ich hab nur den Inhalt der Funktion "hineingeklatscht".
Wenn Du jetzt aber keine Objektschreibweise nutzt... Du sagst ja nicht viel zu dem, was Du hast!
Ich hab das alles im Dialog mit Rolf B erötert und erläutert. Ich hab' gedacht, Du liest dort vielleicht mit.
Da muss man wohl aufhören, Dir zu helfen.
???
Hallo klawischnigg,
Du sagst ja nicht viel zu dem, was Du hast! Da muss man wohl aufhören, Dir zu helfen.
Teil 1 stimme ich zu. Ich fand es auch recht schwierig, mit den Informationen auszukommen, die Du gegeben hast. Da Du aber ein erfahrender Forenteilnehmer bist, bin ich davon ausgegangen, dass die Umstände Dir nicht mehr ermöglicht haben. Das, und nur das, hat mich von Felix' Schlussfolgerung abgehalten.
Rolf
Hi there,
Du sagst ja nicht viel zu dem, was Du hast! Da muss man wohl aufhören, Dir zu helfen.
Teil 1 stimme ich zu. Ich fand es auch recht schwierig, mit den Informationen auszukommen, die Du gegeben hast.
Ja, tut leid. Aber viel mehr Info hatte ich zunächst nicht, weil ich zunächst auch nicht erkannt habe, wie die diversen Phänomene zusammenhängen. Da war Dein Anstoß ja durchaus hilfreich...;)
Hallo klawischnigg,
nur zur Sicherheit: wird der iframe mit sandbox-Attribut erstellt?
"Reine" JS-Dateien werden übrigens problemlos geladen.
Es hat klarerweise etwas mit "same-origin"-etc. zu tun
Das würde zu Felix Aussage passen. MDN schreibt:
The Access-Control-Allow-Headers response header is used in response to a preflight request which includes the Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request.
Und ein preflight request ist ein OPTIONS Request, also kein GET oder POST, und es ist natürlich gut möglich, dass da wegen des iframe ein Preflight gemacht wird und dein Server oder dein PHP Script mit dem OPTIONS Request nicht klar kommt. Oder PHP als Handler für dieses Verb nicht eingerichtet ist. Das sollte sich aber aus dem Text der HTTP 500 Meldung oder dem Server-Log ergeben. Wenn es ein OPTIONS Request ist, musst Du den wohl entsprechend behandeln. Ich weiß nicht, ob es sinnvoll ist, die Header prinzipiell zu setzen.
Rolf
Hi there,
nur zur Sicherheit: wird der iframe mit sandbox-Attribut erstellt?
Nein
Und ein preflight request ist ein OPTIONS Request, also kein GET oder POST, und es ist natürlich gut möglich, dass da wegen des iframe ein Preflight gemacht wird und dein Server oder dein PHP Script mit dem OPTIONS Request nicht klar kommt. Oder PHP als Handler für dieses Verb nicht eingerichtet ist. Das sollte sich aber aus dem Text der HTTP 500 Meldung oder dem Server-Log ergeben. Wenn es ein OPTIONS Request ist, musst Du den wohl entsprechend behandeln. Ich weiß nicht, ob es sinnvoll ist, die Header prinzipiell zu setzen.
Naja, der Server sagt: "GET /common/functions.js.php HTTP/1.1" 500
scheint also doch ein GET zu sein - nichtsdestotrotz haben die header-Anweisungen von Felix leider nichts geholfen...
Hallo klawischnigg,
Naja, der Server sagt: "GET /common/functions.js.php HTTP/1.1" 500
nirgendwo ein error Log mit mehr details? Auf diese Weise kommst Du - glaub ich - kaum zu einer Lösung. Irgendwo muss ein Fehlergrund stehen, entweder im Netzwerk-Trace des Browsers, auf der Leitung (->Wireshark & Co) oder im Log des Webservers oder von PHP.
Du könntest mal experimentieren: Mach einen iframe und lade darin nicht die HTML Seite, sondern /common/functions.js.php. Vielleicht stehen da noch PHP Responses drin. Die könnte man im PHP auch noch aufdrehen.
Rolf
Hi there,
nirgendwo ein error Log mit mehr details? Auf diese Weise kommst Du - glaub ich - kaum zu einer Lösung. Irgendwo muss ein Fehlergrund stehen, entweder im Netzwerk-Trace des Browsers, auf der Leitung (->Wireshark & Co) oder im Log des Webservers oder von PHP.
Tja, kurioserweise erfahr ich im Network-Trace, wie lange das Laden der Resource gedauert hat, die er nicht laden kann. (Argghhhh...)
Ausserdem erfahr ich dort, daß die Header von Felix geladen wurden, und, was vermutlich im Zusammenhang mit meinem Problem interessanter ist:
Unter Request-Headers:
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
Ob die Referrer Policy damit was zu tun hat? Keine Ahnung, der Wert ist jedenfalls "strict-origin-when-cross-origin"...
Du könntest mal experimentieren: Mach einen iframe und lade darin nicht die HTML Seite, sondern /common/functions.js.php. Vielleicht stehen da noch PHP Responses drin. Die könnte man im PHP auch noch aufdrehen.
Ja, same procedure, mit einem Http 500-Error, das Dokument functions.js.php wird genauso behandelt wie das Skript...
Hallo klawischnigg,
mom, die Header kommen an? D.h. das Script ist angelaufen, hat die Header gesetzt und ist dann abgeraucht.
Kling doch prima. Wenn Du keine Logdatei hast, dann hau ein paar "Bin bei Position Xy" echos rein und mach nach jedem echo ein flush(), damit es nicht in irgendeinem Buffer verschrumpelt wenn der HTTP 500 zuschlägt. Die sollten sich dann in der Response finden.
Rolf
Hi there,
mom, die Header kommen an? D.h. das Script ist angelaufen, hat die Header gesetzt und ist dann abgeraucht.
Immerhin hab ich jetzt dank Deines Vorschlags herausgefunden, wo das Teil "abraucht" (beim Aufruf einer bestimmten PHP-Funktion), auch wenn mir die Ursache jetzt unklarer ist als zuvor (weil das mit der Geschichte oberflächlich betrachtet absolut nichts zu tun hat.) Anyway, ich muß das weiter analysieren, werd' schon noch draufkommen, irgendwas muß ich übersehen haben...
Hi there,
Immerhin hab ich jetzt dank Deines Vorschlags herausgefunden, wo das Teil "abraucht" (beim Aufruf einer bestimmten PHP-Funktion)...
Ok, ich bin draufgekommen - es geht nicht um eine "bestimmte" PHP-Funktion, sondern es geht um irgendeinen Syntax- oder sonstigen PHP-Fehler. Keine Ahnung warum, aber wenn die Anwendung in einem domainfremden Iframe läuft, dann reagiert PHP viel pikierter auf Errors und dadurch diese Lade- und sonstigen Fehler. Das im Hinterkopfe und die Headeranweisungen von Felix und die Geschichte sollte funktionieren. Dank an alle damit Befassten...
Hallo klawischnigg,
Keine Ahnung warum, aber wenn die Anwendung in einem domainfremden Iframe läuft, dann reagiert PHP viel pikierter auf Errors und dadurch diese Lade- und sonstigen Fehler.
Das ist jetzt deine Beobachtung, aber gestatte bitte trotzdem, dass ich da Zweifel habe. Die konkrete Ursache muss anders geartet sein. Der Server weiß nur sehr begrenzt etwas davon, ob der Request aus einem nackigen Browserfenster, einem iframe, einem frame, einem Ajax-Request oder einen wget-Aufruf kommt.
Was beim Server ankommt, ist ein HTTP Request. Das ist ein Stück Text. Es besteht aus einer Verb-Zeile (GET /common/functions.js.php HTTP/1.1), gefolgt von Header-Zeilen. Die Header können sich natürlich je Browser und je Browsing Context unterscheiden.
Aber das sich deswegen bestimmte Konstrukte von PHP anders verhalten sollten?! Das wäre merkwürdig. Kannst Du die Request-Header zwischen Aufruf im Hauptfenster und Aufruf im iframe vergleichen?
Wenn Du keine Zeit dafür hast - auch gut. Kann ich verstehen.
Rolf
Hi there,
Keine Ahnung warum, aber wenn die Anwendung in einem domainfremden Iframe läuft, dann reagiert PHP viel pikierter auf Errors und dadurch diese Lade- und sonstigen Fehler.
Das ist jetzt deine Beobachtung, aber gestatte bitte trotzdem, dass ich da Zweifel habe.
Ich glaub's ja selbst nicht. Wahrscheinlich war's auch nicht so. Ich denke, ich hab das nur scheinbar "repariert", in dem ich einem nicht bekannten $_SESSION-Index einen default-Wert gegeben habe (der dann eine PHP-Datei includen kann, deren Name vom Wert dieser Variablen abhängt; oder, um es weniger kryptisch zu machen, wenn zB $_SESSION['lang'] den Wert 'de' hat, dann ladet das Skript die Datei "../languages/lang_de.inc.php".
Das eigentliche Problem aber ist, daß dieser Wert eigentlich nie leer sein darf; daß er es trotzdem ist, ist die eigentlich Folge des cors-Problems, das damit noch immer nicht gelöst wurde (ich weiß wie das zu lösen ist, aber das Problem ist, daß in dem Fall beide Server (also der Hauptseite und dem, was im Iframe läuft) nicht unter meiner Verwaltung stehen und der Entwickler der Rahmenseite gemeint hat, er hätte die Geschichte mit dem Iframe und dem Session-Cookie auf seine Weise gelöst (was er aber offenbar nicht hat)
Die konkrete Ursache muss anders geartet sein. Der Server weiß nur sehr begrenzt etwas davon, ob der Request aus einem nackigen Browserfenster, einem iframe, einem frame, einem Ajax-Request oder einen wget-Aufruf kommt.
Du hast ja soo recht, aber immerhin, über Deine Überlegungen bin ich auf die eigentliche Ursache gekommen, auch wenn mir jetzt bewußt ist, daß die Baustelle ein viel größere ist und meine "Lösung" so sinnvoll und wirksam ist wie eine Decapitation bei Kopfschmerzen...
Hallo klawischnigg,
hast Du in deinem script-Request überhaupt eine Session? Oder fehlt der Session-Cookie? Das würde erklären, weshalb der Session-Eintrag fehlt. Kannst Du gegen den Targetserver überhaupt debuggen oder hast Du irgendeinen Hanswurst vor Ort, dem Du immer sagen musst: Probier mal dies, probier mal das - und der denkt nur daran, ob sein Bleistift orthogonal zur Spacetaste liegt und gut gespitzt ist? Während er den Stundenzeiger auf dem Weg zur 5 beobachtet?
Rolf
Hi there,
hast Du in deinem script-Request überhaupt eine Session? Oder fehlt der Session-Cookie?
Nein, nein, das ist schon alles da. Theoretisch;). Aber es gibt da mit der Session Probleme, wenn die Anwendung in einem Iframe läuft, der nicht der Server der "Rahmenseite" ist. Das kann man durch bestimmte Einstellungen in der PHP.ini lösen, (Voraussetzung, beide Server nutzen das https-Protokoll, ohne gehts gar nicht; das trifft auf alle Chrome-basierten Browser zu) - nur - die Schwierigkeiten damit hab ich eh schon im vorigen Posting erwähnt.
Kannst Du gegen den Targetserver überhaupt debuggen oder hast Du irgendeinen Hanswurst vor Ort, dem Du immer sagen musst: Probier mal dies, probier mal das - und der denkt nur daran, ob sein Bleistift orthogonal zur Spacetaste liegt und gut gespitzt ist? Während er den Stundenzeiger auf dem Weg zur 5 beobachtet?
Ganz so schlimm ist es nicht, aber im Prinzip sprichst Du eine große Wahrheit ganz gelassen aus...😉
Lieber klawischnigg,
Theoretisch;). Aber es gibt da mit der Session Probleme, wenn die Anwendung in einem Iframe läuft, der nicht der Server der "Rahmenseite" ist.
lass mich das mal etwas auseinander dröseln.
Nun meine Fragen:
zu 1.) Welche Debug-Ausgaben hast Du in Deinem Script getätigt, um die unterschiedliche Reaktion auf die Session hin zu prüfen? Inwiefern wirkt es sich auf den Request an Dein Script aus, wenn es in einem Frame einer anderen Seite eingebettet ist? Schaust Du auf den Referrer? Wenn ja, wie/wo/warum?
zu 2.) Woher nimmt sich das Script die Werte in der Session? Sind diese an URL-Parameter oder POST-Werte gebunden, die bei der Einbettung in den Frame fehlen?
zu 3.) Die Session wird in aller Regel über Cookies gelöst. Da im Frame Dein Script im Rahmen Deiner üblichen Domain aufgerufen wird, sollte das zugehörige Cookie erreichbar sein. Und selbst wenn nicht, so kann doch wieder ein neues angelegt werden, das an Deine Domain geknüpft gilt. Oder läuft die Einbettung auf anderem Wege (irgendwelche Proxy-Scripte), die Dein Script eben genau nicht "wie sonst üblich" im Rahmen Deiner Domain aufrufen?
Das kann man durch bestimmte Einstellungen in der PHP.ini lösen, (Voraussetzung, beide Server nutzen das https-Protokoll, ohne gehts gar nicht; das trifft auf alle Chrome-basierten Browser zu) - nur - die Schwierigkeiten damit hab ich eh schon im vorigen Posting erwähnt.
Das klingt für mich gerade nach einer Portion Buchstabensuppe. Die Vokabeln kenne ich natürlich alle, aber ihr Zusammenhang wirkt wie völlig verdreht.
In der PHP.ini kannst Du grundsätzliches Scriptverhalten einstellen, ja. Das habt aber rein überhaupt nichts damit zu tun, was Aufrufe innerhalb von Frames betrifft, weil im Frame ein eigenes Dokument liegt, welches sich wie ein übliches Browserfenster sonst auch Dein Script als Resource lädt. Da ist technisch kein Unterschied (es sei denn da tunnelt etwas herum). Inwiefern ein Google-Browser hier spezielle Extrawürste auffährt, um vermeintliche zusätzliche Sicherheit zu erreichen, kann ich nicht abschätzen oder sagen, da ich ausschließlich mit dem Feuerfuchs entwickle. Im Chromium tut's dann so gut wie immer auch.
Liebe Grüße
Felix Riesterer
Hi there,
Theoretisch;). Aber es gibt da mit der Session Probleme, wenn die Anwendung in einem Iframe läuft, der nicht der Server der "Rahmenseite" ist.
lass mich das mal etwas auseinander dröseln.
- Du stellst (nur) Vermutungen an, was Du mit dem Wort "theoretisch" formulierst.
Keineswegs. Das war die Folge der mit der Version 80 von Chrome erfolgten "SameSite Cookie Änderung". Das Wort "theoretisch" in dem Zusammenhang ist einer rhetorischen Laune geschuldet. Das habe ich auch durchaus erwähnt (ohne die Versionsnummer von Chrome explizit zu nennen), daß das vorher anders war und Firefox davon nicht betroffen ist, ich sehe da nicht wirklich viel "Vermutungen".
Nun meine Fragen:
zu 1.) Welche Debug-Ausgaben hast Du in Deinem Script getätigt, um die unterschiedliche Reaktion auf die Session hin zu prüfen?
Abgefragt, ob der Inhalt der $_SESSION-Variable und davon abgeleiteten Variablen bekannt sind?
Schaust Du auf den Referrer? Wenn ja, wie/wo/warum?
Nein, wozu? Es geht um eine Webapplikation, nicht um eine Seite, die von hüben und drüben angesprungen wird
zu 2.) Woher nimmt sich das Script die Werte in der Session? Sind diese an URL-Parameter oder POST-Werte gebunden, die bei der Einbettung in den Frame fehlen?
Die Werte kommen von einer Login-Seite. Aber um die überhaupt zu sehen, muß die Session schon funktionieren und (leere) Werte enthalten.
zu 3.) Die Session wird in aller Regel über Cookies gelöst. Da im Frame Dein Script im Rahmen Deiner üblichen Domain aufgerufen wird, sollte das zugehörige Cookie erreichbar sein.
Eben nicht. Das PHPSESSID-Cookie wird nicht gesetzt.
Das kann man durch bestimmte Einstellungen in der PHP.ini lösen, (Voraussetzung, beide Server nutzen das https-Protokoll, ohne gehts gar nicht; das trifft auf alle Chrome-basierten Browser zu) - nur - die Schwierigkeiten damit hab ich eh schon im vorigen Posting erwähnt.
Das klingt für mich gerade nach einer Portion Buchstabensuppe. Die Vokabeln kenne ich natürlich alle, aber ihr Zusammenhang wirkt wie völlig verdreht.
Wie konkret und asuführlich hättest Du es gerne? Das Verhalten (und mögliche Lösungen) wird hier und hier gut und detailliert erörtert.
In der PHP.ini kannst Du grundsätzliches Scriptverhalten einstellen, ja. Das habt aber rein überhaupt nichts damit zu tun, was Aufrufe innerhalb von Frames betrifft, weil im Frame ein eigenes Dokument liegt, welches sich wie ein übliches Browserfenster sonst auch Dein Script als Resource lädt.
Da sind wir jetzt wieder bei der Theorie. Die Praxis (siehe oben erwähnte Stackoverflow-Seite) sagt etwas andere.
Da ist technisch kein Unterschied (es sei denn da tunnelt etwas herum). Inwiefern ein Google-Browser hier spezielle Extrawürste auffährt, um vermeintliche zusätzliche Sicherheit zu erreichen, kann ich nicht abschätzen oder sagen, da ich ausschließlich mit dem Feuerfuchs entwickle.
Aha?
Im Chromium tut's dann so gut wie immer auch.
Nein, das betrifft alle auf Chromium basierenden Browser. Also auch den Edge und den Opera und den Chromium selbst.
Ich habe, um das abzuschliessen, das Besondere an meiner Situation ja erklärt. Wenn ich auf den Servern könnte, wie ich wollte, und an der Situation hätte etwas ändern können, dann wäre dieser Thread überhaupt nie entstanden. Weil ich aber nicht einmal Zugang zu allen Logs habe, habe ich mir gedacht, ich frag' halt einmal hier an, ob's dazu "Ideen" gibt. Wenn ich gewußt hätte, daß ich da eine halbwissenschaftliche Abhandlung dazu schreiben muß - ach was, lassen wir's bleiben...ich danke anyway trotzdem noch einmal allen, die sich damit beschäftigt haben...
Lieber klawischnigg,
Das Verhalten (und mögliche Lösungen) wird hier und hier gut und detailliert erörtert.
also ist es ein Chrome-Problem, das alle davon abgeleiteten Browser ebenfalls betrifft. Irgendwie muss es sich ja mal rächen, wenn Browserhersteller sich zusammentun und unter der Haube nur noch ein Browser werkelt. Bin so froh, dass es den Firefox noch gibt. Das muss so bleiben, weil sonst Browser=Chrome mit der Vielfalt im Web nichts mehr zu tun hat.
da ich ausschließlich mit dem Feuerfuchs entwickle.
Aha?
Im Chromium tut's dann so gut wie immer auch.
Nein, das betrifft alle auf Chromium basierenden Browser. Also auch den Edge und den Opera und den Chromium selbst.
Ja, das von Dir geschilderte Problem hätte ich mit Chromium dann auch. Üblicherweise geht es mir um CSS und JS und wie das dann außerhalb des Firefox aussieht und funktioniert.
Ich habe, um das abzuschliessen, das Besondere an meiner Situation ja erklärt. Wenn ich auf den Servern könnte, wie ich wollte, und an der Situation hätte etwas ändern können, dann wäre dieser Thread überhaupt nie entstanden.
OK. Auch ich habe jetzt endlich kapiert, was genau Dein Problem ist. Zugegeben, war ein Stück Arbeit.
Weil ich aber nicht einmal Zugang zu allen Logs habe, habe ich mir gedacht, ich frag' halt einmal hier an, ob's dazu "Ideen" gibt.
Hoffentlich wirst Du wenigstens sehr gut dafür bezahlt! Unter diesen Voraussetzungen arbeiten zu müssen ist sehr unbefriedigend und zeitraubend. Das sollte man Dir entsprechend vergüten.
Wenn ich gewußt hätte, daß ich da eine halbwissenschaftliche Abhandlung dazu schreiben muß - ach was, lassen wir's bleiben...ich danke anyway trotzdem noch einmal allen, die sich damit beschäftigt haben...
Jedenfalls alles Gute!
Liebe Grüße
Felix Riesterer
Hallo klawischnigg,
danke für den Problemhinweis. Das hatte ich mal irgendwann gelesen, aber nicht im Kopf behalten.
Ich versuche es nochmal mit eigenen Worten zu schildern, um zu prüfen, ob ich das Problem jetzt verstanden habe. Der hier hat mir sehr dabei geholfen.
Ich war erstmal verwirrt, weil ich dachte, dass deine /index.php (oder wie auch immer) eine Session erzeugt, die aber beim Abruf der /content/dingsbums.js.php nicht mehr da ist. Das darf aber durch SameSite selbst in einem iframe nicht beeinflusst werden, weil das ein first-party Zugriff ist. Oder?
Anders ist es mit dem Laden des iframe. SameSite=Lax überträgt Cookies nur noch in genau zwei Fällen: beim direkten Navigieren zur Seite, und beim Verzweigen zur Seite über ein Form mit method="get". Ein Form zu einer fremden Domain posten, eine fremde Domain iframen, Ajax-Gets und sogar das Laden von Bildern von einer Fremddomain überträgt Lax-Cookies nicht mehr. Und das bedeutet: Wenn da eine gespeicherte Session war, dann ist sie für deine /index.php bereits nicht mehr vorhanden. Und das würde dann erklären, warum sie auch der .js.php fehlt.
Stimmt das so?
Felix,
nach dem, was ich jetzt gelernt habe, ist das kein Chromia-Bug, sondern eine Trödelei im Firefox! Die Spec wurde nämlich geändert, und SameSite=Lax ist der neue Default. Die Chromia setzen das um, Firefox zockelt hinterher.
Rolf
Hi there,
Ich versuche es nochmal mit eigenen Worten zu schildern, um zu prüfen, ob ich das Problem jetzt verstanden habe. Der hier hat mir sehr dabei geholfen.
Ja. Ich wollte eigentlich diese Seite posten, hab dann aber versehentlich zweimal die, wie ich meine, eher unbedeutendere zu diesem Thema gepostet, wie ich bemerkt habe. Da ist das jedenfalls noch einmal sehr detailliert angeführt und beschrieben.
Ich war erstmal verwirrt, weil ich dachte, dass deine /index.php (oder wie auch immer) eine Session erzeugt, die aber beim Abruf der /content/dingsbums.js.php nicht mehr da ist. Das darf aber durch SameSite selbst in einem iframe nicht beeinflusst werden, weil das ein first-party Zugriff ist. Oder?
ja, aber so ist es. Ich greif nicht auf eine Session von ausserhalb zu (ich weiß nicht einmal, ob da so etwas existiert; "ausserhalb", das ist irgendeine Wordpress-Seite, mit der ich zum Glück nichts zu tun habe), der first-party-Zugriff innerhalb des Iframes funktioniert nicht. Ich hab damit zum Glück nur mittelbar zu tun, es war ursprünglich nie die Rede davon, daß das in einem Frame laufen soll - gleichwohl hab ich natürlich Interesse daran, daß das einigermaßen funktioniert.
Anders ist es mit dem Laden des iframe. SameSite=Lax überträgt Cookies nur noch in genau zwei Fällen: beim direkten Navigieren zur Seite, und beim Verzweigen zur Seite über ein Form mit method="get". Ein Form zu einer fremden Domain posten, eine fremde Domain iframen, Ajax-Gets und sogar das Laden von Bildern von einer Fremddomain überträgt Lax-Cookies nicht mehr. Und das bedeutet: Wenn da eine gespeicherte Session war, dann ist sie für deine /index.php bereits nicht mehr vorhanden. Und das würde dann erklären, warum sie auch der .js.php fehlt.
Stimmt das so?
Also für mich siehts eher so aus, als dürfte nur die "top"-Seite überhaupt cookies setzen. Eigentlich müßte bereits die PHP-Funktion session_start() ein PHPSESSID-Cookie setzen, das passiert aber definitiv nicht im Iframe. Die EditThisCookie-Erweiterung vom Chromium sagt definitiv "No cookies here!". Logisch wäre ja, daß man innerhalb des Iframes machen kann, was man will, aber so ist es leider nicht. Ich könnte ja einmal probieren, ob ich irgendwelche Cookies setzen kann. Übrigens wird das ziemlich eng gesehen, vom Browser; ich hab intern ein paar Webserver laufen, und da tritt der Effekt schon auf, wenn ein Skript vom Server 10.0.0.xx1 in einem Iframe von Server 10.0.0.xx2 laufen soll.
nach dem, was ich jetzt gelernt habe, ist das kein Chromia-Bug, sondern eine Trödelei im Firefox! Die Spec wurde nämlich geändert, und SameSite=Lax ist der neue Default. Die Chromia setzen das um, Firefox zockelt hinterher.
Ja, so hab ich das auch verstanden.
Hallo klawischnigg,
Also für mich siehts eher so aus, als dürfte nur die "top"-Seite überhaupt cookies setzen.
Ich habe das gerade mal nachzuvollziehen versucht.
Eine test.html, die eine kleine PHP Seite iframed. Und die PHP Seite möchte einen Cookie ohne SameSite Attribut setzen.
Tatsächlich meldet das Netzwerktab von Chrome bei der Set-Cookie Response der PHP Seite schon sehr ausführlich:
This Set-Cookie didn't specify a "SameSite" attribute and was defaulted to "SameSite=Lax", and was blocked because it came from a cross-site response which was not the response to a to-level navigation. The Set-Cookie had to have been set with "SameSite=None" to enable cross-site usage.
Und das passiert auch, wenn ich innerhalb des iframes einem Link dorthin folge. Inhalt eines iframe ist also tatsächlich niemals top-level Navigation, und das macht das Leben im iframe deutlich schwerer...
Weiteres herumspielen braucht https und das scheitert bei mir an einem tief verwurzelten Unverständnis der Zertifikatswissenschaften, so dass ich außerstande bin, auf meinem eigenen Windows Computer ein selbstsigniertes Zertifikat so zu erstellen, dass Chrome es akzeptiert.
Rolf
Hallo klawischnigg,
Weiteres herumspielen braucht https und das scheitert bei mir an einem tief verwurzelten Unverständnis der Zertifikatswissenschaften,
Ha! Wer sagt denn, dass Marmelade keine Kräfte gibt? Eigenzertifikat läuft jetzt doch.
Also für mich siehts eher so aus, als dürfte nur die "top"-Seite überhaupt cookies setzen.
Kann ich jetzt für den Fall bestätigen, dass SameSite auf Lax steht. Für "None", zusammen mit "Secure", geht es. Das blöde ist nur, dass man auf diese Weise die Sicherheit wieder loswird, die der SameSite-Schalter eigentlich bringen sollte. Es bräuchte eigentlich sowas wie "trusted parents".
Rolf
Hallo,
das ganze ist die Reaktion von Google darauf, dass das <google>-Element nicht in die HTML-Spezifikation aufgenommen wurde. In Zukunft wird man mit iFrames nur noch Google-Maps und YouTube-Videos einbinden können. 😀
Gruß
Jürgen