Add @SNIPPET binding for generating list of TV options

[sdrenth]

Summary

With PR #13865 @EVAL has been removed for security reasons. If you want to use a snippet for generating a list of TV options we normally use @EVAL. The suggested fix for this issue was to use a chunk which calls a snippet (as mentioned in the comments of the PR).

I think @SNIPPET should be added as a binding option, else you need to add a chunk and a snippet instead of just having the one snippet. It's more a work-around then a proper fix in my opinion.

Also I'd like to see support for @FILE, and make it possible to do something like this:

@FILE [[++core_path]]/components/mycomponent/elements/snippets/getlist.php

Which makes it possible to also work filebased without any reference to the database.

[OptimusCrime]

There is a good reason for doing this; security.

Read the explanation here given by @sepiariver:

@OptimusCrime one option is to use the @chunk binding, which can in turn call a Snippet. In this scenario, a User may be granted permission to edit TVs, but not to edit Snippets, and they would only be able to execute Snippets already installed/prepared.
Alternatively the @select binding provides a very flexible way to fetch input options for TVs. It does grant access to read any value in the database, but at least you cannot execute arbitrary code with it.
Note: implementation of @eval in a given site is not required to exploit it—the mere existence of the feature in core, exposes a substantial vulnerability, albeit scoped to manager users.

This was agreed upon a while back, I do not think they are going to add it back. Security goes before convenience in this situation.

Suggest closing as a wontfix or intended behavior.

[sdrenth]

@OptimusCrime I'm not stating that @eval should be readded again, just that a new option @snippet should be added where an already created snippet can be added. Thats the same solution as the @chunk solution containing a snippet, only better because you don't need to create a chunk AND a snippet but instead only need the snippet

[OptimusCrime]

Oh, I think I understand now. You want the new binding to be able to execute some already existing snippet, with optionally input values? I could see this work, as it would not allow you to execute arbitrary code.

@sepiariver any thoughts on this one?

[sepiariver]

@Mark-H has implemented a @SNIPPET binding on one of his Extras (Content Blocks?) He might be able to chime in here, but @SNIPPET is quite a bit better than @EVAL. The former, you would need to have edit access to Snippets already, in which case you already have been trusted with permissions to execute arbitrary PHP code.

[sdrenth]

I updated the issue because I think the @FILE also should be supported.

[JoshuaLuckers]

I updated the issue because I think the @FILE also should be supported.

Isn't @file already supported?

[Bruno17]

I think, this was solved at the snowup with #15488.
Since this was a feature request on sterc's bounty list, I wonder, if anyone could test it, if it works as expected.
If yes, I think, this could be closed.