Skip to content

BackendUserHandler breaks workspace #535

Open

Description

@DanielSiepmann

What are you trying to achieve?

A frontend request with enabled backend user.
As we extend admin panel and want to cover that with functional tests executing frontend requests.

What do you get instead?

We receive a 404 due to BackendUserHandler class which breaks the expected workspace aspect.

How to reproduce the issue?

Execute the following test:

        $request = new InternalRequest();
        $request = $request->withPageId(1);
        $request = $request->withLanguageId($languageUid);
        $requestContext = new InternalRequestContext();
        $requestContext = $requestContext->withBackendUserId(1);
        $html = (string) $this->executeFrontendSubRequest($request, $requestContext)->getBody();

With the following database fixture:

<?php

declare(strict_types=1);

return [
    'pages' => [
        [
            'uid' => 1,
            'pid' => 0,
            'title' => 'Page with uid 1 below 0',
            'deleted' => 0,
            'backend_layout' => 'pagets__21',
            'slug' => '/start',
        ],
    ],
    'be_users' => [
        [
            'uid' => 1,
            'pid' => 0,
            'tstamp' => 1366642540,
            'username' => 'editor',
            // The actual password is: password
            'password' => '$1$tCrlLajZ$C0sikFQQ3SWaFAZ1Me0Z/1',
            'admin' => 0,
            'disable' => 0,
            'starttime' => 0,
            'endtime' => 0,
            'options' => 0,
            'crdate' => 1366642540,
            'workspace_perms' => 1,
            'deleted' => 0,
            'TSconfig' => null,
            'lastlogin' => 1371033743,
            'workspace_id' => 0,
            // Necessary to allow user to access this page.
            'db_mountpoints' => 1,
            // Necessary to open admin panel.
            'uc' => serialize([
                'AdminPanel' => [
                    'display_top' => true,
                ],
            ]),
        ],
    ],
];

Additional information you would like to provide?

It looks like https://github.com/TYPO3/testing-framework/blob/8.0.8/Resources/Core/Functional/Extensions/json_response/Classes/Middleware/BackendUserHandler.php doesn't properly set the workspace property until one explicitly provides it within the test. Leading to keeping the -99 fallback which in turn will lead to other follow up issues as the system status is wrong.

That will lead to the expectation the user is in preview mode, which will trigger all kind of access checks for a public page.

Specify some data of the environment

  • TYPO3 testing framework version: 8.0.8
  • TYPO3 version: 12.4.10
  • TYPO3 installation type: composer
  • PHP version: 8.2.14
  • Web server used + version: None
  • Operating system: Ubuntu

Activity

  1. DanielSiepmann commented on Jan 25, 2024

    @DanielSiepmann
    ContributorAuthor

    Looks like falling back on 0 if not provided would solve the issue.

  2. added a commit that references this issue on Jan 25, 2024
    d48c23e
  3. DanielSiepmann commented on Jan 25, 2024

    @DanielSiepmann
    ContributorAuthor

    Looks like the middleware misses some more proper initializations, e.g. UserTSconfig seems to be missing as well.

    Looks like those two calls should be added as well:

                $backendUser->initializeUserSessionManager();
                $backendUser->fetchGroupData();

    And UC is also not unpacked … And the necessary method is now protected and therefore not available from the middleware.

  4. sbuerk commented on Jan 25, 2024

    @sbuerk
    Collaborator

    Can you provide a full testcase showing the issue ? (failing) - can be done as a WIP core patch.

    TBH - not getting how parts are looking in the test setup not mentioned in the post/thread.

  5. DanielSiepmann commented on Jan 25, 2024

    @DanielSiepmann
    ContributorAuthor

    Sure, but will take some time as I moved forward and work on other areas right now …

  6. added a commit that references this issue on Jan 30, 2024
    36a137f
  7. DanielSiepmann commented on Jan 30, 2024

    @DanielSiepmann
    ContributorAuthor

    @sbuerk done: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82715 You can debug within typo3/sysext/adminpanel/Classes/Utility/StateUtility.php to see that the TSconfig is not provided, due to missing intialization. This is called from e.g. typo3/sysext/adminpanel/Classes/Middleware/AdminPanelInitiator.php.

    The provided PR fixes most of the issues for 12.4 and main.
    But I couldn't find a way to unpack the uc of the user. That prevents to "open" the admin panel, the 2nd test.

  8. DanielSiepmann commented on Jan 30, 2024

    @DanielSiepmann
    ContributorAuthor

    Another proper solution might be to replace the provided middleware of testing framework with an authenticator which checks the provided request context and auths the user, allowing TYPO3 to work as usual? But I didn't give it a try yet.

  9. added a commit that references this issue on Feb 12, 2024
    3297eff
  10. DanielSiepmann commented on Feb 12, 2024

    @DanielSiepmann
    ContributorAuthor

    The given PR solves the issues and makes https://review.typo3.org/c/Packages/TYPO3.CMS/+/82715 pass.

  11. added a commit that references this issue on Feb 21, 2024
    c1cf194
  12. added a commit that references this issue on Nov 29, 2024
    eb72b0a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions