Bug #91697
openAccess protecting root page results in "page not found" when user is not logged in, as opposed to "page inaccessible"
0%
Description
This is a rather complex bug. It triggers when:
- You configure the root page of a domain to be access protected
- TypoScriptFrontendController attempts to resolve the page, but does not disable access checks
- An early guard clause triggers pageNotFound handling because page is not resolved - but root line is NOT empty
- This prevents the true group access checks from triggering
The result is that any custom class registered for page-not-found handling is told the page does not exist, when it fact it does exist but is merely access protected. And this in turn prevents such a custom class from handling this particular case as an access failure case.
It is possible to work around this:
if (empty($parameters['pageAccessFailureReasons']) && count($controller->rootLine) === 1) { // No reason was provided and the root line contains a single entry. Check the only page that is in the // root line and determine if it was access protected. If it is access protected, return true. // Perform the access check by repeating a call to get the page record, but with access check enabled. $pageIsRootAndNotAccessibleByUserGroup = !$controller->checkPageGroupAccess($controller->rootLine[0]); }
Suggested fix:
In \TYPO3\CMS\Frontend\Controller\TypoScriptFrontendController::getPageAndRootline, in the second check for "if (empty($this->page))", check if:
- Root line contains a single entry (the requested page was the root page and it exists)
- $this->checkPageGroupAccess($this->rootline0) returns false
If fulfilled:
- Set $this->pageNotFound = 1 indicating that failure reason is that page is not accssible
- Set $this->pageAccessFailureHistory['direct_access'][] = $this->rootline0;
- call $this->pageNotfoundAndExit('The requested page was not accessible!', $GLOBALS['TYPO3_CONF_VARS']['FE']['pageUnavailable_handling_statheader']); instead of calling $this->pageNotFoundAndExit('The requested page does not exist!');
This causes the same check and failure reason for a request made directly to a protected root page, as would trigger for a request made directly to a protected sub-page.
Bug is encountered on 8.7 but almost certainly exists on all versions up to and after 10 LTS.
Set to "must have" as this bug is a serious inconsistency that prevents proper use of custom page-not-available handling.