Bug #20540
closedPages protected by incl. sub-pages FE-group don't redirect
0%
Description
If you have a incl. sub-pages FE-group protected hierarchy you get the page renderd according to your login-status, instead of being redirected.
My wild guess is that the page-cache tags (clearing according to or saving) are not honoring "incl. sub-pages". Because the page-sections behace correctly and no secured information (except the existance of that page) is exposed.
(issue imported from #M11237)
Files
Updated by Niels Fröhling over 15 years ago
Okay, the reason is in cms/class.tslib_fe.php: 1230
function checkPagerecordForIncludeSection($row) {
return (!$row['extendToSubpages'] || $this->checkEnableFields($row)) ? 1 : 0;
}
This check is plainly wrong, here is the fail-scenario:
Rootline:
1: not protected
`-- 2: fe_group, no extendTo
`-- 3: fe_group, extendTo enabled
`-- 4: not protected
- sys_page->getPage returns the entry (not protected)
- checkRootlineForIncludeSection() returns:
TRUE, TRUE, FALSE, TRUE for non-removal - the page displayed is the last in the rootLine, which is '2', which is wrong!
- sys_page->getPage returns no entry
- getPageAndRootline() takes over the search for the next valid page and correctly removes 2, 3, 4
- the page displayed is the last in the rootLine, which is '1'
It can be seen that getPageAndRootline() itself does the job just fine, checkRootlineForIncludeSection() is just a post-function for cases that are a bit more complex, especially trying to cover extendTo cases. I asume from that one-liner that the initial intention is to not return FALSE for un-protected pages (those that do not have fe_groups). Reconstructing that initial intention the function should be:
function checkPagerecordForIncludeSection($row) {
return (!$row['fe_group'] || $this->checkEnableFields($row)) ? 1 : 0;
}
instead.
It makes no sense to bind access-restriction to the pure existance of the extendTo-flag!
Patch attached and verified under the given fail-case. Acessing '2', '3' or '4' all drop to '1' now. If logged-in, they all allow correct access.
Updated by Niels Fröhling about 15 years ago
After three months of testing and verification I came up with the last uploaded solution. Changing "checkPagerecordForIncludeSection" will break getPidList (logins, realurl, ...), which must not execute extendTo-functionality (as storage folders within extendTo will not be able to be found, etc.).
Updated by Oliver Hader about 15 years ago
Did you test whether this behaviour also occurred in TYPO3 4.2?
Updated by Niels Fröhling about 15 years ago
Give me a day, I'm going to check it in 4.2.0. Deductions says "yes", as the code hasn't changed since ages.
Updated by Popy no-lastname-given about 15 years ago
I have another kind of problem with this issue :
When a page is not accessible, the checkRootlineForIncludeSection function fall back to the last valid page correctly. But the last accessible page is (in my case) a shortcut page... which is not resolved.
This "problem" occurs around the checkRootlineForIncludeSection function usage (around line 1084 of tslib_fe)
Updated by Popy no-lastname-given about 15 years ago
Well, i tried something.
As rootline is modified each time we follow a shortcut, the shortcut resolution should maybe be a loop (around in tslib_fe, line 1041).
Rootline check maybe have to be done one time, and then each time we follow a shortcut.
Updated by Alexander Opitz over 11 years ago
- Status changed from New to Needs Feedback
- Target version deleted (
-1)
The issue is very old, does this issue exists in newer versions of TYPO3 CMS (4.5 or 6.1)?
Updated by Alexander Opitz about 11 years ago
- Status changed from Needs Feedback to Closed
- Is Regression set to No
No feedback for over 90 days.