Bug #15984

menu.showAccessRestrictedPages doesn't replace link for "include subpages"

Added by Wolfgang Sassik almost 16 years ago. Updated almost 2 years ago.

Status:
Accepted
Priority:
Should have
Assignee:
-
Category:
Frontend
Target version:
-
Start date:
2006-04-05
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
hard
Is Regression:
Sprint Focus:

Description

When creating a menu with showAccessRestrictedPages set to any PID, links to pages that inherit a usergroup restriction ("include subpages" set on a parent page) won't be substituted.

function changeLinksForAccessRestrictedPages(..) @ class.tslib_menu.php is calling $GLOBALS['TSFE']->checkPageGroupAccess($page) which itself does not traverse the pagetree to check if a parent page has the field "extendToSubpages" set true.

Same problem may occour when using config.typolinkLinkAccessRestrictedPages for typolinks, but I have not tried yet.
(issue imported from #M3129)


Files

3129.diff (905 Bytes) 3129.diff Administrator Admin, 2010-06-10 22:46

Related issues

Related to TYPO3 Core - Bug #22860: typolinkLinkAccessRestrictedPages_addParams doesn't work on restricted subpagesClosed2010-06-10

Actions
Related to TYPO3 Core - Bug #26484: extend to subpages in page properties in access tab does not work correctlyClosed2011-04-29

Actions
Related to TYPO3 Core - Bug #78825: Wrong pid determination when opening a nested access restriced pageNeeds Feedback2016-11-28

Actions
Precedes TYPO3 Core - Bug #32756: Massive Memory Leak in 4.5.8+ / 4.6Closed2011-12-21

Actions
#1

Updated by Sascha Egerer about 12 years ago

This Problem still exists in TYPO3 4.2.X and 4.3.X!

tslib_fe.checkPageGroupAccess() does not work with "extendToSubpages".

Page 1 (restricted and extendToSubpages checked)
- Page 2 (not directly restricted but should be restricted because of "extendToSubpages" of Page 1)

$GLOBALS['TSFE']->checkPageGroupAccess(2) returns true because it does not check the page tree.

#2

Updated by Franz Koch over 11 years ago

Just stumbled over this bug in recent 4.4 SVN version.

#3

Updated by Chris topher over 11 years ago

It would be great, if someone of you could provide a patch and send it to Core List:

http://typo3.org/teams/core/core-mailinglist-rules/

#4

Updated by Sven Teuber over 11 years ago

The problem occurs for config.typolinkLinkAccessRestrictedPages, too, see related ticket 0014690

http://bugs.typo3.org/view.php?id=14690

#5

Updated by Sven Teuber over 11 years ago

Provided patch, will send it to core list now

#7

Updated by Mr. Hudson almost 11 years ago

Patch set 3 of change I98ea123ccdf1e370f28103546191b0a7234076f4 has been pushed to the review server.
It is available at http://review.typo3.org/1186

#8

Updated by Mr. Hudson over 10 years ago

Patch set 1 of change I98ea123ccdf1e370f28103546191b0a7234076f4 has been pushed to the review server.
It is available at http://review.typo3.org/2544

#9

Updated by Mr. Hudson over 10 years ago

Patch set 1 of change I459aa01a8aba89ce361accd3dd84ea0329c5d1e4 has been pushed to the review server.
It is available at http://review.typo3.org/2545

#10

Updated by Andreas Wolf over 10 years ago

  • Category deleted (Communication)
  • Target version changed from 0 to 1238
  • TYPO3 Version changed from 4.4 to 4.5

Have merged this one for master, but I think we should also have it in 4.5.

#11

Updated by Sven Teuber over 10 years ago

  • Status changed from Accepted to Resolved
  • % Done changed from 0 to 100
#12

Updated by Markus Klein over 10 years ago

Patch for 4.5 is still pending, but has enough votes!

https://review.typo3.org/2545

#13

Updated by Xavier Perseguers almost 10 years ago

  • Status changed from Resolved to Closed
#14

Updated by Susanne Moog almost 10 years ago

  • Status changed from Closed to Accepted
  • Assignee deleted (Steffen Kamper)
  • Target version deleted (1238)
  • % Done changed from 100 to 0
  • Complexity set to hard

Reopened as we had to revert the patch because of the massive performance impact it had.

We need to find another solution that does not check the whole root line for each and every page again.

#15

Updated by Riccardo De Contardi almost 5 years ago

I just wanted to be sure, but I tested it with 7.6 and I think it is still present.
My test:

1) Very basic PageTree:

[1] Home
  |
  +-[8] Login
  |
  +- [5] Test 15984
  |     |     
  |     +- [6] Test 15984_subpage
  | 
  + - [4] Sysfolder Users


2) Page [4] contains FE users and groups (a group named TEST and an user named test)
3) On page [8] there is a FELogin plugin with the following configuration:

- User Storage Page: 4
- Redirect mode: After Login (TS+Flexform) + Defined by GET/POST parameters
- Use First Supported Mode from Selection: enabled

4) Page [5] has been configured this way:

- Usergroup Access Rights: TEST
- Extend to subpages: enabled

5) Very basic TS Setup:

config.no_cache=1
page = PAGE
config.typolinkLinkAccessRestrictedPages = 8
config.typolinkLinkAccessRestrictedPages_addParams = &return_url=###RETURN_URL###&pageId=###PAGE_ID###

page.5 = HMENU
page.5.entryLevel=0

page.5.1 = TMENU
page.5.1{
 showAccessRestrictedPages = 8
 showAccessRestrictedPages.addParams = &return_url=###RETURN_URL###&pageId=###PAGE_ID###
 wrap=<ul>|</ul>
 expAll=1
 NO.wrapItemAndSub  = <li>|</li>
}

page.5.2 < page.5.1
page.10 = TEXT
page.10.data = page:title
page.10.wrap = <h1>|</h1>
page.100 < styles.content.get

Results:

1) when rendering the menu, all pages are visible (8,5,6)
2) the link of page [5]Test 15984 is

http://typo3.7.test.it:8888/index.php?id=8&return_url=index.php%3Fid%3D5%26L%3D0&pageId=5

It lands on [8] and, after login, you get redirected again to [5]

3) the link of page [6] Test 15984_subpage is http://typo3.7.test.it:8888/index.php?id=6 and, if you try to access it while logged out, you get redirected to the home page (i.e. the first accessible page in the tree). after logged, the link works as expected and brings you to the [6]

#16

Updated by Riccardo De Contardi almost 5 years ago

  • Related to Bug #26484: extend to subpages in page properties in access tab does not work correctly added
#17

Updated by Riccardo De Contardi almost 5 years ago

  • Related to Bug #78825: Wrong pid determination when opening a nested access restriced page added
#18

Updated by Riccardo De Contardi almost 5 years ago

  • Related to Bug #26484: extend to subpages in page properties in access tab does not work correctly added
#19

Updated by Riccardo De Contardi almost 5 years ago

  • Related to deleted (Bug #26484: extend to subpages in page properties in access tab does not work correctly)
#20

Updated by Susanne Moog about 4 years ago

  • Category set to Frontend
#21

Updated by Riccardo De Contardi almost 2 years ago

I've repeated my test on comment 15 on version 9.5.14

the difference is just the ID of the pages:

ID of login page = 230
ID of restricted page (and extend to subpages): 231
ID of subpage: 232

1) when rendering the menu, all pages are visible
2) the link of page [231] test15984 is

https://typo3.9.test.it:8890/login?pageId=231&return_url=%2Ftest15984&cHash=a0ecef2c1a6ea8753930b425932f95f4

clicking on it you land on the login page (230) and after that, you are redirected again to ID=231

please note that the link is not beautified.

3) the link on the page 232 is https://typo3.9.test.it:8890/supertest15984/test15984-subpage

3.1 Access it while not logged in: Page not found error is shown with the message:

Page Not Found
Reason: Subsection was found and not accessible

3.2 Access it after logged in: works like a normal link

I repeated the same test on latest master (10.4.0-dev) and the results are the same except

1) the redirection does not seem to work
2) the message for the page not found is slightly different:

Page Not Found
The page did not exist or was inaccessible. Reason: Subsection was found and not accessible

Also available in: Atom PDF