Bug #91729

Frontend 404 handling incorrectly reports "group access denied" if access history is empty, should report 404 not found

Added by Claus Due over 1 year ago.

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


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


Observed on 8.7 but should be exactly the same up to and including v10.4

Set to "must have" since this causes major inconsistency in information transmitted to 404 handlers

Consider the following code from TypoScriptFrontendController->getPageAccessFailureReasons:

$combinedRecords = array_merge(is_array($this->pageAccessFailureHistory['direct_access']) ? $this->pageAccessFailureHistory['direct_access'] : [['fe_group' => 0]], is_array($this->pageAccessFailureHistory['sub_section']) ? $this->pageAccessFailureHistory['sub_section'] : []);
if (!empty($combinedRecords)) {
    // Generate failure reason

If $this->pageAccessFailureHistory['direct_access'] is EMPTY, a virtual entry is generated here which 1) has no page UID as key, and 2) says that fe_group is zero.

This then makes the !empty() check return TRUE (because $combinedRecords contains this virtual entry) and enter the condition which generates an incorrect failure reason that is then transmitted to registered 404 handlers.

Handlers receive the following incorrect information:

  • Failure happened because of group access (wrong, it happened because a page was not resolved)
  • UID of page is zero (wrong, no such page can exist)
  • UID of group that caused the failure is zero (wrong, this would always have to be a valid ID or special keyword -2)

In short, it makes the 404 error appears like a "group access denied" error.

The reason for the incorrect behavior is the falling back to a virtual "direct_access" group restriction error. Removing this part correctly identifies the 404 error as a "page not found".

No data to display

Also available in: Atom PDF