Project

General

Profile

Actions

Bug #20494

closed

Access-restriction behaves identical for non-recursive/recursive

Added by Niels Fröhling over 15 years ago. Updated about 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
Category:
-
Target version:
-
Start date:
2009-05-22
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.3
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

There is no distinction in behaviour if you restrict a page to a FE-group and mark "incl. sub-pages" or not. In both cases you get thrown down to the next un-restricted page, dispite the sub-page not being restricted.

Either there is just one option possible (incl. sub-pages) and the option need to be removed and the icon always indicate recursivity, or the case of non incl. sub-pages (in presence of un-restricted pages under that tree) is broken.

(issue imported from #M11171)


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #20396: Simulating frontend user groups via admin panel does not workClosedOliver Hader2009-05-06

Actions
Actions #1

Updated by Niels Fröhling over 15 years ago

Possibly related to behaviour described in #0011163

Actions #2

Updated by Niels Fröhling over 15 years ago

Okay, just to describe the most simplest way to reproduce this:

1) make a page, access-restriction is on a specific FE-group, it is NOT "incl. sub-pages"
2) create another page as a child, do NOT protect it
3) log out of the typo
4) try to jump directly onto the child-page

What happens is you get thrown out. There is no distinction between incl. or not.

Actions #3

Updated by Niels Fröhling over 15 years ago

Okay, we tracked the error down to one of the pages inbetween being "BE-user page" ...

35: FE-user bereich, NICHT recursiv
`- 36: BE-user bereich
`- 38: nicht geschützt

38 kann nicht erreicht werden (ausser von admin)

Actions #4

Updated by Niels Fröhling over 15 years ago

So okay, I'm very sorry for the confusion, I have difficulties to describe the issue as it depends on several factors, and it is slippery like fish; so I hope you bear with me. I made a protocol of the behaviour of the forementioned structure:

35: FE-user area, NOT recursive
`- 36: BE-user section
`- 38: regular page

These pages behave like the following (with a debug-echo in checkRootlineForIncludeSection, which is the only function I found which actually handles doktype==6):

--------------------------------------------------------------------------------
--- Case one, accessing a page which is "BE-User Section"

Pages-cache deleted, admin-user logged in, load page:

- checkRootlineForIncludeSection(): this->beUserLogin is 1
- Content visible

Admin-user logged out, reload same page:

- checkRootlineForIncludeSection(): this->beUserLogin is 0
- Content visible!!!

Other BE-user logged in, reload same page:

- checkRootlineForIncludeSection(): this->beUserLogin is 1
- checkRootlineForIncludeSection(): this->beUserLogin is 0
- Content visible

--------------------------------------------------------------------------------
--- Case two, accessing a page which is child of a "BE-User Section", but
--- itself is a regular page

Pages-cache deleted, admin-user logged in, load page:

- checkRootlineForIncludeSection(): this->beUserLogin is 1
- Content visible

Admin-user logged out, reload same page:

- checkRootlineForIncludeSection(): this->beUserLogin is 0
- Content visible!!!

Other BE-user logged in, reload same page:

- checkRootlineForIncludeSection(): this->beUserLogin is 1
- checkRootlineForIncludeSection(): this->beUserLogin is 0
- Content visible
--------------------------------------------------------------------------------

Okay, so I believe the "BE-user section" suffers from caching-artefacts, I compared the code with down to 4.0.4 and it didn't change. So my guess is that page-handling & caching changed, ignoring the case of doktype==6.

All the problems I mentioned here occured in relation to a "BE-user section", some don't occur anymore, possibly because of cache-side effects too.

So much about that. Sorry it's just super-weird behaviour, I can give access to a Typo3-SVN installation which behaves like that, if somebody wants to dig into the real case.

Actions #5

Updated by Niels Fröhling over 15 years ago

With the last SVN (27 or 28 of may) I get the standard "error" message about re-login from Typo3 in a BE-user section. The page no longer is cached and shown on invokation by direct link.

If you did change something in respect the issue may be solved!

Actions #6

Updated by Niels Fröhling about 15 years ago

Close please, solved (SVN).

Actions #7

Updated by Benni Mack about 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF