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. > > 1. 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](https://stackoverflow.com/questions/64023550/sessions-are-not-working-when-the-site-is-called-by-an-iframe/65216475#65216475) und [hier](https://stackoverflow.com/questions/64023550/sessions-are-not-working-when-the-site-is-called-by-an-iframe/65216475#65216475) 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...

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. > > 1. 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](https://stackoverflow.com/questions/64023550/sessions-are-not-working-when-the-site-is-called-by-an-iframe/65216475#65216475) 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...