Bug #86346

Hidden pages sent 403 Header

Added by Sascha Egerer about 1 year ago. Updated about 1 year ago.

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

0%

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 New 2013-11-20

History

#1 Updated by Sascha Egerer about 1 year ago

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

#2 Updated by Markus Klein about 1 year 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 1 year 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 1 year ago

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

#5 Updated by Sascha Egerer about 1 year 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 1 year ago

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

#8 Updated by Markus Klein about 1 year 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 1 year 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

Also available in: Atom PDF