-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BackendUserHandler breaks workspace #535
Comments
Looks like falling back on |
Default requests won't have a workspace id. That will lead to TYPO3 defaults -99 id. That in turn will lead to being in preview mode once a backend user is provided within context. We therefore cover the default and turn it into live workspace which could be the expected default. Resolves: TYPO3#535
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. |
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. |
Sure, but will take some time as I moved forward and work on other areas right now … |
Default requests won't have a workspace id. That will lead to TYPO3 defaults -99 id. That in turn will lead to being in preview mode once a backend user is provided within context. We therefore cover the default and turn it into live workspace which could be the expected default. Resolves: TYPO3#535
@sbuerk done: https://review.typo3.org/c/Packages/TYPO3.CMS/+/82715 You can debug within The provided PR fixes most of the issues for 12.4 and main. |
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. |
Default requests won't have a workspace id. That will lead to TYPO3 defaults -99 id. That in turn will lead to being in preview mode once a backend user is provided within context. We therefore cover the default and turn it into live workspace which could be the expected default. Also we add missing initialization for backend user. Resolves: TYPO3#535
The given PR solves the issues and makes https://review.typo3.org/c/Packages/TYPO3.CMS/+/82715 pass. |
Default requests won't have a workspace id. That will lead to TYPO3 defaults -99 id. That in turn will lead to being in preview mode once a backend user is provided within context. We therefore cover the default and turn it into live workspace which could be the expected default. Also we add missing initialization for backend user. Resolves: TYPO3#535
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:
With the following database fixture:
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
The text was updated successfully, but these errors were encountered: