Bug #17952
closedtypolinkLinkAccessRestrictedPages / showAccessRestrictedPages access does not work with "include subpages"
0%
Description
If there is a not access restricted page with a link to a page with is access protected, butnot directly but through the "include subpages" feature of its parent, the typolinkLinkAccessRestrictedPages feature does not work. The link to the is displayed, but not rewritten to the page configured with typolinkLinkAccessRestrictedPages = pid
in order to reproduce create three pages a,b, and c (a parent of b, c child of b)
and access protect b.
Create two links on a, one to b the other to c.
Activate typolinkLinkAccessRestrictedPages and set it to a's pid.
Two links are shown. The "b" link actually links to a but the "c" link does not.
The same applies to menues with showAccessRestrictedPages
this is due to the fact that during the procedure which figures out if the page is access restricted, only the current page is checked for access parameters but not its ancestors.
(issue imported from #M7051)
Updated by Mathias Schreiber almost 17 years ago
This might result in MASSIVE performanc problems.
Imagine a sitemap being rendered.
Each link triggers a request to the rootline function, which - itself - will retrigger itself over and over again.
We are jumping around with this problem for a while now but did not (yet) suceed in finding a solution which is reasonable (performancewise)
Updated by Peter Beernink almost 17 years ago
Yes. I've been looking at a solution for a while and came to the same conclusion.
What might be an option is to add some sort of caching of the results, so pages 'know' whether or not its rights structure has been defined at an higher level, but then again when should it be triggerd or cleared.
Updated by Mikkel Ricky over 16 years ago
In TYPO3 4.2 results from "t3lib_page::getRootLine" are cached and this should eliminate (serious) performance problems if checking root line for access restrictions extending to subpages.
Updated by Christian Kuhn over 15 years ago
Resolved as a duplicate of #16561 that describes the exact same issue.