Bug #82848
closed
Wrong 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.
Updated by Moritz Ahl about 7 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
Updated by Moritz Ahl about 7 years ago
- Related to Feature #53813: Different redirects for different error types in "Page not found" handling added
Updated by Susanne Moog over 4 years ago
- Status changed from New to Closed
Multiple answers to multiple questions. First of all: The main documentation of frontend login related features (for example the how to redirect users to a login page) can be found at https://docs.typo3.org/c/typo3/cms-felogin/master/en-us/Introduction/Index.html
To your third problem: the browser would not cache a 404 response. However, there are still cases where the same URL with different content depending on login state might be used. TYPO3 provides a configuration option just for these cases: https://docs.typo3.org/m/typo3/reference-typoscript/master/en-us/Setup/Config/Index.html#sendcacheheaders-onlywhenlogindeniedinbranch
Hope that answers - albeit a bit late - your questions.