Monday, January 16, 2017, 12:22:51 PM, Christoph Rüger wrote:
[snip]
> NodeModel.getDocumentBuilderFactory(). This is when also the
> external entities are resolved and DOM is created. So it would be
> good, if this could be customized (either by passing parameters or some other
> mechanism).
2017-01-16 11:58 GMT+01:00 Daniel Dekany :
> Monday, January 16, 2017, 10:05:13 AM, Christoph Rüger wrote:
>
> [snip]
> > The DocumentBuildFactory created
> > in freemarker.ext.dom.NodeModel.getDocumentBuilderFactory() is currently
> > setup to resolve external entities
Friday, January 13, 2017, 1:07:36 PM, Christoph Rüger wrote:
> 2017-01-13 1:17 GMT+01:00 Daniel Dekany :
>
>> Friday, January 13, 2017, 12:08:12 AM, Christoph Rüger wrote:
>>
>> > +1 for everything.
>> >
>> > additional security topics:
>> > use
2017-01-13 1:17 GMT+01:00 Daniel Dekany :
> 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.
>
>
Yeah, that's one of the parser-related wishes I saw for a few time. I
heads it's also possible with JavaCC. This would be also very useful
for IDE plugins (the current Eclipse plugin only marks the first
error). Anyway, when we get to the template language issues, we shall
see what direction that
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
It would be awesome if the parser was able to recover on error and return
multiple errors, instead of the first one. Perhaps you may need to use a
bottoms-up parser instead of javacc. My customers complain that they need to
try the “run” (I use a preview mode actually) multiple times if they
These look good to me. Always feels good to clean out old and unneeded code. :)
-David
On Thu, 2017-01-12 at 23:58 +0100, Daniel Dekany wrote:
> I have collected some further easy changes for FM3... Any comments?
>
> - Drop FTL classic compatible mode option (Roughly emulates FM1
> behavior
+1 for everything.
additional security topics:
use TemplateClassResolver.ALLOWS_NOTHING_RESOLVER by default to avoid
template injection attacks.
2017-01-12 23:58 GMT+01:00 Daniel Dekany :
> I have collected some further easy changes for FM3... Any comments?
>
> - Drop FTL
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 instead of <#if x>).
-
10 matches
Mail list logo