Bug #95580
closed
Wrong ConfigurationManager in Frontend Ajax call
0%
Description
I use in some of my extension Ajax calls in the frontend, but with TYPO3 11.5 I got the error message that my controller is not allowed for the extension.
After some searching I have found that Configuration uses the BackendConfigurationManager instead the FrontendConfigurationManager.
I did not find anything if I have to change something in my configuration, or if it's a bug.
The typoscript configuration looks like:
lib.tx_myextension.conf = USER
lib.tx_myextension.conf {
userFunc = TYPO3\CMS\Extbase\Core\Bootstrap->run
extensionName = MyExtension
pluginName = Pi1
vendorName = MyVendor
settings < plugin.tx_myextension.settings
}
tx_myextension_ajaxCall = PAGE
tx_myextension_ajaxCall {
typeNum = 424342
config {
disableAllHeaderCode = 1
disablePrefixComment = 1
xhtml_cleaning = 0
no_cache = 1
replace = 1
}
10 < lib.tx_myextension.conf
}
Updated by Markus Pircher almost 3 years ago
Seems to have another reason: #96371
Updated by Benni Mack almost 3 years ago
- Related to Bug #96371: Strange error with custom Frontend AuthenticationService in TYPO3 11 TLS added
Updated by Christin Gmeiner over 2 years ago
This is also a serious problem when using an early frontend middleware which uses extbase repositories (injected through DI).
If the middleware is executed before typo3/cms-frontend/prepare-tsfe-rendering then the global Request Object $GLOBALS['TYPO3_REQUEST'] is not set and therefore the Backend Configuration Manager is used.
This should be fixed, especially if the middleware is created explicitely as frontend middleware, the configuration manager should then resolve to the frontend configuration manager.
The main problem is that the $GLOBALS['TYPO3_REQUEST'] object is set too late (in PrepareTypoScriptFrontendRendering middleware). Currently, I overcome this problem with a 'helper' middleware registered early in the frontend, which sets the request object:
public function process(ServerRequestInterface $request, RequestHandlerInterface $handler): ResponseInterface
{
$GLOBALS['TYPO3_REQUEST'] = $request;
return $handler->handle($request);
}
Updated by Andreas Wolf over 1 year ago
@Christin Gmeiner I can confirm that this fix works, I just implemented it myself and now the FE plugin (from EXT:solr) is working as expected.
Updated by Christian Kuhn 3 months ago
- Status changed from New to Closed
Hey.
First, it sounds as if the original issue creator found the reason and solved the issue differently.
Secondly, about "extbase in early middlewares". This is - by nature - not directly supported by TYPO3: Extbase depends on TypoScript configuration, so extbase is designed to be called after TypoScript has been set up by middlewares. To put it simply: Extbase expects to be called as ContentObjectRenderer plugin. When Extbase is fired more early, TypoScript tends to not be ready. $GLOBALS['TYPO3_REQUEST'] is a b/w compat layer that will vanish (we're actively working on reducing usages in core, $GLOBALS['TYPO3_REQUEST'] will vanish mid-term). When an instance decides to configure Extbase to be run earlier than "naturally" from ContentObjectRenderer - for instance in an early middleware, then the instance has to take care of proper Extbase bootstrap (which is not trivial) on it's own. This is not supported by TYPO3 directly, and we won't fix issues in this area: Such a case is perceived as a misuse from TYPO3 framework point of view.
Closing here for now, hope this is ok.