Ressourcen-Icon

XF1.x Cookie SameSite Support 1.0

Keine Rechte zum Download
Indirekt ja, denn es geht ja um schlecht konfigurierte WebServer. :) Ich hab ein Vorschlag gemacht, der geht aus Gründen nicht. Ist ja OK, dann geht es anders weiter.

Hat die Änderung denn etwas gebracht?
 
Hi,

Zeit, Zeit, Zeit, ...

Ich hab am We noch mal kurz (zu kurz) den kompletten Umschwung auf nginx probiert, aber da brauch ich def. noch mal mehr Zeit um Sachen aus der dann unnötigen htaccess zu nginx zu konvertieren. Das ist mal was für ne Saure Gurken Zeit und ob nun nginx, nginx+apache oder nur apache - so oder so sollte der FF ja nicht allein deswegen Zicken machen.

Ich hab n paar Dinge geändert, z.B. die Cache-betreffenden Sachen aus der nginx Konfiguration raus genommen, dort gibts nur noch die Dinge zum packen (gzip). Keine Änderung bei FF - daran lags also nicht.

@Hoffi
Was ist bez. htaccess zu bemängeln? Ich mein, außer das da viel drin ist, es geht ja vermutlich um ein Cache-Problem im Zusammenspiel mit FF und ich find ums verrecken nicht den exakten Grund.

Frage, wo/wie hast du dir die Cache Sachen meiner Seite anzeigen lassen um die Dopplungen zu finden?
Auf das hier: XF1.x - Cookie SameSite Support warst du so richtig leider nicht eingegangen.

Ich werde am WE mal testweise ne nackig gemachte minimal htaccess setzen und dann mit dem FF mal wieder testen, testen, testen...

Nochmal zum Verständnis, an den Foren/Server wurde nichts geändert, seit vielen Monaten (außer Updates, aber keine Konfig-Änderungen) und dann gabs das leidige FF Update und seither gibts Probleme mit dem FF. Wenn ich wüsste was sich da in Bezug auf die Probleme bei meinen Foren geändert hat, dann wüsste ich vielleicht auch besser, wo ich genauer suchen muss. :(
 
Ok, ich habs nu doch gefunden und das war auch noch echt banal...

Code:
## BEGIN Cache-Control Headers (Sekunden)
# 86.400 = 1 Tag, 604.800 = 1 Woche, 2.500.000 = über 1 Monat, 31.500.000 = über 1 Jahr
<ifmodule mod_headers.c>
<filesmatch "\\.(ico|jpe?g|png|gif|swf|apng)$">
Header set Cache-Control "max-age=31500000, public"
</filesmatch>
<filesmatch "\\.(css)$">
Header set Cache-Control "max-age=2500000, public"
</filesmatch>
<filesmatch "\\.(js)$">
Header set Cache-Control "max-age=2500000, private"
</filesmatch>
<filesmatch "\\.(x?html?|php)$">
Header set Cache-Control "max-age=60, private, must-revalidate"
</filesmatch>
</ifmodule>

zu
Code:
## BEGIN Cache-Control Headers (Sekunden)
# 86.400 = 1 Tag, 604.800 = 1 Woche, 2.500.000 = über 1 Monat, 31.500.000 = über 1 Jahr
<ifmodule mod_headers.c>
<filesmatch "\\.(ico|jpe?g|png|gif|swf|apng)$">
Header set Cache-Control "max-age=31500000, public"
</filesmatch>
<filesmatch "\\.(css)$">
Header set Cache-Control "max-age=2500000, public"
</filesmatch>
<filesmatch "\\.(js)$">
Header set Cache-Control "max-age=2500000, private"
</filesmatch>
<filesmatch "\\.(x?html?)$">
Header set Cache-Control "max-age=60, private, must-revalidate"
</filesmatch>
</ifmodule>

geändert, also mal testweise das php caching (letztes filesmatch) raus genommen, und schmupps geht auch FF wieder wie er sollte.


Dennoch: was hat man im FF geändert, das es seit v77 ein Problem ist, bisher gabs damit keine Probleme und auch der Chrome kann mit dem cachen von php Dateien gescheit umgehen, wie es FF bis v 76 ja auch konnte... :kap::unknown::ungeduldig:

Hätte must-revalidate nicht eigentlich reichen müssen? Oder ist es das, dass der FF dies ignoriert seit v77 ?
 
Das Cache-Control dürfte aus der htaccess kommen, das andere, muss ich mal schauen... melde mich. Danke!

Die .htaccess solltest du nur spärlich verwenden, z.B. für WordpressSachen.
Alles was den Webserver und Nginx für die jeweilige Domain betrifft solltest du mit Plesk hier plazieren: "Einstellungen für Apache und Nginx". Das ist dann auch performanter weil das vor der .htaccess abgearbeitet wird und im RAM vorgehalten wird.
upload_2020-9-17_8-6-3.png

upload_2020-9-17_8-19-16.png

Plesk ist schon eine feine Sache, fast so gut wie CPanel, nur weit günstiger. Allerdings sollte man seine Möglichkeiten auch nutzen ;) und es auf dem aktuellsten Stand halten.
 
Zuletzt bearbeitet:
Wie kommst du drauf, das mein Plesk nicht aktuell sei? :unknown:

Mir ist durchaus bewusst das die htaccess Performance Probleme bietet. Das es nun aber, wenn man sie eh noch brauch, nen riesen Unterschied macht, ob die etwas voller ist oder nur noch das dort notwendige enthält, ist mir noch nicht geläufig gewesen. Ja Wordpress ist da ein Thema, aber auch ein paar Sachen daneben.
Mit nem freien Tag und Muse tu ich mir das mal an und bereinige die mittlerweile steinalten htaccess Dateien oder schau wo ich komplett auf htaccess und Apache verzichten kann.


Zurück zum Thema - der FF tut es wieder, wie erste Tester berichten. Das zuvor funktionierende cachen von php Dateien scheint seit v77 beim FF Probleme zu machen, das war mir bis gestern nicht bekannt, funktionierte ja zuvor auch anstandslos.
Seit php Dateien vom Cache ausgenommen wurden, geht es jetzt jedenfalls auch mit FF wieder.
 
Boothby hat eine neue Ressource erstellt:

Cookie SameSite Support - Cookie SameSite Support



Weitere Informationen zu dieser Ressource...
Ich hab eventuell noch n Problem mit dem Hack gefunden - zumindest ein merkwürdiges Verhalten, wieder nur FireFox betreffend:

Wenn ich z.B. in einem Tab hobby-gartenteich.de aufrufe, mich anmelde, und dann beliebige Seiteninterne Links mit "öffnen im neuen Tab" öffne bin ich auch in den anderen Tabs noch angemeldet angezeigt.

Wenn ich aber, z.B. in einem Tab hobby-gartenteich.de aufrufe, mich anmelde, und dann aber einfach nen neuen leeren Tan im gleichen FF Browser aufmache, dann dort per Hand oder kopierten Link hobby-gartenteich.de öffne, dann bin ich in diesem Tab nicht eingeloggt, im ursprünglichen aber schon.

Ist reproduzierbar, auch von mehreren anderen Nutzern mit FireFox Browser.

Da die meisten meinen, das sei seit ca. 2 Wochen, fällt das in das Zeitfenster wo ich den Hack bez. SameSite eingebaut habe. @Boothby kannst du das mal versuchen zu reproduzieren? Ich lass bis morgen Abend den Hack mal noch bei meiner Gartenteichseite drin, damit andere darüber testen können. Danach würde ich den testhalber mal raus bauen wollen.
 
Ich vermute mal, (bin nun doch schon am Testen...) das es hieran liegt:

Der Eintrag in der Config (Auszug):
Code:
'samesite' => 'strict'

Hab zum Thema "strict", "lax" oder "none" hier einen netten Beitrag gefunden, der das von mir zuvor geschilderte Verhalten mAn. ein Stück weit erklärt:
SameSite Cookies - Strict, oder soll es doch lieber Lax sein?
(bis in die Mitte scrollen zum Punkt "strict oder lax?"

Wenn ich nicht daneben liege, sollte es mit lax das beobachtete Verhalten nicht geben und alles gewohnt funktionieren.

... allerdings, unter Einbuße eines Stückchens Sicherheit. Wobei immer noch besser lax als none ;)
 
Zurück
Oben