Christoph Rueger created FREEMARKER-121:
-------------------------------------------
Summary: Pluggable filtering of template accessible class members,
as unsafeMethods.properties is clearly not useful if you want to allow people
outside the developer team to provide templates.
Key: FREEMARKER-121
URL: https://issues.apache.org/jira/browse/FREEMARKER-121
Project: Apache Freemarker
Issue Type: New Feature
Components: engine
Affects Versions: 2.3.29
Reporter: Christoph Rueger
h2. Problem description
We want to "hide" certain class members (methods, fields, properties) so that
they are not accessible from templates. The problem is based on a discussion
about white-list / black-list of accessible class members.
One example is preventing that one might call
{code:java}
${obj.class}
{code}
or
{code:java}
${obj.getClass()}
{code}
h2. Why
In our plugin system, FM-templates and objects accessible in the FM-Context are
coming from external users and which are not our developers.
We need a way to forbid some methods and fields (blacklist approach) which are
considered harmful or dangerous (like .getClass()).
h2. What
We wish to be able to do two things:
* define a *whitelist* of classes, methods, fields which are allowed to be
accessed
* define a *blacklist* of classes, methods, fields which are NEVER allowed to
be accessed
** the *blacklist* also servers as a safety guard against developer mistakes,
which mistakenly whitelisted something by accident
h2. What is already there?
Freemarker currently has *MethodAppearanceFineTuner* which can be injected to
the ObjectWrapper.
It allows you to e.g. prevent access to _${obj.getClass()}_ method like this:
{code:java}
objWrapper.setMethodAppearanceFineTuner(new MethodAppearanceFineTuner() {
@Override
public void process(MethodAppearanceDecisionInput in,
MethodAppearanceDecision out) {
if(in.getMethod().getName().contains("getClass")){
// hide method
out.setExposeMethodAs(null);
}
}
});
{code}
But currently it does *not* allow you to hide the property. That means
_${obj.class}_ is still possible.
There is also something like
_freemarker.ext.beans.UnsafeMethods.isUnsafeMethod(Method)_ in the code base,
which is missing _.getClass()_ and cannot be changed because it wouldn't be
backwards compatible.
A discussion with [~ddekany] by email pointed in the direction:
?? the point that need to be customizable is
ClassIntrospector.isAllowedToExpose.??
h2. How
The how is currently up for discussion.
Keywords: Maybe a mix of different hooks for doing it programmatically (e.g.
_ClassIntrospector.isAllowedToExpose_ or similar to MethodAppearanceFineTuner),
.properties files, annotations are coming to mind.
h3.
h3. Side Note on OSGI / Classloaders
We are living in an OSGI-world of multiple bundles with each having a different
class loader.
So it would be good to have a way to let other bundles (with different
classloader) define their own rules / hooks too, without requiring the
objectWrapper to know about the class added to freemarker. Maybe this OSGI
part does not belong to this issue exactly but I wanted to bring it up as it
might be a constraint for the solution.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
