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:[email protected]] 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
