- Registriert
- 11. Dez. 2010
- Beiträge
- 5.430
- Punkte
- 448
- XF Version
- 2.2.15
- XF Instanz
- Hosting
- PHP-Version
- 8.2.x
- MySQL/MariaDB
- 10.3.x
- Provider/Hoster
- Strato/Hetzner
Ich versuch mich mal in Erklärung...
Zeitlicher ungefährer Verlauf:
Die meisten Browser, auch Firefox (bis Version 76) haben das fehlen, des SameSite Attributes Anfangs gar nicht beachtet und später so gewertet, als wäre das Attribut "lax" (dt. locker) gesetzt.
Mit Version 77 des Firefox wurde dann erstmals Ernst und der Browser wertete das nicht gesetzte SameSite Attribut als Problem und reagierte entsprechend mit Problemen beim Loggin/Logout auf manchen Seiten/Foren.
Nun kam bei mir noch hinzu, das ich php-Dateien einen Cache Header mit gegeben hatte. Das, kombiniert mit dem SameSite Dilemma des Firefox führte zu Anfangs schwer nachvollziehbarem Verhalten des Browsers beim Besuch meiner Foren.
Da der Verdacht zuerst auf die Cookies und das SameSite Attribut fiel und Xenforo keinen Bock hat, dies für den 1.5.x Zweig noch nach zu reichen per Patch - erstellte @Boothby lobenswerter Weise einen Hack/Patch für Xenforo 1.5.x der eben dieses SameSite Attribut endlich setzt und dem Fall konkret nicht "lax" sondern "strict", was sich heut nun bei meinen Foren als Problem heraus kristalisierte.
Nach einigem lesen und Versuchen mit der Einstellung "lax" statt "strict" beim Hack zeigt sich, das vielleicht "lax" die bessere Vorgabe beim Hack von Boothby wäre, weil zwar etwas weniger sicher wie "strict" aber in Sachen usability besser und gleichzeitig sicherer als "none" bzw. nicht gesetzt.
Der Artikel war am Ende recht hilfreich:
Aktuell geht wieder alles wie es soll, dynamische PHP Dateien werden nicht mehr zwangsweise gecached und Boothby's Hack läuft mit Samesite = lax jetzt bestens.
Zwei Mini-Problemchen, aber in Kombination erstmal voll doof.
Zeitlicher ungefährer Verlauf:
Die meisten Browser, auch Firefox (bis Version 76) haben das fehlen, des SameSite Attributes Anfangs gar nicht beachtet und später so gewertet, als wäre das Attribut "lax" (dt. locker) gesetzt.
Mit Version 77 des Firefox wurde dann erstmals Ernst und der Browser wertete das nicht gesetzte SameSite Attribut als Problem und reagierte entsprechend mit Problemen beim Loggin/Logout auf manchen Seiten/Foren.
Nun kam bei mir noch hinzu, das ich php-Dateien einen Cache Header mit gegeben hatte. Das, kombiniert mit dem SameSite Dilemma des Firefox führte zu Anfangs schwer nachvollziehbarem Verhalten des Browsers beim Besuch meiner Foren.
Da der Verdacht zuerst auf die Cookies und das SameSite Attribut fiel und Xenforo keinen Bock hat, dies für den 1.5.x Zweig noch nach zu reichen per Patch - erstellte @Boothby lobenswerter Weise einen Hack/Patch für Xenforo 1.5.x der eben dieses SameSite Attribut endlich setzt und dem Fall konkret nicht "lax" sondern "strict", was sich heut nun bei meinen Foren als Problem heraus kristalisierte.
Nach einigem lesen und Versuchen mit der Einstellung "lax" statt "strict" beim Hack zeigt sich, das vielleicht "lax" die bessere Vorgabe beim Hack von Boothby wäre, weil zwar etwas weniger sicher wie "strict" aber in Sachen usability besser und gleichzeitig sicherer als "none" bzw. nicht gesetzt.
Der Artikel war am Ende recht hilfreich:
Aktuell geht wieder alles wie es soll, dynamische PHP Dateien werden nicht mehr zwangsweise gecached und Boothby's Hack läuft mit Samesite = lax jetzt bestens.
Zwei Mini-Problemchen, aber in Kombination erstmal voll doof.
