Problem/Motivation
The global "Text area" that can be added to footer, header or no-result areas is not meant to fully support twig. Background: https://www.drupal.org/node/2805173#comment-11814857. It does actually support twig when "Use replacement tokens from the first row" is checked and result count > 0. I would like full twig support. why using a powerfull language like twig only for replacing tokens? row "Custom text" fields explicitly support twig, why not header "text area" fields?
I'm curious for arguments why "Text area" supports twig conditionally, but is only designed to parse tokens?
Proposed resolution
- Let the "Text area" always parse twig, or
- Add a new "Custom area" that extends "Text area" class "TokenizeAreaPluginBase" and adds twig parsing.
The latter I build as a small custom module, can make a patch of that.
Comments
Comment #2
keesje CreditAttribution: keesje at Sogeti for RIVM commentedComment #3
dawehnerI was running into this the other way as I was totally expecting that we support that.
Comment #4
andypost@dawehner twig is for templates, we do not allow use twig engine for user input (security reasons, same as php filter that allows delete nodes)
So closing as related #2805173-10: importing a view with a text area containing Twig markup shows the raw Twig
Comment #5
andypostMisunderstanding comes from ”twig syntax of tokens"
https://www.drupal.org/node/2404639
https://www.drupal.org/node/2566251
Comment #6
andypost>>Major because closes potential data-loss vulnerabilities. Not critical because this requires admin-level permissions (access to Twig templates) to exploit this.
Comment #7
andypostComment #8
keesje CreditAttribution: keesje at Sogeti for RIVM commentedHi @andypost, can you please explain why this (allow use twig engine on "text area") is a security threat and not on a "Custom text" field? thanks.
Comment #9
andypostI think both are, because #2513266: Twig templates can call delete() on entities and other objects
So I think we should reconsider if "custom text" row allows to use twig
Comment #10
keesje CreditAttribution: keesje at Sogeti for RIVM commentedThanks, I agree.
I didnt realise twig was that powerful, capable of deleting entities.
There are strong cases though for using code-like logic in a views header. views_php module popularity could be proof of that.
Comment #11
keesje CreditAttribution: keesje as a volunteer commentedReading the issue #2513266 tread you linked,
I get the impression that this security issue is fixed in current core release. Looking at the code, implementing class "TwigEnvironment" from the core "Drupal\Core\Template" namespace should be safe for user input?
Comment #12
silverham CreditAttribution: silverham at EY Digital commentedOpening to get feedback on issue.
Comment #13
Chi CreditAttribution: Chi commentedEditing Twig templates by untrusted users will never be safe. That's because Drupal render arrays are too powerful. Aside from that third party Twig extensions can enable unrestricted functionality. Think of PHP filter in Twig Tweak. However, given that Twig is already allowed for other field types enabling it for textareas won't make the site less secure. For the purpose of consistency we should either enable it on all text fields in Views UI or remove it completely.
Comment #14
Chi CreditAttribution: Chi commentedThe better approach could be creatiing a separate Twig enviroment with strict sandbox policies and without support for render arrays. That could be usefull not only in Views UI but in many other places. For example in email templates.