Bug #82848
closedWrong cache-control headers when accessing restricted pages
0%
Description
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.