Project

General

Profile

Actions
Copy link

Bug #104160

open

TYPO3 sends wrong Cache-Control header for pages with dynamic content

Added by Oliver Eglseder 9 days ago. Updated 5 days ago.

Status:
Accepted
Priority:
Should have
Assignee:
-
Category:
Caching
Target version:
next-patchlevel
Start date:
2024-06-20
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
12
PHP Version:
8.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

How to reproduce:

  • Fresh composer-installed minimal TYPO3 v12 with typo3/cms-felogin
  • Set TypoScript setup: config.sendCacheHeaders = 1
  • Create a default FE User Group (because it is required for FE users)
  • Create a FE User
  • Create a page with one CE hidden at login and one CE with show at login. (see screenshot)
  • Log out from the backend or open incognito tab
  • Visit the page with the two content elements -> It shows "not logged in"
  • Login with the created FE user
  • Visit the page with the two content elements again (no hard refresh) -> It shows "not logged in" again

Problem:

The page is cached on the client side.

When visiting the page, TYPO3 sends the header Cache-Control: max-age=86400 and Pragma: public which caches the page on the client (also, proxies are allowed to cache the page and make the problem worse). Since the page contents are dynamic, based on the login status of the user, TYPO3 must not tell clients and proxies that the page is cacheable.

Why is it a problem

The majority of users know nothing about browser caching. Therefore, you cannot expect users to perform a hard refresh on every page they suspect to miss some content after logging in. As a result, users complain to the site operator, which complain to us, the agencies.

The solution:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching#force_revalidation

The response must include the header Cache-Control: no-cache, Last-Modified and ETag (ETag should be generated by the webserver)

Impact:

  • On pages which contain dynamic content based on user login, users will always see the correct content.
  • You could probably enumerate all pages which contain dynamic content, but i don't consider this as a security problem, as the these pages tell you to log in to see more content most of the time, and that a page can contain different content is no attack vector.
  • TYPO3 does already cache the page internally. Rendering the page again is not very resource consuming. This is the best trade-off between freshness of the page and overhead on the server side.

Related issue: https://forge.typo3.org/issues/82848
The only answer references the typoscript sendcacheheaders-onlywhenlogindeniedinbranch, but that was removed in TYPO3 v12

Files

clipboard-202406201235-0hnuu.png (151 KB) clipboard-202406201235-0hnuu.png Oliver Eglseder, 2024-06-20 10:35
Actions
Copy link
 #1

Updated by Benni Mack 5 days ago

  • Status changed from New to Accepted

Hey,

yes. I have a similar issue which I patched in a TYPO3 v11 installation: TYPO3 can cache the contents for 24h, but should not tell the client to cache it for 24hs. Instead, the proxy "could" cache it for a time (but this is s-maxage, not used by all vendors) if the proxy is purgeable. So we have two options:

  • Ugly solution: If we have fe_users available, we should never cache a site
  • document that config.sendAllCacheHeaders = 1 is a bad idea in general (it's not just about fe_users, but also about the freshness of updated content)
  • Introduce a new setting that superseeds sendAllCacheHeaders = 1 but allows to define the maxage for clients and proxies.
Actions
Copy link

Also available in: Atom PDF