Bug #91892
openlinkAccessRestrictedPages (typolink setting) should only be considered when building link tags, not when building URIs
0%
Description
linkAccessRestrictedPages
of typolink is historically used to control whether procteded pages appear in menus for un-authenticated users, so it controlls whether an actual <a>-tag is rendered or not.
In the modern days the typolink service is used for all kinds of URI building, for example in ext:redirects
, where only pure URIs are generated, not full <a>-tags.
If linkAccessRestrictedPages
is not set it defaults to false, which in the case of ext:redirects
leads to 404. In other cases it just returns an empty url, having unpredicatble consequences.
Also, one has to always think about setting linkAccessRestrictedPages => true
explicitly, which is error prone.
I propose to change the behaviour in the core generally to only respect linkAccessRestrictedPages
when building <a>-Tags (like in typoscrip MENU objects, or in f:link ViewHelpers). In all other cases it should default to true
.
If a developer or a redirect or some other tool explicitly requests the URL to a protected page this may not be empty or treated as 404. In fact the URL does exist and the API must return it thus. If the url is accessed the 403 handler jumps in anyways, which is the correct bahaviour.
You can also look at the name of this setting to understand this - it's not named buildUriToAccessRestrictedPages
but linkAccessRestrictedPages
!
Updated by S P over 4 years ago
- Related to Bug #91879: Redirecting a logged out user to an access restricted page via t3 link does not handle it as 403 but as 404 added