Tuesday, August 8, 2017, 1:52:50 PM, Mickel Daelmans | Add to Favorites wrote:

> Hi Daniel,
>
> Thanks for the solution and sorry for the late reaction. The
> Environment.getCurrentEnvironment().getCurrentTeamplte() works in
> this case and we'll use it for now to distinguish between initial
> loads and consecutive includes/imports. 
>
> In future releases we'd definitely like more control over security
> and performance related features. Custom loaders for
> imports/includes, user management and fine grained directive control
> (enable/disable) would be appreciated. Also some defence against
> infinite loops/recursive functions and/or out-of-memory exceptions
> would be very helpful. We now use
> freemarker.core._CoreAPI.addThreadInterruptedChecks(template); as a
> defence mechanism, but we don't even now if (an/or for how long) this is 
> supported.

http://try.freemarker.org/ uses it, so it's actively used. But as the
JavaDoc of _CoreAPI says, that's internal API, so there are no
backward compatibility promises. But it's unlikely to change anytime
soon, unless it's replaced with a published API.

> We use freemarker for online template authoring where we have no
> control of how freemarker is used by our clients and misusage (on
> purpose or by accident)) is a definite threat.

(Just in case you did, don't miss the related FAQ entry.)

> Access to restricted resources is a definite no-go and a failing
> template must not jeopardise the running service, but only fail the
> specific (template parsing) thread instead.
>
> We hope our opinion matters and some related features will make it to future 
> releases.

As far as it's feasible to do... For example, while limiting CPU time
is possible with timeouts, I'm not aware of any technique to prevent
too high memory usage. It's fairly easy to do such thing with string
concatenation for example. (We could then limit the length of
concatenated results though...) Though applications almost always
quickly recover from OOME, the OOME can introduce some state
corruption (not because of FreeMarker, but in general it's like that).
But if you have paying customers, then hostile users are rare and I
guess will be banned pretty quickly anyway.

> Thanks for a great product,
>
>
> Mickel Daelmans
> Developer
>  
>
> Goeman Borgesiuslaan 77
> 3515 ET Utrecht
> T. 030-7551560
> W. www.addtofavorites.nl
>  
> Alles weten over transactionele e-mail?
> Volg onze mailroad pagina op LinkedIn
> ===
> De inhoud van deze e-mail, inclusief bijlagen, is vertrouwelijk en
> enkel bestemd voor de geadresseerde. Indien dit bericht niet voor u
> is bestemd, verzoeken wij u het te vernietigen, de inhoud daarvan op
> geen enkele wijze te gebruiken of te openbaren en direct contact met
> ons op te nemen. Op al onze werkzaamheden zijn onze Algemene
> Voorwaarden van toepassing, waarin een aansprakelijkheidsbeperking
> is opgenomen. Onze Algemene Voorwaarden worden op verzoek
> toegezonden. Add to Favorites B.V. is gevestigd te Utrecht (KvK Utrecht nr. 
> 17228639).
>
>
> -----Oorspronkelijk bericht-----
> Van: Daniel Dekany [mailto:ddek...@apache.org] 
> Verzonden: dinsdag 1 augustus 2017 23:51
> Aan: Mickel Daelmans
> Onderwerp: Re: import / include directives question
>
> There's no specific feature for that (like some kind of template
> access rights system), and what #include and #import does is fixed.
>
> There's the possibility that you do such a check both in the
> TemplateLoader and in the CacheStorage (with custom wrapper
> implementations in both cases), by calling
> Environment.getCurrentEnvironment(), and if it's non-null then you
> call env.getCurrentTemplate() to see who was the caller was. But
> it's awkward, obviously. And maybe there's some catch that I don't yet 
> realize...
>
> So maybe we should figure out some light weight feature to address
> this. I think we should introduce some callback object that you can
> set in the Configuration, which handle the Template resolution step
> of #include and #import (and the default just calls
> Configuration.getTemplate(...)). That can be useful for other
> purposes as well, so maybe it has enough applications to warrant the extra 
> complexity. Any thoughts?
>
>
> Tuesday, August 1, 2017, 1:46:37 PM, Mickel Daelmans | Add to Favorites wrote:
>
>> Hi group,
>>
>>
>>
>> Can we use a different TemplateLoader from "Configuration.getTemplate" 
>> to use for <#import/> and <#include/> directives?
>>
>> We don't want template authors to load other templates in their 
>> templates. We only want to be able to include specific files from a 
>> specific directory (which we can manage).
>>
>> Otherwise: is there a way to disable import and include directives?
>>
>> Thanks in advance,
>>
>>
>> Mickel Daelmans
>> Developer
>>
>>
>> Goeman Borgesiuslaan 77
>> 3515 ET Utrecht
>> T. 030-7551560
>> W. www.addtofavorites.nl<http://www.addtofavorites.nl/>
>>
>> Alles weten over transactionele e-mail?
>> Volg onze mailroad pagina op
>> LinkedIn<https://www.linkedin.com/company/mailroad>
>> ===
>> De inhoud van deze e-mail, inclusief bijlagen, is vertrouwelijk en 
>> enkel bestemd voor de geadresseerde. Indien dit bericht niet voor u is 
>> bestemd, verzoeken wij u het te vernietigen, de inhoud daarvan op geen 
>> enkele wijze te gebruiken of te openbaren en direct contact met ons op 
>> te nemen. Op al onze werkzaamheden zijn onze Algemene Voorwaarden van 
>> toepassing, waarin een aansprakelijkheidsbeperking is opgenomen. Onze 
>> Algemene Voorwaarden worden op verzoek toegezonden. Add to Favorites 
>> B.V. is gevestigd te Utrecht (KvK Utrecht nr. 17228639).
>>
>
> --
> Thanks,
>  Daniel Dekany
>
>

-- 
Thanks,
 Daniel Dekany

Reply via email to