Fluid
Fluid copied to clipboard
TYPO3
!!![WIP][FEATURE] Update escaping behavior
@helhum @kitsunet @bwaidelich @NamelessCoder i added a small doc file that outlines the expected/intended escaping behavior:
https://github.com/mneuhaus/Fluid/blob/feature/escaping/doc/FLUID_ESCAPING_BEHAVIOR.md
this changeset includes all changes to conform to this intended behavior. feedback and suggestions are welcome of course :)
I just hat a problem with escaping. In my case extension_builder uses fluid templates to build php code ( https://github.com/FriendsOfTYPO3/extension_builder/issues/24 ).
There i had a idea: Escaping behaviour should be dependent on the template filetype: .html -> escape as planned .js -> excape for use in js strings? .anythingelse -> no escaping?
Maybe make the escaping function exchangeable dependent on filetype? This may not be in the scope of this issue - and it´s not fully thought through - just an idea ..
There i had a idea: Escaping behaviour should be dependent on the template filetype: .html -> escape as planned .js -> excape for use in js strings? .anythingelse -> no escaping?
Not to dismiss the idea, but IMHO that probably shouldn't be a part of Fluid itself - but rather, a choice of the framework that implements Fluid. To achieve this, inspect $this->templatePaths->getFormat() in an overridden https://github.com/TYPO3/Fluid/blob/master/src/Core/Rendering/RenderingContext.php#L345 which avoids adding the Escape interceptor when format is XYZ (and I strongly suggest you make this a configurable option, which formats cause no escaping!) - and make sure that in setControllerContext() (TYPO3 only!) you call setFormat($context->getRequest()->getFormat()) (I think this already happens but it is required; not passing the desired format and expecting it to be guessed from extension of template filename means the detection happens too late for it to affect the escaping behavior).
@kitsunet ping ;) https://github.com/mneuhaus/Fluid/blob/feature/escaping/doc/FLUID_ESCAPING_BEHAVIOR.md
Sorry for being late, but the proposed behavior looks good 👍 Thanks a lot. Will try to get a full review done as well.
@mneuhaus can you rebase? I also wonder if we can find a way around making "callInterceptors()" public (or maybe we add a "@internal" comment to it?)
Also: What's missing to get this change in? (still WIP)
Also: What's missing to get this change in? (still WIP)
From my perspective, I'd like to preserve the ArgumentDefinition as unmutable and avoid the related public API change. And if there is a way to do the intercepting differently (as in, do it like the other interception instead of delegating it to the ViewHelperNode) I'd prefer that.
I also agree the suggested behavior is good so all we need to do now is find the ideal implementation for that.
Hey. I hope it's ok to close here: There is no current known sec issue with escaping behavior anymore in current fluid, and I think parts of this PR found their way into Fluid the one or the other way meanwhile. I something is still open, we should restart with a new PR.
