Bug #58728
closed
Regression: unaccessible protected section with shortcut in rootline
Added by Alexander Stehlik about 10 years ago. Updated over 5 years ago.
100%
Description
The fix for #16472 introduced a regression when you have a shortcut in the rootline.
My rootline looks like this:
- Root page (is_siteroot flag is set here)
-- Shortcut to Homepage
--- Homepage
--- Protected page (expand to subpages)
---- Protected Subpage
When I try to access any protected subpage I will always be redirected to the Hompage.
The reason for this seems to be the introduced recursive call to $this->getPageAndRootline() which will set the $this->originalShortcutPage class property which will end up in a redirection to the shortcut.
Updated by Alexander Opitz about 10 years ago
What happened till yet on your setup?
Updated by Alexander Stehlik about 10 years ago
Before the page not found handler was triggered when I was not logged in and tried to access the page.
The problem does not seem to occur when I'm logged in.
Updated by Alexander Opitz about 10 years ago
- Status changed from New to Accepted
So it didn't worked as expected before. But everyone thought this is the correct behavior. ;)
As already written in #16472, this fields needs a complete rethinking. The status vars and the found page are coupled yet and the NotFound handler don't know what to do. Also you can't configure it like you want it.
So in question:
- Revert the fix and work out a better (and cleaner) solution
- Let the patch in and work out a better solution
- Fix it and get new regressions till end of live
- Define the yet existing handling as correct (which seams isn't)
Updated by Alexander Stehlik about 10 years ago
Well, the current behavior would be correct, if the default page not found handler is used. But when I disable the default behavior (redirecting to next accessible page in page tree) this behavior is definitely wrong because the error handler is not triggered at all.
I can't decide which is the best solution. I'm currently reverting the patch in the source I'm using because I never was affected by the bug that is fixed with the patch. But as it looks to me the whole page permission handling could use some love (also performance wise, e.g. #57953).
Updated by Alexander Opitz about 10 years ago
@Alex
"But when I disable the default behavior ..." how do you disable the default behavior?
Updated by Alexander Stehlik about 10 years ago
You can set it in $TYPO3_CONF_VARS['FE']['pageNotFound_handling']. When this setting is empty (as in DefaultConfiguration.php) the user will be redirected to the next upper page.
When you set it to TRUE you will get an error message, that the requested page is not accessible instead. You can also use different prefixes (like REDIRECT: or READFILE:).
Updated by Alexander Opitz about 10 years ago
@Alex
"When this setting is empty the user will be redirected to the next upper page" ... the page was searched but $this->pageNotFound wasn't reseted => Uptree page shown but symlink pages not resolved (1)
"When you set it to TRUE you will get an error message, that the requested page is not accessible instead." ... another page is searched uptree but handler is messaged (2)
Now I remember my old issue: The fix I introduced was to have the handler active but also have the uptree functionality. (3)
So there are 3 things.
(1) Is fixed.
(2) Can be fixed, cause we don't need uptree search if we will error.
(3) Was fixed but resulted in this regression.
So we need a way to enable/disable the behavior of (3) with default disabled if $TYPO3_CONF_VARS['FE']['pageNotFound_handling'] isn't empty.
Does this sounds correct?
Updated by Alexander Opitz about 10 years ago
If we want to fix/rewrite this, we should also consider #23178
Updated by Alexander Opitz about 10 years ago
Hi Ernesto,
how would you like to progress in this regression?
1) Revert patch.
2) Add a possibility to enable/disable the "uptree" handling.
I'd also like to rewrite this part, with backward compatible handling, can this be done for 6.2.x or only for 6.2+x?
Updated by Oliver Hader about 10 years ago
Alexander Opitz wrote:
1) Revert patch.
2) Add a possibility to enable/disable the "uptree" handling.
I'd opt for reverting the change in 6.2 and 6.1 and then work out a clean and consistent solution.
Besides that, I'd consider #23178 as separate issue.
Updated by Gerrit Code Review about 10 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/31039
Updated by Gerrit Code Review about 10 years ago
Patch set 1 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/31041
Updated by Gerrit Code Review about 10 years ago
Patch set 2 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/31041
Updated by Gerrit Code Review about 10 years ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/31039
Updated by Helmut Hummel about 10 years ago
Oliver Hader wrote:
Alexander Opitz wrote:
1) Revert patch.
2) Add a possibility to enable/disable the "uptree" handling.I'd opt for reverting the change in 6.2 and 6.1 and then work out a clean and consistent solution.
Besides that, I'd consider #23178 as separate issue.
I agree. Reverts are pending now.
If nobody objects, I will merge within the next days...
Updated by Gerrit Code Review about 10 years ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/31039
Updated by Gerrit Code Review about 10 years ago
Patch set 3 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/31041
Updated by Gerrit Code Review about 10 years ago
Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/31045
Updated by Helmut Hummel about 10 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 626925808451f6464753008038094d17553fdadc.
Updated by Martin Kutschker almost 10 years ago
According to http://wiki.typo3.org/TYPO3_CMS_6.1.10 the regresion has not been fixed for 6.1. branch. The way the changelog is written, the regression has been introduced in 6.1.10.
Updated by Alexander Opitz almost 10 years ago
@Martin Kuschker
From the 6.1.10 ChangeLog
2014-06-22 6269258 #58728 Revert "[BUGFIX] Inaccessible pages on shortcuts/PageNotFound handler" (Helmut Hummel)
2014-05-22 203c1eb #16472 [BUGFIX] Inaccessible pages on shortcuts/PageNotFound handler (Alexander Opitz)
<<<
So it was introduced and reverted while developing 6.1.10, so no issue here.
Updated by