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. 

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. 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.

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

Reply via email to