Contao Shared Cache immer "miss" wegen Session Cookie

[betatester]

Hallo,
Ich muss voraus werfen, ich finde ganz allgemein - auch abseits von Eclipse - den Contao Seitencache bzw. Shard-Cache ein Drama. Es gelingt immer schwerer das Ding zum Cachen von Seiten zu bringen. Ein falsches Cookie und es wird nichts.

Jedenfalls schaffe ich es mit einer Eclipse Seite grad wieder nicht, Contao hier zum Seiten Cachen zu bewegen. Es kommen keinerlei andere Erweiterungen zum Einsatz. Der Shared Cache ist auf 7 tage eingestellt, da es keine User bezogenen Inhalte gibt, habe ich auch den Haken "immer aus dem Shared Cache laden" rein gemacht. Trotzdem wird stets die Seite frisch gerendert und ich sehe in den http Headern

Contao-Private-Response-Reason: session-cookie
Contao-Cache: miss

Es wird auch tatsächlich immer ein PHPSESSID Cookie gesetzt, aber mit dem müsste Contao ja eigentlich zurecht kommen. Ansonsten wird noch das csrf_https-contao_csrf_token Cookie gesetzt, das wars dann aber auch schon.

Kennt jemand noch Tricks um Contao mit Eclipse zum Seiten Cachen zu bewegen?

[Tim]

Hi,
EX nutzt keine Cookies, sondern ausschließlich den localstorage.

csrf_https-contao_csrf_token ist glaube ich der neue Request Token. Sobald Du quasi ein Formular auf der Seite hast, wird der benötigt und von Contao gesetzt. PHPSESSION ist halt PHP. Du kannst Cookies gezielt erlauben:
https://docs.contao.org/manual/de/pe...kie-allow-list

Soweit ich mich erinnern kann greift der Seitencache auch nur, wenn du nicht am Backend angemeldet bist und auch nicht im Debug-Modus bist.

[tschero]

Moin,

die PHPSESSID und das csrf_https-contao_csrf_token werden immer erzeugt wenn Du im BE angemeldet bist.
Beim normalen Betrieb der Seite sind die beiden Cookies standardmäßig nicht immer gesetzt.
Nachvollziehbar in der Contao Official Demo.
https://demo.contao.org/contao/

Grüße

[betatester]

Ist mir soweit alles klar.
Aber irgendwas oder irgendwer macht eine PHP Session auf, die zu dem Session-Cookie führt und somit das Caching behindert. Contao selbst ist meiner Meinung nach nicht. Das kann man bei einer Vanilla Contao Installation oder auch auf https://demo.contao.org/ schön sehen, hier wird keinerlei Session-Cookie (PHPSESSID) gesetzt.

[betatester]

tschero, unsere Postings inklusive Hinweis auf Contao Demo haben sich überschnitten ;-)

Ich hab das jetzt mehrmals kontrolliert. Ich bin im Contao Backend definitiv abgemeldet. Ich starte Browser dennoch sicherheitshalber zur Gänze neu. Ich surfe auf das Frontend - PHPSESSID Cookie und csrf sind wieder da...
Es ist auch keinerlei Formular auf der Seite platziert.

[Tim]

Ist mir soweit alles klar.
Aber irgendwas oder irgendwer macht eine PHP Session auf, die zu dem Session-Cookie führt und somit das Caching behindert. Contao selbst ist meiner Meinung nach nicht. Das kann man bei einer Vanilla Contao Installation oder auch auf https://demo.contao.org/ schön sehen, hier wird keinerlei Session-Cookie (PHPSESSID) gesetzt.

Du kannst die Cookies in die Whitelist packen und gut. Im Contao Handbuch findest du sogar eine copy and paste Zeile exakt für die Contao-eigenen Cookies.

[betatester]

So funktioniert die Whitelist aber meines Wissens nicht und ich halte das für eines der größten Missverständisse, was im Contao Forum hunderte Leute stundenlang beschäftigt hat mit dem Thema.
Die Whitelist legt fest, welche Cookies definitiv bei der Applikation ANKOMMEN sollen. Damit verhindert man das Caching als erst recht.

https://community.contao.org/de/show...he-und-Cookies
https://contao.org/de/news/die-jagd-...essige-cookies

[Tim]

Ich hab die Defaul-Demo mal schnell in den Seitencache gepackt. Die Contao-eigenen Cookies, die hier aufgrund von Formularen gesetzt werden, unterbinden den Seitencache nicht. Ich habe keine Whitelist definiert.

Der Header gibt miss/store als Rückantwort. Was korrekt ist. Die Seite existiert noch nicht und wird abgelegt. Ein Reload bringt die Antwort fresh. -> Seite kommt aus dem Cache.
https://docs.contao.org/manual/de/pe...r-shared-proxy

Das muss andere Gründe bei Dir haben. Zeig mal die Seite.

[betatester]

Ja, über ein miss/store wär ich schon mal glücklich
Danke für Dein Angebot die Seite zu sichten. Ich bin unsicher ob mein Kunde mit der Veröffentlichung hier einversanden wäre, ich schicke Dir per Privatnachricht.

[betatester]

Ganz allgemein findet man ja sehr widersprüchliche Angaben ob die PHPSESSID nun das Caching blockiert oder nicht.
Ich hab mir mal so ein Session File direkt am Webserver angesehen. Also da findet man schon Hinweise auf "PCT_THEMEDESIGNER_eclipse_doctor", und auch auf den Revolutionslider, der offenbar auch Dinge in einer PHP Session speichert.

Ein frisch installiertes Contao ohne irgendwelche Themes oder Erweiterungen öffnet jetzt rein vom Frontend her offenbar keine PHP Session.

[Tim]

Der ThemeDesigner nutzt natürlich die Session, wenn du damit arbeitest. Aber nicht, wenn du damit fertig bist. Gleiches gilt für das Frontend Editing.

Ein frisch installiertes Contao ohne irgendwelche Themes oder Erweiterungen öffnet jetzt rein vom Frontend her offenbar keine PHP Session.

Stimmt nicht so ganz. Das ganze Thema ist inhaltsabhängig / vom Aufbau der finalen Seite abhängig. Wenn Du auf deiner rohen Contao Seite ein Kontaktformular platzierst, hast du auch wieder deine Cookies. Die Cookies unterbinden das Caching meines Erachtens nicht, wenn die Checkbox "Immer aus dem Shared-Cache laden" aktiv ist, sonst könnte man mit Contao keine Seite bauen, auf der ein Formular zum Einsatz kommt und die im Cache liegen soll. Kann ja sein man hat eine Startseite mit Kontaktformular oder Anfrageformular

Auf das Theme bezogen benötigt das Optin-System ein Formular, damit in einem sicheren POST-Request die Auswahlen des Benutzers protokolliert in einer Datei abgelegt werden können. Das gibt Rechtssicherheit und ist Pflicht gegenüber der DSGVO.

[betatester]

Der ThemeDesigner ist definitv nicht aktiv.
Mein Ansatz war ja jetzt nur mal in das session File am Server unter /tmp rein zu schauen, um Hinweise zu finden wo die Session überhaupt her kommt. Da sah ich eben Fragmente wie

_sf2_meta|a:3:{s:1:"u";i:1718104853;s:1:"c";i:1718104636;s:1:"l";i:0;}PCT_THEMEDESIGNER_eclipse_doctor|a:0:{}_sf2_attributes|a:4: 

[betatester]

Ich hab jetzt nochmal eine isolierte Sitzung in einem privaten Browserfenser gemacht. Das Session File unter /tmp enthält dann ausschließlich

_sf2_meta|a:3:{s:1:"u";i:1718112884;s:1:"c";i:1718 112870;s:1:"l";i:0;}PCT_THEMEDESIGNER_eclipse_doct or|a:0:{} 

Wer öffnet diese Session?

[Tim]

Ich hab jetzt nochmal eine isolierte Sitzung in einem privaten Browserfenser gemacht. Das Session File unter /tmp enthält dann ausschließlich

_sf2_meta|a:3:{s:1:"u";i:1718112884;s:1:"c";i:1718 112870;s:1:"l";i:0;}PCT_THEMEDESIGNER_eclipse_doct or|a:0:{} 

Wer öffnet diese Session?

Die Session wird vom Optin-Formular geöffnet, oben erklärt. Du kopierst hier Session-Daten, die dann aktiv werden, wenn du wieder am TD arbeiten solltest.
Darüber hinaus verhindert dass ja den Cache nicht.

EX5.x
Hier zu sehen (4.13): https://dev4-13.premium-contao-themes.com/home-107.html
Und hier zu sehen (5.3): http://trial.premium-contao-themes.com/home-107.html

(ich kann die Seite nicht lange so halten, weil es Entwicklungsumgebungen sind).

Aber ich bin ganz bei Dir. Das gesamte SharedCache-System ist ne Wunderkiste. Ich hab rohe Seiten, die wollen grad auch nicht. Andere, identischer Aufbau, passen wie oben. Ich bau mir lokal mal eine direkte Testumgebung, mal schauen...

[Tim]

So, ich habe jetzt sukzessiv jede Erweiterung Stück für Stück deaktiviert und aktiviert. Ich denke ich habe einen Verdacht bzw. den Übeltäter: Google Fonts.

Ich habe hier eine Installation ohne Datenschutz-Optin. Damit wir alle vorherigen Komponenten prüfen können.

Wenn der ThemeDesigner die gewünschten Schriften extern laden soll, startet PHP bzw, der Browser einen Session Prozess bei mir. Das autom. Laden kann in den Systemeinstellungen deaktiviert werden (empfohlen auch gegenüber der dsgvo).
https://service.premium-contao-theme...nts-lokal.html

Mach das mal bitte und leere deinen Browser zum Test.