Friday, January 13, 2017, 12:08:12 AM, Christoph Rüger wrote: > +1 for everything. > > additional security topics: > use TemplateClassResolver.ALLOWS_NOTHING_RESOLVER by default to > avoid template injection attacks.
At least in FM2 you pull in your TemplateDirectiveModel-s and TemplateMethodModel-s into #import/#include-able FTL-s with `?new`. I can imagine much better mechanisms for that use-case though... But for now, the point is that we can't just default to ALLOWS_NOTHING_RESOLVER without giving an alternative first. But, now that you say, I will delete those legacy "utility" TemplateModel-s which make `?new` rather dangerous. > 2017-01-12 23:58 GMT+01:00 Daniel Dekany <[email protected]>: > I have collected some further easy changes for FM3... Any comments? > > - Drop FTL classic compatible mode option (Roughly emulates FM1 > behavior at null-s and at some type handling issues) > > - Drop FTL non-strict syntax option (FM1 syntax - that's where you > could write <if x> instead of <#if x>). > > - Drop all the "public static void main(String[] args)" methods (security > concern) > > - Drop freemarker.log. That's a simple log adapter facility from the > ancient times of Java, kind of like commons-logging or slf4j. I > would instead introduce slf4j-api as a required dependency. > > - Drop legacy XML wrapper (freemarker.ext.xml, not to be confused with > freemarker.ext.dom) > > - Drop ant task (freemarker.ext.ant) > > -- > Thanks, > Daniel Dekany > > > > -- Thanks, Daniel Dekany
