Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.#2513266: Twig templates can call delete() on entities and other objects added the ability to whitelist what object methods were allowed to be called from a Twig template. These whitelists can be customized in a site's settings.php file by adding the appropriate $settings[' ... '] variable. This requires modules that need access to new method names to include extra documentation explaining how this is done and could lead to less secure code if site builders accidentally replace the default values instead of adding to them. See the original change record for more details.
Allowing modules and theme's to implement a service to handle white- or blacklisting a given method call would solve this. Similar to the node access ssytem, a service could respond ALLOW/DENY/NEUTRAL, allowing core to maintain it's current list while a module could add additional method names or have even greater restrictions in situations where Twig templates may come from untrusted sources (eg: user generated).
Comments
Comment #2
mikeker CreditAttribution: mikeker as a volunteer commentedAnother, more disruptive, option is to use ViewModels so that a read-only copy of any object is passed to the Twig template. That would eliminate the need for a Twig Sandbox policy.
Comment #11
fergusong CreditAttribution: fergusong as a volunteer commentedI agree that having custom modules specific configuration information
in settings.php is undesirable. The workaround I use is
to define a 'marker interface' (named TwigAccess) and
to allow that class in the settings.php. A 'marker interface'
is an PHP interface that does not specify any methods. Classes I intend for
twig access implement TwigAccess and be allowed access with
no further ado.
Two issues come to mind.
1. My app has a base module where I can define the shared interface
once and for all. Just the one class is added to settings.php when
the base module is installed.
Many apps won't have such a base module. Perhaps it would make sense to
add the marker interface to core?
2. Some people dislike marker interfaces on principle.
It does feel a little dodgey; but better than relying on settings.php.
Anyway, the TwigAccess interface approach solves my problem, might be of use to others,
and might point towards a resolution to this issue.
I'd be glad to post the little bits of code if this is of interest and unclear.