Bug #20494
closedAccess-restriction behaves identical for non-recursive/recursive
0%
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)
Updated by Niels Fröhling over 15 years ago
Possibly related to behaviour described in #0011163
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.
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)
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.
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!