TYPO3 Core

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->rootline⁰) returns false

If fulfilled:

• Set $this->pageNotFound = 1 indicating that failure reason is that page is not accssible
• Set $this->pageAccessFailureHistory['direct_access'][] = $this->rootline⁰;
• 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.