Bug #105866
openBackend user access rights overrule frontend user access rights
0%
Description
I have a website with restricted FE user access to most pages.
If there is no backend user logged in, then the restriction works as expected. My FE user can access all the pages where access is granted.
When there is also a backend user logged in into the TYPO3 backend (using the same browser; the FE user is still logged in), then only the frontend pages to which the backend user has access / edit rights in the TYPO3 backend can be viewed in the frontend.
This means that the frontend is not usable for the frontend user as long as he is simultaneously logged into the TYPO3 backend.
This TYPO3 website was migrated from an older version, where this problem did not exist.
The error is caused by the class vendor/typo3/cms-frontend/Classes/Middleware/TypoScriptFrontendInitialization.php
Since version 12 there is a check, which did not not exist before:
// Check if backend user has read access to this page.
if ($this->context->getPropertyFromAspect('backend.user', 'isLoggedIn', false)
&& $this->context->getPropertyFromAspect('frontend.preview', 'isPreview', false)
&& !$GLOBALS['BE_USER']->doesUserHaveAccess($controller->page, Permission::PAGE_SHOW)
) {
return GeneralUtility::makeInstance(ErrorController::class)->accessDeniedAction(
$request,
'ID was not an accessible page',
$controller->getPageAccessFailureReasons(PageAccessFailureReasons::ACCESS_DENIED_PAGE_NOT_RESOLVED)
);
}
So if a backend user is logged in and the page is in preview mode, then the access to a page is based on the backend user access rights.
I would suggest to adjust this to:
// Check if backend user has read access to this page.
if ($this->context->getPropertyFromAspect('backend.user', 'isLoggedIn', false)
&& $this->context->getPropertyFromAspect('frontend.preview', 'isPreview', false)
&& !$GLOBALS['BE_USER']->doesUserHaveAccess($controller->page, Permission::PAGE_SHOW)
) {
$this->context->unsetAspect('frontend.preview');
}
With that change the preview aspect is unset and the page can be accessed as expected.
Updated by Garvin Hicking 21 days ago
- Related to Task #97176: Move BE_USER check of TSFE into middleware added
Updated by Garvin Hicking 21 days ago
- Related to Task #102856: Streamline TypoScriptFrontendItitialization added
Updated by Garvin Hicking 21 days ago
- Category set to Frontend
- Status changed from New to Needs Feedback
This check was introduced with https://review.typo3.org/c/Packages/TYPO3.CMS/+/73905 - but then again for v13 changed again with https://review.typo3.org/c/Packages/TYPO3.CMS/+/82452
Could you see if the issue persists for you with the v13 version? That would help to decide how to proceed.
However: I do think there are more places in the frontend evaluation that will take a Backend-User account into consideration, if a login exists, and overrides that. It is best practice to test frontend login-related functionality always in an incognito tab or with a second browser, because a backend user login changes a lot in frontend context also related to caching.
Updated by cosmoblonde GmbH 21 days ago
It will take me some time to have a v13 version setup for testing. Sorry for a delay...
However looking at the code in Classes/Middleware/TypoScriptFrontendInitialization.php, it seems that the lines causing the issue have been removed, so I assume it will not be an issue in v13.
And yes, I am aware that testing frontend login-related functionality should be disconnected from any backend login. But in that specific case, it was not a frontend-login test but a real use case: Having hundreds of users with BE accounts having very resticted access rights to the BE and FE accounts with reading access to many more pages then they are allowed to edit with their BE accounts. Additionally, users are logged in via SSO and stay logged in. So a real separation by using incognito tabs is no option.
My suggested change will solve the problem for my use cases. Is this something you can implement in v12?
Updated by Garvin Hicking 21 days ago
Thanks, I understand your scenario better now.
With t3v13 it's become easier to replace the affected code with a custom middleware.
V12 is now in "priority bugfix" mode, and this change may affect how other instances work, so honestly I'm it sure if v12 would receive a general patch level release for it. This is not my personal decission to make, I'll bring it up in the team after the holidays.
(Please feel free to remind/ping me if it gets "lost" in the year turnaround 😅)
Updated by cosmoblonde GmbH 5 days ago
This is a little reminder for this "priority bugfix". ;-)
It would be good to know if a fix is planned in the near future.
Thank you!
Updated by Garvin Hicking 5 days ago
Hi!
Did you get the chance to test this with v13? As mentioned this would affect the road to take... :-)
Thanks!
Updated by cosmoblonde GmbH 3 days ago
Hi!
we have now tested that scenario with v13 and all works as expected.
So this is a v12 bug "only".
In the meantime we have discovered that this problem affects several of our TYPO3 projects and does not seem to be an usual setup for bigger sites having lots of BE and FE users. So I think a v12 fix is strongly required.
Thank you!