Isolate interpreter scope when rendering value in striptags filter #1068
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A bit of a complex bug with a simple solution.
We are seeing an issue where the execution of the striptags value on a String is causing the whole template to fail. I have narrowed it down to the fact that in the striptags filter we execute the Jinjava in the String before escaping the value.
This execution has existed since the initial commit in the repo ee1a3a9
What was missed is that this execution is not scoped. Meaning that any Jinjava inside the
striptags
argument can pollute the outer context and break the overall rendering. This seems to have been a problem in the early days of Jinjava resulting in some filters implementing the isolated scope pattern (see 1e5f17b) but it appears this filter was missed in that initial fix from 8 years ago.So here I am 8 years later. We have not come across this issue until recently when a common context variable that commonly has
striptags
applied to it started including Jinjava frequently. This included Jinjava is polluting the outer scope and causing rendering issues.