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 over 1 year ago. Updated over 1 year ago.

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


Estimated time:
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.


Updated by Claus Due over 1 year ago

  • Category set to Frontend

Also available in: Atom PDF