Project

General

Profile

Actions

Bug #89633

closed

BE user in FE context

Added by Roman Büchler over 4 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Backend API
Target version:
-
Start date:
2019-11-11
Due date:
% Done:

0%

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

Description

When using the context API to retrieve information regarding a logged in BE user the information is just valid in case a admin-be-user is logged in. The following just works for admin-be-users:

$context = GeneralUtility::makeInstance(\TYPO3\CMS\Core\Context\Context::class);
$beUserLoggedIn = $context->getPropertyFromAspect('backend.user', 'isLoggedIn');
Actions #1

Updated by Benni Mack over 4 years ago

  • Status changed from New to Needs Feedback

Hey Roman,

thanks for your report. I reproduced this issue and cannot confirm your issue. However, where exactly in the frontend request do you use this code? If you use this in a "cacheable" object, and you first hit the page without a proper backend user, it is cached as "not logged in" (e.g. in a USER plugin or cacheable extbase action).

Actions #2

Updated by Roman Büchler over 4 years ago

Benni Mack wrote:

Hey Roman,

thanks for your report. I reproduced this issue and cannot confirm your issue. However, where exactly in the frontend request do you use this code? If you use this in a "cacheable" object, and you first hit the page without a proper backend user, it is cached as "not logged in" (e.g. in a USER plugin or cacheable extbase action).

Hello Benni

Thank you very much for looking into this. The code is used in a cacheable controller action. The uncached usage is just desired when previewing the record. For this the following TSConfig is used (understanding that additionalGetParameters triggers the usage from no_cache=1):

TCEMAIN.preview {
    <table name> {
        additionalGetParameters {
            <plugin name> {
                action = show
                controller = Job
                preview = 1
            }
        }
        useCacheHash = 0
    }
}

To get the BE user the following is used now:

$className = \TYPO3\CMS\Core\Authentication\BackendUserAuthentication::class;
/** @var \TYPO3\CMS\Core\Authentication\BackendUserAuthentication $backendUser */
$backendUser = GeneralUtility::makeInstance($className);
$backendUser->start();
if (isset($backendUser->user['uid']) && $backendUser->user['uid']) {
    $beUserLoggedIn = true;
}
Actions #3

Updated by Benni Mack about 4 years ago

Hey Roman,

hmm, I still cannot reproduce this issue. Within an extbase controller (cached/uncached). Can you share more details on the plugin / controller-action code?

Actions #4

Updated by Roman Büchler about 4 years ago

Hi Benni

The issue was related to the non-admin user not having access to the page beeing shown upon previewing the record beeing edited in a sys folder the non-admin user had access to:

[root]
  |
  |--- [sys folder] ...with records beeing edited. The be user has access to this folder.
  |
  |--- [page] ...where plugin to show the record is located. The be user doesn't have access to this page

This lead to the situation that the user could edit the records in the sys folder and view the result in the frontend on the page the user doesn't have be-access. In the PageResolver middleware $GLOBALS['BE_USER'] was unset due to the user not having access to the page that was viewed in the frontend.

\TYPO3\CMS\Frontend\Middleware\PageResolver:

public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
    ...
        if ($this->controller->isBackendUserLoggedIn() && !$GLOBALS['BE_USER']->doesUserHaveAccess($this->controller->page, Permission::PAGE_SHOW)) {
            unset($GLOBALS['BE_USER']);
    ...

This is quite special use case and could be solved easyly by using the BackendUserAuthentication class in the extbase controller hence this issue could be closed.

Thank you again for helping!

Actions #5

Updated by Riccardo De Contardi about 4 years ago

  • Status changed from Needs Feedback to Closed

@Roman Büchler thank you for your quick and nice reply; I close this issue for now;

if you think that it is the wrong decision, please reopen it or ping me on Slack and I'll do.

Best regards.

Actions #6

Updated by Benni Mack about 4 years ago

Hey Roman,

now i see - the main issue is the sysfolder - that the Frontend says "nope, cannot access this one"!

Actions #7

Updated by Roman Büchler about 4 years ago

Hi Benni,

Isn't it rather that the backend says "this BE user can't access this page in the BE (the one that doesn't has FE restrictions) hence we don't provide information regarding this BE user when rendering the page"?

Actions

Also available in: Atom PDF