Bug #91697

Access protecting root page results in "page not found" when user is not logged in, as opposed to "page inaccessible"

Added by Claus Due 19 days ago. Updated 19 days ago.

Must have
Target version:
Start date:
Due date:
% Done:


TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


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.


#1 Updated by Claus Due 19 days ago

  • Category set to Frontend

Also available in: Atom PDF