Contao Cache immer "private", kein public/shared Cache möglich?

Ich habe das Problem, das Contao 4.8.4 nie! den Public/Shared Cache füllt. (Lokale Installation mit Apache)
Um alle Störenfriede auszuschließen, habe ich ein Layout angelegt wo nur ein Artikel definiert ist und dort eine leere Seite. (mit Privat 5 Sekunden und Shared 30 Minuten)
Damit ist also nichts drin was das ganze beeinflussen könnte, trotzdem immer "private" und "miss".

Code:

---

Cache-Control: max-age=5, private, s-maxage=1800
Contao-Cache: miss
Vary: Accept-Encoding

---

Jemand ne Idee?

Nachtrag: nein ich teste das nicht mit F5 oder Reload, ich klicke zwischen zwei leeren Seiten immer hin und her.

Was mich wundert, wenn ich Private Cache auf 0 setze, kommt:

Code:

---

Cache-Control: private, s-maxage=1800
Contao-Cache: miss

---

Es werden auch keine html Seiten im Cache abgelegt, nur kleine ~35 Byte kleine Dateien die mit HTML nichts zu tun haben.


Nachtrag: Es werden keine Cookies mitgesendet.

Jetzt wird es seltsam. Ich mache mit wget auf Kommandozeile die Testaufrufe und habe EventListener/MakeResponsePrivateListener.php dabei debuggt.
Hier wird setPrivate() bei mir aufgerufen:

Code:

---

        // 1) An Authorization header is present
        if ($request->headers->has('Authorization')) {
            $response->setPrivate();

            return;
        }

---

https://github.com/contao/core-bundl...stener.php#L45

Warum wird hier eine Authorization festgestellt? Das ist doch falsch, oder?

Versuch mal, im Browser explizit alle Cookies für diese Domain zu löschen.

Alles schon getestet. Wenn ich per wget teste, da gibt es keine Cookies oder ähnliches.

Aber, die Ursache ist bei mir die .htaccess die Contao mitbringt!
Die Zeilen:

Code:

---

    # Sets the HTTP_AUTHORIZATION header removed by Apache
    RewriteCond %{HTTP:Authorization} .
    RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

---

setzten den Header, obwohl der gar nicht gesetzt sein sollte, da er keinen Inhalt hat.

Kommentiere ich die beiden Zeilen aus ist alles OK, es wird gecached.

Ich habe einen PR auf GitGub gefunden, da wurde auch bei Symfony drauf hingewiesen (in der ServerBag.php als Kommentar)
https://github.com/symfony/symfony/pull/3551/files

Dort wurde nur eine Zeile erwähnt:

Code:

---

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

---

Damit funktioniert es bei mir.

Später wurde das auf zwei Zeilen angepasst (zumindest bei mir aktuell in der ServerBag.php)

Code:

---

RewriteCond %{HTTP:Authorization} ^(.+)$
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

---

Damit funktioniert es nicht mehr bei mir.

Damit hätten wir nun also drei Varianten wovon eine zumindest bei mir funktioniert bzw. durch löschen der Zeilen aus der .htaccess.
Nachteile habe ich bisher nicht feststellen können.

Leider nur die halbe Miete.
Lokal mit COD funktioniert das, auf meinem Server reicht das nicht, da scheinen die Header gesetzt zu sein ob ich will oder nicht.
Also will ich nicht, daher habe ich in der index.php zu Anfang reingesetzt:

Code:

---

if (isset($_SERVER['HTTP_AUTHORIZATION']) && (strlen($_SERVER['HTTP_AUTHORIZATION']) == 0))
{
    unset($_SERVER['HTTP_AUTHORIZATION']);
}

---

Das ist natürlich nicht updatesicher, klaro, aber erstmal geht es (bei mir).

Ich habe exakt das gleiche Problem. Bei mir hat auch nur die Anpassung der index.php geholfen. Gibt es zu dem Problem schon ein Ticket?

Poste mal eure .htaccess bzw. nginx config

Bei mir hatte das Problem mit einer ungünstigen nginx-Konfiguration bei Timme Hosting zu tun.

Warum finde ich das jetzt erst. Zwei Stunden gegrübelt was ich falsch mache, den gesamten Vortrag von Toflar nochmal angeschaut. Jetzt vermute ich mal, dass mir der nginx-Proxy von Webgo da in die Suppe spuckt. Sehr ärgerlich so kurz vor Weihnachten, wo ich doch schon dachte, das Caching funktioniert bei mir jetzt so wie es soll. Cookies werden keine mitgeschickt.
Bei mir sieht der Response-Header momentan so aus:

Code:

---

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 24 Dec 2019 00:50:27 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: max-age=3600, private, s-maxage=28237
vary: Cookie
x-content-type-options: nosniff
referrer-policy: no-referrer-when-downgrade, strict-origin-when-cross-origin
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
x-content-digest: en165e1a47cf3598a5f7e4d67c299e6093effb365ea0e5012a5c026a09be8d3198
Age: 24637
Contao-Cache: fresh
Content-Encoding: gzip

---

Das Verhalten ist so, dass wenn ich den Public Cache lösche, erst mal alles zu funktionieren scheint, deswegen habe ich das auch erst spät gemerkt. Ich lösche den Servercache, danach rufe ich die Seite aus, rufe per Navigation eine andere Seite auf und gehe dann per Navigation wieder auf die erste Seite. Dann wird mir von Firefox angezeigt, dass das HTML aus dem Browsercache kommt. Also scheinbar alles gut. Aber dann warte ich eine längere Zeit und bekomme dann sowas wie den Response-Header oben und Firefox zeigt mir an, dass das HTML runtergeladen wurde. Immer noch ok, sofern ich länger warte als für den private Cache eingestellt. Aber dann müsste er doch eigentlich nach mehrmaligem hin- und hernavigieren zwischen den Seiten doch das frisch vom Server geladene HTML wieder frisch im Browsercache haben und beim nächsten Mal das HTML wieder aus dem Browsercache laden. Das passiert aber nicht, er lädt es jedes Mal wieder neu vom Server. Leider geht Toflar in seinem Vortrag nur sehr kurz auf den private Cache ein. Verständlich, weil eigentlich nicht seine Baustelle. Muss ich wohl morgen mal mit den Tipps hier im Thread experimentieren, falls das Problem nicht schon jemand vor mir gehabt hat bei Webgo und eine Lösung parat hat.

Zitat:

---

Zitat von webstar

Bei mir hatte das Problem mit einer ungünstigen nginx-Konfiguration bei Timme Hosting zu tun.

---

was genau war das Problem? Ich habe auch nginx laufen

Ich nutze aktuell die 4.9.2 mit Marketing Suite (https://github.com/numero2/contao-marketing-suite). Habe auch eine .env im root-Verzeichnis angelegt:

Code:

---

COOKIE_WHITELIST=PHPSESSID,csrf_https-contao_csrf_token,cms_cookies,cms_cookies_saved

---

bekomme jedoch immer nur:

contao-cache: miss

Poste einen Link zur Seite.

Bist du dir sicher, dass die COOKIE_WHITELIST so stimmt? So eine Einstellung würde bedeuten, dass die Seite nie aus dem Cache kommt, wenn ein Cookie namens cms_cookie oder cms_cookies_saved vorhanden ist. Wenn aber die Marketing Suite anhand dieser Cookies andere Inhalte ausgibt, dann bleibt dir aber eh nichts anderes über und kannst den Cache somit auch nicht nutzen.

den Link darf ich leider nicht posten.

https://youtu.be/VU4JmsmF99Y?t=1803
Ich habe es so verstanden, dass systemrelevante Cookies in die .env eingetragen werden sollen.

Wie genau wird das denn dann geregelt? Also ich habe z.B nur eine Seite mit einem YouTube Video, welches erst angezeigt wird wenn die Cookies akzeptiert wurden, aber alle anderen Seiten bleiben, vom Markup her, gleich

Zitat:

---

Zitat von typomat

den Link darf ich leider nicht posten.

https://youtu.be/VU4JmsmF99Y?t=1803
Ich habe es so verstanden, dass systemrelevante Cookies in die .env eingetragen werden sollen.

Wie genau wird das denn dann geregelt? Also ich habe z.B nur eine Seite mit einem YouTube Video, welches erst angezeigt wird wenn die Cookies akzeptiert wurden, aber alle anderen Seiten bleiben, vom Markup her, gleich

---

Dann muss der Cache leider überall deaktiviert bleiben, weil der Cache weiß ja nicht auf welcher Seite das Cookie relevant ist. Zumindest kann man ihn nicht so detailliert konfigurieren. Du müsstest es wenn dann umgekehrt machen: die entsprechenden Cooklies aus der WHITELIST entfernen und den Cache auf der Seite, wo die Cookies relevant sind, in der Seitenstruktur deaktivieren.

ich habe jetzt bei dieser einen Seite das Caching deaktiviert und auch die .env wieder entfernt.

bei einer Seite die gecachet werden sollte bekomme ich immer nur das:

Code:

---

cache-control: max-age=86400, private, s-maxage=259200
contao-cache: miss

---

Ja, weil du die .env entfernt hast ;). Jetzt verursacht das Cookie weiterhin, dass die Seite nie aus dem Cache kommt. Du musst entweder

• die entsprechenden Cookies, die für den Cache ignoriert werden sollen, in die Blacklist eintragen,
• oder die entsprechenden Cookies, die für den Cache nicht ignoriert werden dürfen, in die Whitelist eintragen.

Siehe https://docs.contao.org/dev/referenc...anaged-edition

ich habe nun wieder die .env angelegt ;)

Code:

---

COOKIE_WHITELIST=PHPSESSID,csrf_https-contao_csrf_token

---

oder

Code:

---

COOKIE_WHITELIST=PHPSESSID,csrf_https-contao_csrf_token,cms_cookies,cms_cookies_saved

---

macht bisher keinen Unterschied.

Alle Cookies lösche ich immer. Beim Aufrufen der Seite die gecachet werden soll, bekomme ich aber immer nur
contao-cache: miss

Ja, wenn dann muss es

Code:

---

COOKIE_WHITELIST=PHPSESSID,csrf_https-contao_csrf_token

---

sein.

Zitat:

---

Zitat von typomat

Alle Cookies lösche ich immer. Beim Aufrufen der Seite die gecachet werden soll, bekomme ich aber immer nur
contao-cache: miss

---

Hast du überprüft, ob eines er Cookies der Whitelist gesetzt wird? Wenn ja, kommt die Seite nicht aus dem Cache.

Ja PHPSESSID und csrf_https-contao_csrf_token werden immer gesetzt und nach dem akzeptieren der Cookies sind auch cms_cookies und cms_cookies_saved immer gesetzt

Zitat:

---

Zitat von typomat

Ja PHPSESSID und csrf_https-contao_csrf_token werden immer gesetzt

---

Dann startet dein eigener Code oder eine Extension irgendwo die Session, vermutlich - und es befindet sich ein Formular auf der Seite.

Zitat:

---

Zitat von Spooky

Dann startet dein eigener Code oder eine Extension irgendwo die Session, vermutlich - und es befindet sich ein Formular auf der Seite.

---

Das kommt von der Marketing Suite. Die MS wird aber für die Opt-In Einstellungen benötigt.

Kennt jemand eine andere (funktionierende) Lösung für die Opt-In Einstellungen als die Marketing Suite mit der auch der Cache genutzt werden kann?

Schreibe es als Feedback an die Marketing Suite, dass das nicht mit Cookies gelöst werden sollte.

Zitat:

---

Zitat von Spooky

Schreibe es als Feedback an die Marketing Suite, dass das nicht mit Cookies gelöst werden sollte.

---

Antwort von numero2 zusammengefasst:
- Thema Caching haben sie grundsätzlich im Auge
- Das Anliegen mit den Cookies kommt auf die Agenda

Ich versuche hier gerade eine Installation (Contao 4.9.2) zu schützen per .htaccess und .htpasswd. Dazu habe ich eine entsprechende .htaccess ins Installationsverzeichnis gelegt.

Code:

---

AuthType Basic
AuthName "Bitte melden Sie sich an, Bla bla bla"
AuthUserFile /var/www/vhosts/hosting136630.a2e46.netcup.net/websites/.htpasswd
require valid-user

---

Das funktioniert soweit auf den ersten Blick auch, sowohl im Frontend als im Backend. Allerdings wird dadurch das Cookie csrf_https-contao_csrf_token gesetzt, was wiederum dazu führt, dass serverseitig nichts gecached wird im public/shared Cache. Wie kommt der Apache auf die blöde Idee, das mit dem selben Cookie zu realisieren, mit dem Contao z.B. seine Formulare schützt? Ich kann das Token ja jetzt schlecht auf die Blacklist setzen. Obwohl ... ich habe gar kein Formular auf der Website ;). Kann ich das dann sicher auf die Blacklist setzen bzw nicht in eine Whitelist aufnehmen, so dass der Zugriffsschutz erhalten bleibt aber der Contao-Cache funktioniert? Oder kann ich irgendwie erreichen, dass für den Zugriffsschutz ein anderes, separates Cookie verwendet wird und nicht ausgerechnet das CSRF-Token Cookie?

Ohne die .htaccess klappt das übrigens mit dem public/shared Cache soweit ich das beurteilen kann :rolleyes:.

Siehe die Beschreibung von COOKIE_WHITELIST hier: https://docs.contao.org/dev/reference/config/

Caching ist von Haus aus deaktiviert, wenn ein Authorization Header vorhanden ist. Und das CSRF Cookie wird automatisch gesetzt, wenn ein Authorization Header vorhanden ist: https://docs.contao.org/dev/framework/request-tokens/

Schade, ich verzichte dann auf den genialen Public-Cache und setze den Private-Cache entsprechend hoch.

Wenn du weißt, was du tust, kannst du auch die Checkbox™ aktivieren ;). Ich nehme zumindest an, dass die Seite auch dann aus dem Cache bezogen wird, wenn ein Authorization Header da ist.

Würde ich sogar machen, aber es gibt eben auch Mitgliedergruppen, für die zusätzlicher Content, Seiten und Inhaltselemente, ausgeliefert wird. Dafür ist dann eine wirklich Contao-relevante Authorisierung erforderlich. Das würde dann wohl nicht funktionieren oder läuft das über das PHPSESSID!? Ich probiere das mal aus, ansonsten bleibt es halt ohne Cache, was aber den Seitenaufbau um bis zu 1 Sekunde verzögert. Oder ich haue das ganze Mitgliedergruppeninhaltsgedöns komplett in die Tonne, also in eine eigene Installation mit anderer Domain. Was eh das Vernünftigste wäre.

Bloss auf den "globalen" Zugriffsschutz, dass also die komplette Site passwortgeschützt ist, will ich nicht verzichten.
Soweit ich CSRF-Attacken verstehe, kann ein normaler Websitebesucher nicht missbraucht werden in meinem Fall, weil der trotz erfolgter Authorisierung keinerlei Rechte hat irgendwas zu machen außer eben auf die Website zuzugreifen. Er kann also nichts tun, was dem Angreifer irgendwas bringen würde. Kein Formular, wo er etwas eingeben oder gar eine Mail verschicken könnte. Außer im Backend, wofür er aber nicht autorisiert ist. Eine DOS-Attacke könnte er eventuell gegen meinen Server starten, aber dazu braucht es eh keine Autorisierung. Es müsste dann also schon mich selbst erwischen, wenn ich z.B. im Backend angemeldet bin (einziger angelegter User). Da müsste ich freilich sehr, sehr vorsichtig sein und im selben Browser am besten gar keine anderen Seiten öffnen solange die Backend-Anmeldung gültig ist. Ich weiss nicht ob ich mir das zutraue ;) und ob mir der Cache das wert ist, da muss ich erst mal drüber schlafen.

Aktiviere den Cache generell, inkl. "Immer aus dem Shared Cache laden", und deaktiviere den Cache für alle Seiten, die nutzerspezifischen Inhalt anzeigen.

So kann ich es freilich erst mal machen. Die nutzerspezifischen Inhalte sind eh noch nicht wirklich vorhanden oder nur angedacht. Da gibt es bestenfalls zwei oder drei Beispielseiten als "Proof of Concept". Insofern fällt es mir sicher leicht, bei diesen Seiten den Cache zu deaktivieren, das ist in einer Minute erledigt. Aber was ist mit der Navigation? Die muss ja dann je nach Anmeldung anders aussehen, oder läuft die Navigation per ESI? Ich sehe schon, ich muss den Vortrag von YANNICK nochmal anschauen.

Ja, dann wird's schwierig. Den Vortrag solltest du dir auf jeden Fall auch ansehen.

Bei Magento wird es bspw. so gelöst: alles kommt aus dem Cache, Benutzerspezifische Inhalte werden per AJAX geladen. Das Menü wird per ESI integriert, allerdings so, dass das Menü quasi pro Store View separat gecached und invalidiert werden kann.

Wenn dein Menü auch Nutzerabhängig ist, dann solltest du dir genau überlegen wie und was du machst :D. Bspw. könntest du das ganze Menü per AJAX nachladen. Oder nur die notwendigen Einträge. Das ganze Menü per ESI integrieren macht vermutlich nur dann Sinn, wenn der Rest der Seite komplex ist. Denn wenn du das per ESI in Contao machst ist der Geschwindigkeitsvorteil des Caches evt. schon fast ganz weg. Aber das kommt ganz auf deine Seite an.

Hmm, ich denke dann wähle ich die einfache Lösung: Raus mit den nutzerspezifischen Inhalten! Ich denke die Vorteile überwiegen die Nachteile, die ja momentan sowieso nicht ins Gewicht fallen. Für die anderen Inhalte erstelle ich dann halt irgendwann eine eigene Website, wo ich das dann ganz genau so mache wie jetzt hier: Keine Mitgliedergruppe, der Besucher kommt entweder gar nichts zu sehen (.htaccess + .htpasswd) oder er sieht das Gleiche wie alle anderen die was zu sehen bekommen.:)

So, erstes Update, ich bin jetzt mal da drangegangen und habe den Haken gesetzt, dass immer aus dem shared Cache geladen werden soll. Optimistisch wie ich war, habe ich den Haken erst mal nur im Startpunkt gesetzt, in der Hoffnung, dass es auch für die Unterseiten gilt. Private Cache habe ich zum Testen komplett deaktiviert, Public Cache auf 1 Jahr gesetzt. Dann nochmal den Public Cache gelöscht in der Systemwartung. Um einen Vergleich zu haben, habe ich die .htaccess erst mal weggelassen, so dass die Seite öffentlich ist und eigentlich gar keine Cookies gesetzt werden müssten. Aber weit gefehlt, was vor der Umstellung noch funktioniert hatte (keine Cookies gesetzt) bringt mir jetzt gleich zwei Cookies, csrf und PHPSESSID. Hmmm :confused:. Zusätzlich bekam ich grundsätzlich auch nach mehrmaligen Hin- und Hernavigieren zwischen den Seiten immer nur ein "Miss" für den Contao Cache. Danach habe ich mir mal die Startseite angeschaut und mal die Cache-Einstellungen angeklickt. Da standen beide Caches auf 0 und der Haken war nicht gesetzt. Muss ich jetzt die Zeiten wirklich für jede Seite einzeln setzen und auch den Haken? Puh. Hätte mir gewünscht, dass zumindest der Startwert für die Cachezeiten übernommen worden wäre. Immerhin habe ich das jetzt mal bei einigen Seiten gesetzt wie ich es haben wollte und bei einer von ihnen hatte ich dann irgendwann auch mal ein "Fresh". Ich probiere mal noch ein wenig weiter, aber momentan geht die Tendenz dazu, dass ich auf den Cache dann lieber verzichte. Das Ding ist mir offensichtlich über. Aber die Hoffnung stirbt zuletzt, vielleicht bekomme ich es ja doch noch hin.

Nein, du musst das grundsätzlich nur für den Website Root setzen.

Wenn ein Session Cookie gesetzt wird, dann wird vielleicht eben irgendwo die Session gestartet?

Ich wüsste nicht wo. Ich entferne jetzt nochmal die bereits geänderten Cache-Einstellungen einzelner Seiten, leere alle Caches, natürlich auch den Browsercache, alles was es halt so gibt, schliesse dann den Browser und teste nochmal. Wenn ich dann Cookies finde, nehme ich die Einstellungen in der Website Root auch noch zurück, leere nochmal alles und teste nochmal. Wohlgemerkt bis jetzt sogar ohne den Verzeichnisschutz durch .htaccess und .htpasswd. Wenn die Cookies dann wieder weg sind, dann weiss ich nicht mehr was ich noch machen könnte und lebe halt ohne den Cache. Wenn sie dann immer noch da sind, dann habe ich wohl was falsch gemacht, wenn ich auch nicht weiss was. Denn das war ja schon mal so, dass keine Cookies gesetzt wurden.

Das beste bisher war ja, dass ich für eine Seite mal im Response Header den Contao-Cache als "Fresh" angezeigt bekommen habe, trotz der für mich unverständlicherweise erzeugten Cookies. Immerhin das hat mal funktioniert. Wird also hoffentlich auch funktionieren, wenn zumindest das csrf-Cookie wegen der Autorisierung per .htaccess berechtigterweise gesetzt wird. Ganz besonders unverständlich für mich, dass das bei einer zweiten Seite mit den selben Cache-Einstellungen nicht geklappt hat, da kam weiterhin immer "Miss", obwohl ich mehrmals von der einen auf die andere Seite gewechselt habe.

In dem Zusammenhang könnte folgender Bug relevant sein, ggf. probierst du den vorhandene Bugfix mal bei dir aus: https://github.com/contao/contao/pull/1625

Ja, ich versuche das morgen nochmal sauber zu reproduzieren. Falls es dann tatsächlich nicht funktioniert werde ich die Änderung in der services.yml mal ausprobieren. Den Test kann ich mir ja wohl schenken.

Reproduzieren kann ich es jedenfalls. Zuerst habe ich die Installation wieder auf den Ursprungszustand gebracht. Also die testweise erstellten Cache-Einstellungen einiger Unterseiten wieder rausgenommen, im Startpunkt bei den Cache-Einstellungen den Haken rausgenommen, dass er immer aus dem Shared Cache laden sollen. Gespeichert, Systemwartung-> Shared Cache gelöscht. Contao-Manager->Application Cache neu aufgebaut. Contao-Manager abgemeldet, Browserfenster geschlossen. Browser (Firefox) wieder auf, Startseite aufgerufen, Web-Speicher geprüft. Keine Cookies :). Netzwerkanalyse, Response Header->Contao-Cache: miss/store. Selbes mit den zuvor getesteten Unterseiten, beim zweiten Aufruf einer Seite dann Contao-Cache: fresh. Also alles so, wie es sein sollte.

Dann nochmal den Haken im Startpunkt gesetzt zwecks aus Shared Cache laden aktiv. Gleiche "Säuberung", wie oben. Browser zu und wieder auf. Startseite geladen. Web-Speicher geprüft. Upps, PHPSESSID Cookie! Response Header Contao-Cache: miss. Auf die Unterseite gewechselt. Web-Speicher jetzt Cookies PHPSESSID und csrf. Response Header: miss, bei jeder Seite die ich aufrufe.

Danach nochmal ohne den Haken wegen aus Shared Cache laden. Alles wieder ok! Jetzt werde ich mal den Fix von Yanick einpflegen und schauen ob das etwas ändert. Ohne jeglichen Wissensballast über die inneren Abläufe würde ich eigentlich nicht erwarten, dass es bei dieser Problematik etwas bewirkt, weil ja eigentlich gar kein CSRF-Token erzeugt werden sollte, egal in welchem Speicher. Das wird nach meinem sehr begrenzten Verständnis hier - erst beim zweiten Seitenaufruf - erzeugt, weil beim ersten Seitenaufruf - warum auch immer - das PHPSESSID-Cookie gesetzt wird. Aber Versuch macht kluch! :D

Sodala, hier der nächste Stand. Habe den Fix eingepflegt und getestet. Fehlendes Wissen hilft offenbar nicht immer. Der Fix hat zumindest teilweise etwas gebracht. Ohne aktivierten Verzeichnisschutz klappt das jetzt auch mit aktiviertem "Immer aus dem Shared Cache laden". Mit aktiviertem Verzeichnisschutz aber nur teilweise. Wobei ich nicht beurteilen kann ob das jetzt so gewollt ist oder ein Bug.

Was klappt ist, dass Seiten, die bereits zuvor im Shared Cache gespeichert wurden (beim Aufruf ohne Verzeichnisschutz), werden tatsächlich aus dem Shared Cache geladen. Im Response Header wird angezeigt: Contao-Cache: fresh. Was nicht klappt ist, wenn eine Seite noch nicht im Cache ist, dann wird sie auch nicht gecached, der Response Header zeigt dann bei jedem Aufruf "miss" und nicht "miss/store". Es werden also nur Seiten aus dem Cache geladen, die da bereits drin sind, weitere Seiten werden aber nicht hinzugefügt.

Das steht allerdings auch nicht an der Checkbox im Backend. Insofern könnte man sagen: "It's not a bug, it's a feature!" Sollte meines Erachtens aber nicht so sein. Ich sehe jedenfalls keinen Sinn darin hier die einmal erzeugte Seite nicht in den Shared Cache zu schreiben. Meine Anwendung ist zwar ein Spezialfall, weil ja hier die Seiten NIE ohne gesetztes Cookie aufgerufen werden. Wenn das Cookie meinetwegen nur nach Anmeldung eines Mitglieds gesetzt wird, dann kommt die Seite in den Cache, sobald sie von einem Gast aufgerufen wird. Ab diesem Moment wird die Seite dann aber auch für das angemeldete Mitglied aus dem Cache geladen. Das mag verhindern, dass geschützte Inhalte im Shared Cache landen, so weit so sinnvoll. Aber dass sich die Anzeige für das angemeldete Mitglied ändert sobald die Seite von einem Gast aufgerufen wird, das ist zumindest inkonsistent und für das Mitglied sicher höchst verwirrend. Außerdem wird man die Einstellung "Immer aus dem Shared Cache laden" ja nur wählen, wenn man sich sicher ist, dass auf der entsprechenden Seite sich durch eine Anmeldung nichts ändert. Seiten wo das nicht so sein soll wird man daher gar nicht cachen lassen. Für mich heißt das, bei dieser Einstellung muss eben der zuständige Benutzer/Administrator selbst dafür sorgen, dass hier keine privaten Daten öffentlich zugänglich werden. Einfach indem er entsprechende Seiten explizit vom Cache ausnimmt. Sonst wäre die Einstellung ja weitgehend sinnlos.

Poste das als Ticket ;)

Ich wärme diesen Thread nochmal auf, @BugBuster schrieb zu Beginn des Threads

Zitat:

---

kein public/shared Cache möglich?

---

Seit Umstellung von 4.4.LTS auf 4.9.LTS (derzeit aktuell 4.9.10) habe ich die selbigen Cache-Allüren.
Das Verzeichnis /var/cache/prod//http_cache/ beinhaltet nur wirre leere Unterverzeichnisse mit Buchstaben; unter 4.4.LTS war es gut gefüllt. Private-Cache und Shared-Cache ist aktiviert im Startpunkt

Nach Lesen vieler relevanter Threads wie u.a. https://community.contao.org/de/show...richtenteasern und der Contao Docs erahne ich, dass der CSRF-Cookie die Ursache ist?
@tab und @spooky lieferten interessante Hinweise - besten Dank dafür.
Der Response Header liefert für alle Seiten contao-cache: miss.

Code:

---

HTTP/2 200
date: Thu, 10 Dec 2020 20:56:45 GMT
server: Apache/2.4.43 (Unix)
cache-control: max-age=86400, private
x-powered-by: PHP/7.3.24
vary: Origin
x-content-type-options: nosniff
referrer-policy: no-referrer-when-downgrade, strict-origin-when-cross-origin
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
contao-private-response-reason: session-cookie
contao-cache: miss
age: 1
content-length: 74058
content-type: text/html; charset=utf-8
set-cookie: csrf_https-contao_csrf_token=v4cEKqZNGwGnnvkdeL5WM9GAsxLuEApR5pZxrBxukXw; path=/; secure; httponly; samesite=lax

---

Ansonsten habe ich die Standard .htaccess mit

Code:

---

Header set Cache-Control "max-age=31536000" env=CONTAO_ASSETS

---

Ich hab mal etwas spioniert, bezeichnenderweise liefern auch viele Seiten der Contao-Fallstudien und auch die demo.contao.org contao-cache: miss; jedoch contao.org liefert contao-cache: fresh. Seitenladezeiten sind auch durchwachsen von blitzschnell bis mehrere Sekunden.

Wenn ich das richtig verstanden habe, wird der CSRF-Cookie auf Seiten mit Anmeldeformularen und/oder Kontaktformularen gesetzt und man sollte auf diesen Seiten den Cache in den Seiteneinstellungen deaktivieren. Geholfen hat das noch nichts.
Ich habe auf jeder Seite in der Fußzeile ein kleines Kontaktformular, dass scheinbar durchgängig verantwortlich für den CSRF-Cookie ist?

Mir ist die Sache eigentlich nur aufgefallen, weil die Seitenladezeiten jetzt unter 4.9 LTS manchmal bis knapp unter 10 s betragen (unter 4.4 LTS betrugen die nur ein Bruchteil davon), und da dachte ich das ist nicht sehr erfreulich und ob man das reduzieren könnte ... :) :confused:
Vielleicht hat jemand noch ein paar Tricks oder Stellschrauben wo man den Zustand verbessern könnte - die ich dankenswerterweise gern annehme.

In deinem Response Header steht:

Code:

---

contao-private-response-reason: session-cookie

---

Da hänge ich mich mal ran. Bei mir kommt auf allen Seiten immer:

Code:

---

contao-private-response-reason:        authorization

---

Was sagt mir das? Ich habe keinerlei Formulare, Logins oder ähnliches auf der Seite.

Ich vermute mal, das eine Erweiterung bei jedem Aufruf prüft ob ein Nutzer angemeldet ist oder nicht, aber das sollte doch nicht zum Cache Desaster führen, oder?

Achja, ich hab ein Update gemacht und musste die index.php wieder anpassen. Uberspace sendet ja immer einen HTTP_AUTHORIZATION Header, und auch wenn der leer ist, meint Symfony, das wäre ein Login.

@Bugbuster danke; bin jetzt näher dran an der Sache. Habe im Rocksolid-Template den Cookie-Hinweis zunächst deaktiviert,
jetzt erhalte ich erstmalig Set-Cookie: PHPSESSID ....
Browsertool meldet jetzt:

Code:

---

:status: 200
Content-Type: text/html; charset=utf-8
X-XSS-Protection: 1; mode=block
Age: 0
Set-Cookie: PHPSESSID=ujoncqnvt8obhuge406am246sf; path=/; secure; httponly
Referrer-Policy: no-referrer-when-downgrade, strict-origin-when-cross-origin
Cache-Control: max-age=86400, private
Date: Sat, 19 Dec 2020 00:21:21 GMT
Content-Length: 72023
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Vary: Origin
x-powered-by: PHP/7.3.25
Server: Apache/2.4.43 (Unix)
contao-cache: miss
contao-private-response-reason: session-cookie

---

Header-Abfrage über curl auf der Konsole ergibt weiterhin

Code:

---

contao-private-response-reason: session-cookie

---

Mal sehen ob ich mich jetzt über das PHPSESSID weiterkomme, dazu gibt es ja etliche Treads .., oder ich muss mal die eingebauten Module nacheinander abschalten; ich bleibe dran ..

Wenn bei dir eine Session aktiv ist, wird by default nichts aus dem Cache ausgegeben.

Außer du aktivierst "Immer aus dem shared cache laden" - aber dann kannst du keine individualisierten Inhalte ausgeben.

Wenn wir mal davon ausgehen, dass der CSRF-Cookie das Problem ist und dieser wegen des Formulars auf allen Seiten aktiv ist, warum nicht aus den Seiten rausnehmen und durch einen Link auf eine gesonderte Seite mit dem Kontaktformular ersetzen? Was allerdings zu beachten ist: Sobald ein Besucher diese Seite aufgerufen hat ist der Cookie gesetzt und es geht danach dann wieder ohne Cache weiter.

Das CSRF Token Cookie wird wieder entfernt, wenn es nicht gebraucht wird.

Zitat:

---

Zitat von Spooky

Das CSRF Token Cookie wird wieder entfernt, wenn es nicht gebraucht wird.

---

Stimmt, gerade getestet. War das schon immer so?

In der 4.9 denke ich ja.

Besten Dank für die Hinweise von @Spooky und @tab
Seitdem ich im Seitenlayout aus Kopf- und Fußzeilen vorhandene Formulare und Logins rigoros entfernt habe, diese jetzt auf separate Seiten verlinke und für diese separaten Seiten den Cache deaktiviert habe, funktioniert nun auch der komplette Seitencache und ich bekomme endlich contao-cache: fresh . Nutzung von Login und Kontaktformular ist sehr gering, so dass es zumutbar ist, auf eine zentrale Seite zu verlinken.
Cookies tauchen keine mehr auf, nur während aktiver Anmeldung am Frontend ist der per default gesetzte CSRF Token Cookie aktiv.

Die zusätzliche Verwendung der .env-Datei

Code:

---

COOKIE_WHITELIST=PHPSESSID,csrf_https-contao_csrf_token

---

erzeugt mit Firefox/Win10 beim Backend-Login immer ein Ungültiges Anfrage-Token, welches nach Aufrufen des Installtools einmalig wieder weg ist, andererseits zeigt Safari/Mac dieses Verhalten nicht. Deshalb habe ich die .env generell nicht in Benutzung.

Für die Starteite funktioniert der Cache auch, der Thread scheint für 4.9. LTS nicht relevant zu sein:
https://community.contao.org/de/show...der-Startseite