Bug #15984

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

Added by Wolfgang Sassik over 13 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%

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)

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


Related issues

Related to TYPO3 Core - Bug #22860: typolinkLinkAccessRestrictedPages_addParams doesn't work on restricted subpages Closed 2010-06-10
Related to TYPO3 Core - Bug #26484: extend to subpages in page properties in access tab does not work correctly Accepted 2011-04-29
Related to TYPO3 Core - Bug #78825: Wrong pid determination when opening a nested access restriced page New 2016-11-28
Precedes TYPO3 Core - Bug #32756: Massive Memory Leak in 4.5.8+ / 4.6 Closed 2011-12-21

Associated revisions

Revision 94feeb25 (diff)
Added by Sven Teuber over 8 years ago

[BUGFIX] showAccessRestrictedPages doesn't replace links to restricted subpages

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

Change-Id: I98ea123ccdf1e370f28103546191b0a7234076f4
Resolves: #15984
Reviewed-on: http://review.typo3.org/1186
Reviewed-by: Susanne Moog
Tested-by: Susanne Moog
Reviewed-by: Stefan Neufeind
Tested-by: Stefan Neufeind
Reviewed-by: Christian Mueller
Reviewed-by: Georg Ringer
Reviewed-by: Andreas Wolf
Tested-by: Andreas Wolf

Revision 3dd43f60 (diff)
Added by Sven Teuber almost 8 years ago

[BUGFIX] showAccessRestrictedPages doesn't replace links to restricted subpages

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

Change-Id: I459aa01a8aba89ce361accd3dd84ea0329c5d1e4
Resolves: #15984
Reviewed-on: http://review.typo3.org/2545
Reviewed-by: Georg Ringer
Tested-by: Georg Ringer
Reviewed-by: Stefan Neufeind
Reviewed-by: Markus Klein
Tested-by: Markus Klein
Reviewed-by: Andreas Wolf
Tested-by: Andreas Wolf

History

#1 Updated by Sascha Egerer over 9 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 9 years ago

Just stumbled over this bug in recent 4.4 SVN version.

#3 Updated by Chris topher over 9 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 9 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 9 years ago

Provided patch, will send it to core list now

#7 Updated by Mr. Hudson over 8 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 8 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 8 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 8 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 8 years ago

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

#12 Updated by Markus Klein almost 8 years ago

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

https://review.typo3.org/2545

#13 Updated by Xavier Perseguers over 7 years ago

  • Status changed from Resolved to Closed

#14 Updated by Susanne Moog over 7 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 over 2 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 over 2 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 over 2 years ago

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

#18 Updated by Riccardo De Contardi over 2 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 over 2 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 almost 2 years ago

  • Category set to Frontend

Also available in: Atom PDF