Closed Zellwerker closed 1 year ago
I have found the place which generates the error.
// This is where it happens.
EXT:flux\Classes\Integration\Configuration\SpooledConfigurationApplicator.php -> spoolQueuedContentTypeRegistrations()
$GLOBALS['TYPO3_REQUEST'] = $GLOBALS['TYPO3_REQUEST'] ?? (new ServerRequest())->withAttribute(
'applicationType',
defined('TYPO3_REQUESTTYPE') ? constant('TYPO3_REQUESTTYPE') : SystemEnvironmentBuilder::REQUESTTYPE_FE
);
I don't really understand the context. Is this a new security feature of TYPO 12.4 LTS?
Does anyone have an idea how to solve this?
Hello @Zellwerker I think the solution should be like this and it works on my local Thank you.
Hello,
I can confirm this issue - the fake server request stops the loading process of the TYPO3 backend:
I also do not understand why chrome lists the request for "JS" within the network panel (instead of "Doc").
The problem occured on an existing project, but also on a clean installation with: ddev apache composer PHP 8.1 / 8.2 (makes no difference) TYPO3 12.4.2 flux@dev vhs@dev helhum/typo3-console
@NamelessCoder, this may be the only/biggest problem from preventing flux to run with TYPO3 12.4. Can you tell when it would be possible for you to take a closer look at the problem?
Or maybe you could give us a hint, what may be causing this issue? Unforunately I am clueless where to start fixing this... Could it be a problem with the Content Security Policity introduced in TYPO3 12.3? https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/ContentSecurityPolicy/Index.html (security.backend.enforceContentSecurityPolicy
is disabled in my setup)
Hello @Zellwerker I think the solution should be like this and it works on my local Thank you.
Just try as mentioned, and the error disapear :
$GLOBALS['TYPO3_REQUEST'] = (new ServerRequest())->withAttribute( 'applicationType', SystemEnvironmentBuilder::REQUESTTYPE_BE );
Dont know, if it break something anywhere, will make a feedback if its the case.
@Apen
It's FE
for a reason in the emulated request - yes, it most certainly will break something elsewhere. It will result in the Can't determine default controller for plugin
error in FE.
@kraemer-igroup
Can you tell when it would be possible for you to take a closer look at the problem?
I'm working on it but I can tell you that this is NOT easy, because the TYPO3 core just keeps shifting things around with the request and handling thereof, in every major version since 9. Finding a solution that actually works for all of those, even with a version detection and different processing for each, is posing a major problem. I'm doing my best but it's like walking through a mine-field.
I'm honestly quite dissatisfied with the way this request situation is being handled. There's simply no way to discern if FE or BE until basically all essential hooks and events have already been dispatched, yet many core classes (including API!) assumes one or the other context - which is why we even have this situation now.
Just FYI: the solution around all of this may end up being a complete rewrite of how Flux processes things, from a "load during runtime" to a "generate to static" kind of approach; requiring you to take manual action to generate assets whenever the composition of available page templates and content types changes. Flux is just so severely affected by every decision made around the request internals in TYPO3 - they make what seems like a minor change, everything breaks.
@NamelessCoder Thank you for your detailed feedback! Great that you're already on it, but I'm sorry to hear that it's such a big problem. I hope you can find a solution 🤞 Let me know if there is anything I can do to support you, for example testing.
@Apen @kraemer-igroup I've implemented a facade for ConfigurationManager which is capable of switching between Frontend and Backend ConfigurationManagers on-the-fly. If nothing else, this removes the Can't determine default controller for plugin
problem.
@Zellwerker The emulated request Flux uses while bootstrapping is unset immediately afterwards and replaced by whichever value the TYPO3_REQUEST
global had, whether it was a request instance or null. It should no longer be capable of affecting the request in a way that would cause issues in the backend.
And to all of you: please retry your installations with the most recent dev-development
and let me know if it solves the problem. I was never able to reproduce this "HTML delivered as JS" problem so I'm kind of working blind here.
Hello @NamelessCoder Thank you for your input. I have installed the latest development version and the problem seems to be solved. Thank you.
@NamelessCoder I can confirm the "HTML delivered as JS" problem is also solved 🎉 Thank you very much for your work, I'm glad you could work out a workaround for this!
Thanks for the feedback guys - closing the issue as "solved" :)
[heart] Amine SAADAOUI reacted to your message:
From: Claus Due @.> Sent: Wednesday, August 23, 2023 9:14:08 AM To: FluidTYPO3/flux @.> Cc: Amine SAADAOUI @.>; Comment @.> Subject: Re: [FluidTYPO3/flux] MIME type ('text/html') is not executable, (Issue #2082)
Thanks for the feedback guys - closing the issue as "solved" :)
— Reply to this email directly, view it on GitHubhttps://github.com/FluidTYPO3/flux/issues/2082#issuecomment-1689587560, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BAAOUEAFPJ6R7PUBYEZI3NTXWXCWBANCNFSM6AAAAAAXYAYL54. You are receiving this because you commented.Message ID: @.***>
Hello,
TYPO3 12.4.0 LTS Flux 9.7.2@dev
After a fresh TYPO3 12.4.0 installation and adding the EXT:flux with composer the backend does not work anymore.
The following error message is displayed in the browser console:
Refused to execute script from 'https://domin.tld/typo3/main?token=5e03a7590f2e38a32704f819bc2d35163e43503f' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.