Project

General

Profile

Actions

Bug #20540

closed

Pages protected by incl. sub-pages FE-group don't redirect

Added by Niels Fröhling almost 15 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2009-06-02
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

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

11237.diff (582 Bytes) 11237.diff Administrator Admin, 2009-06-09 22:23
11237_final.patch (4.01 KB) 11237_final.patch Administrator Admin, 2009-10-09 23:30
Actions #1

Updated by Niels Fröhling almost 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

We access '4' directly:
  • 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!
We access '3' directly:
  • 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.

Actions #2

Updated by Niels Fröhling over 14 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.).

Actions #3

Updated by Oliver Hader over 14 years ago

Did you test whether this behaviour also occurred in TYPO3 4.2?

Actions #4

Updated by Niels Fröhling over 14 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.

Actions #5

Updated by Popy no-lastname-given over 14 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)

Actions #6

Updated by Popy no-lastname-given over 14 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.

Actions #7

Updated by Alexander Opitz almost 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)?

Actions #8

Updated by Alexander Opitz over 10 years ago

  • Status changed from Needs Feedback to Closed
  • Is Regression set to No

No feedback for over 90 days.

Actions

Also available in: Atom PDF