481796 - Add scalar operator syntax to most frequently used FILTER's

Status: RESOLVED WONTFIX

(Bugzilla :: Bugzilla-General, enhancement)

Description

[Vitaly Fedrushkov]

Separated from bug 476305:

FILTERs are good because they are clearly visible in template code.  This is twice as valuable in security filters like 'html'.

But FILTERs are suited for direct rendering.  They add complexity in situations where we don't render things but capture FILTER output for later reuse:

| [% title = BLOCK %] 
|   Request for new user account '[% login FILTER html %]' submitted
| [% END %]
| [% PROCESS global/header.html.tmpl title = title %] 

TT allows to declare the same function as scalar operator: http://template-toolkit.org/docs/manual/VMethods.html#section_Defining_Custom_Virtual_Methods

So the above example may be reduced to

| [% PROCESS global/header.html.tmpl 
|    title = "Request for new user account ${login}.html submitted" %]

Comment 1

[Vitaly Fedrushkov]

(In reply to bug 476305 comment 10)
> It's not OK to me, from a security point of view. The example in comment 2 will
> force us to filter the login name, else 008filter.t will complain. With your
> new example, it's too easy to forget to filter the login name, and I'm sure
> people is going to abuse this syntax as soon as it's available. Did you think
> about that? I fixed enough security bugs related to filtering to know it will
> be a problem.

We already do not trust developers and (since bug 192677) rely on tests for that task.  And yes, if we implement this -- 008filter.t should be updated accordingly.

Comment 2

[Max Kanat-Alexander]

Doesn't ${login}.html just render like "[e-mail]"?

Anyhow, I'm pretty much against this--I want total consistency if we can get it.

Comment 3

[Vitaly Fedrushkov]

(In reply to comment #2)
> I want total consistency if we can get it.

Total consistency is good, as long as we're converged on _best_ practice.  Current practice and best practice are not always the same :-) and 'current' may eventually become 'legacy'.

I do understand why FILTER syntax for security filters _was_ good when it was introduced.  I just do not expect it to be good forever, with our requirements changes and Template Toolkit advances.

Comment 4

[Max Kanat-Alexander]

It's easy to differentiate FILTER html from, say, "hash.keys". I have no problem with FILTER html (or the very rare "| html"). Filters are important, they work just fine, and I don't think there's too much of a problem that needs to be solved with them.

Comment 5

[Frédéric Buclin]

(In reply to comment #2)
> Anyhow, I'm pretty much against this--I want total consistency if we can get
> it.

I'm against this too, from a security point of view. Also, having two ways to do the same thing is not a good idea, IMO. If TT devs wanted to implement FILTERS as scalar operators, they would have done it already.


(In reply to comment #1)
> We already do not trust developers

This is unrelated to "trust" developers or not. Developers are human, and human is not perfect, nor are reviewers. But offering them another way to filter stuff is just a good opportunity to do such mistakes more often.


Also, technically, we would have to be very careful with parsing strings correctly in the scalar operator as .html is also used as a file extension (e.g. [% PROCESS foo.html.tmpl %] or href="page.cgi?id=fields.html").

For all these reasons, I'm suggesting WONTFIX.

Comment 6

[Frédéric Buclin]

<LpSolit> mkanat: WONTFIX for bug 481796?
<mkanat> LpSolit: Yes.