freemarker-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christoph Rueger (Jira)" <j...@apache.org>
Subject [jira] [Created] (FREEMARKER-121) 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.
Date Mon, 04 Nov 2019 21:06:00 GMT
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)

Mime
View raw message