Bug #86346

Hidden pages sent 403 Header

Added by Sascha Egerer about 2 years ago. Updated 29 days ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2018-09-21
Due date:
% Done:

100%

TYPO3 Version:
8
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When trying to access a hidden page a 403 Header is sent. This has been introduced in #23178
As a hidden page from the frontend view does not exist, it must sent a 404 header and not a 403 which means it is not accessible due to missing authentication


Related issues

Related to TYPO3 Core - Bug #23178: Wrong HTTP headers sent when trying to access pages that require login Closed 2010-07-14
Related to TYPO3 Core - Feature #53813: Different redirects for different error types in "Page not found" handling Closed 2013-11-20
Related to TYPO3 Core - Bug #88957: ID was not an accessible page - on hidden pages although the 404 error handler is configured in the site config Closed 2019-08-14
Related to TYPO3 Core - Bug #82036: Missing use of pageNotFound_handling in TypoScriptFrontendController.php, only PageNotFoundException is used. Closed 2017-08-03

Associated revisions

Revision 14c742b7 (diff)
Added by Oliver Hader about 1 month ago

[TASK] Always send 404 response on hidden pages

As a backend user, it is possible to preview a hidden page & record
in a workspace, however, without a user it is not possible.

Adding the tests also discovered that access to a "hidden" page should
result in a 404 instead of 403 response (even though the page
has access restrictions or not) in a live environment.

This change adds tests to ensure this functionality is always working.

Resolves: #92225
Resolves: #84098
Resolves: #86346
Releases: master, 10.4
Change-Id: I746717473bb93681c7b998d61c4f72eab4ec2ef3
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/58829
Tested-by: TYPO3com <>
Tested-by: Benni Mack <>
Tested-by: Christian Kuhn <>
Reviewed-by: Benni Mack <>
Reviewed-by: Christian Kuhn <>

Revision 6537d297 (diff)
Added by Oliver Hader about 1 month ago

[TASK] Always send 404 response on hidden pages

As a backend user, it is possible to preview a hidden page & record
in a workspace, however, without a user it is not possible.

Adding the tests also discovered that access to a "hidden" page should
result in a 404 instead of 403 response (even though the page
has access restrictions or not) in a live environment.

This change adds tests to ensure this functionality is always working.

Resolves: #92225
Resolves: #84098
Resolves: #86346
Releases: master, 10.4
Change-Id: I746717473bb93681c7b998d61c4f72eab4ec2ef3
Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/65815
Tested-by: TYPO3com <>
Tested-by: Benni Mack <>
Reviewed-by: Benni Mack <>

History

#1 Updated by Sascha Egerer about 2 years ago

  • Related to Bug #23178: Wrong HTTP headers sent when trying to access pages that require login added

#2 Updated by Markus Klein about 2 years ago

"Funny". Reading my patch 10 month later, I realize the wording of "accessible" does not reflect the actual "forbidden" state, but also all the other enable fields.
That's very unfortunate.

On the other hand: The page does exist, you just don't have access if it is hidden or expired. So semantically that's not really wrong. Do you see any SEO consequences?

#3 Updated by Sascha Egerer about 2 years ago

Yes, Google throws lots of “could not access page anymore” errors.

From the Frontend point of view they do not exist. There is no way from the frontend to make them accessible so I would that a 404 must be used.

#4 Updated by Markus Klein about 2 years ago

Okay, so we need to revert #23178. Unfortunate, but necessary.

#5 Updated by Sascha Egerer about 2 years ago

Markus Klein wrote:

Okay, so we need to revert #23178. Unfortunate, but necessary.

Are you sure? I think we do still need some parts of it. The code must just not be 403 for disabled pages but still for non accessible pages (due to frontend group restriction)

#7 Updated by Markus Klein about 2 years ago

  • Related to Feature #53813: Different redirects for different error types in "Page not found" handling added

#8 Updated by Markus Klein about 2 years ago

Technically we can't distinguish those cases currently code-wise. The reason why a page can't be accessed is hidden quite deep in the code. It needs a good amount of refactoring to preserve the reason until the final header is sent.

#9 Updated by Urs Braem about 2 years ago

Maybe related (?): for some custom extbase records, when not existing, I get a 303 immediately followed a redirect to the central 404 page (which then throws the correct 404)
https://www.gendercampus.ch/de/aktuelles/neuigkeiten/nonexistingrecord

#10 Updated by Christian Eßl 8 months ago

  • Category set to Frontend

#11 Updated by Susanne Moog 7 months ago

  • Related to Bug #88957: ID was not an accessible page - on hidden pages although the 404 error handler is configured in the site config added

#12 Updated by Susanne Moog 7 months ago

  • Related to Bug #82036: Missing use of pageNotFound_handling in TypoScriptFrontendController.php, only PageNotFoundException is used. added

#13 Updated by Johannes Seipelt 6 months ago

For disabled pages I managed to show the content of the 404 error page the same way its used in my site-configuration (multi-site and multi-language) with this added to my AdditionalConfiguration.php (v9):

if (preg_match('/\/en\//', $_SERVER['REQUEST_URI']) || $_GET['L'] == 1) {
    $GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling'] = '/en/404/';
} else {
    $GLOBALS['TYPO3_CONF_VARS']['FE']['pageNotFound_handling'] = '/de/404/';
}

The status code 403 is ofc still wrong in that case but atleast i can show content to the user and not just the error page (Page Not Found Reason: ID was not an accessible page)
What would be a better way to get it right? these options have been removed in v10 and iam still trying to understand why i can set a error page for 403 with pageNotFound_handling, didnt TYPO3 distinguish between 403/404 in the past? To just set the ErrorHandling for 403 in the site-configuration to the same handling as 404 doesnt seem right to me.

#14 Updated by Gerrit Code Review about 2 months ago

  • Status changed from New to Under Review

Patch set 15 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/58829

#15 Updated by Gerrit Code Review about 2 months ago

Patch set 16 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/58829

#16 Updated by Gerrit Code Review about 2 months ago

Patch set 17 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/58829

#17 Updated by Gerrit Code Review about 1 month ago

Patch set 18 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/58829

#18 Updated by Gerrit Code Review about 1 month ago

Patch set 1 for branch 10.4 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/65815

#19 Updated by Oliver Hader about 1 month ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100

#20 Updated by Benni Mack 29 days ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF