Re: import / include directives question

2017-08-08 Thread Daniel Dekany
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 ther

RE: import / include directives question

2017-08-08 Thread Mickel Daelmans | Add to Favorites
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



Re: import / include directives question

2017-08-01 Thread Daniel Dekany
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
>
> 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).
>

-- 
Thanks,
 Daniel Dekany