Bug #82848

Wrong cache-control headers when accessing restricted pages

Added by Moritz Ahl almost 2 years ago. Updated almost 2 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


Scenario: As an editor, I want to easily create access restricted pages which require a valid frontend login. TYPO3 currently provides ways to access-restrict pages through page properties.

Unfortunately there are some problems with that:
1. What does the field "Login behaviour" do? An explanation is missing in documentation.
2. I see no way for a developer/admin to specify what should happen if the page is accessed if no valid login is given. Are there any ways? If yes, we should include them as best practice in documentation.
3. Currently, when accessing a restricted page in FE, TYPO3 seems to search for the first parent page which is not restricted, and then TYPO3 delivers the content of that page under the URL of the access restricted page. That leads to problems with caching.

The cache-control headers which are sent with the access-restricted page are calculated based on the content of the not-restricted page. In my case, that's the start page which is fully cacheable if not logged in. This leads to long living expires headers being sent with the URL of the access-restricted page. This again leads to "wrong" content for the access restricted page being cached in the client's browser, thus the user will not be able to see the "right" content for the accedd restricted page when he logs in.

Note: A widely-uses workaround for all these issues is that editors shouldn't restrict the whole page but rather the several content elements on it. While this solves the problem, this workaround is in no way convenient especially if there are many pages with many content elements on it. And since there is no way in the backend page view to filter out certain content elements, it also clutters the page. So in my eyes TYPO3 editors diserve a better solution.

The following steps should be taken:
1. [Task] Provide documentation for "login behaviour" field in page properties.
2. [Feature or Task] Provide functionality or documentation to specify what shall happen if an acces-restricted page is accessed
3. [Bug] Send no-cache cache-control headers for access-restricted pages showing content from other pages.

Related issues

Related to TYPO3 Core - Feature #53813: Different redirects for different error types in "Page not found" handling New 2013-11-20


#1 Updated by Moritz Ahl almost 2 years ago

I just found out that there's a configuration setting in the install tool:
$GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling'] = REDIRECT:index.php?id=2

But it also affects really non-existing pages which shall show a 404 page. Problem can be solved when we have this in the core: https://forge.typo3.org/issues/53813

#2 Updated by Moritz Ahl almost 2 years ago

  • Related to Feature #53813: Different redirects for different error types in "Page not found" handling added

Also available in: Atom PDF