You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Miles Huang <mi...@surwing.com> on 2007/08/17 12:37:34 UTC

Proposal: Eliminate POJO Wrapper by Velocity "uberspect" mechanism

Hi Roller developers,
  We have developed a customized Velocity "uberspect", which can do method
level bean access control for Velocity templates. The access control is
based on annotations. Since roller has recently changed to support JDK 1.5,
it could be a good replacement for roller's current POJO wrapper solution.
If you are interested in it, we can contribute the code to roller.

  Use "uberspect" to do security control will do help both on developing and
system runtime efficient. Backend query results can be send to templates
directly, no wrapper and list copy process are necessary now. And the single
point control setting (on POJO class itself) method will eliminate the
possibility of security hole that some code at somewhere give the template
unwrapped object accidentally.

  To apply the customized uberspect is easy, just change the
velocity.properties. Add following line:

runtime.introspector.uberspect =
com.surwing.velocity.AnnotationAwareUberspect

  To utilize the annotation aware uberspect, some source code changes needs
to do:

1. For all POJO's accessible from templates, a class level annotation should
be added, @VelocityPojoAC. The annotation have three options with default
values: getters(ALLOWED), setters(DENIED) and (other) methods(DENIED). These
are default settings for a POJO class, which can match most POJO method
access control requirements.
2. Individual methods' access control can be defined by method level
annotation @VelocityMethodAC, which will take precedence than the class
level default settings. The annotation takes only one option, either
AccessControl.ALLOWED or AccessControl.DENIED. For roller's POJO codes,
changes need to do are add @VelocityMethodAC(AccessControl.ALLOWED) to
findXXXAttribute methods, and add @VelocityMethodAC(AccessControl.DENIED) to
get method of many-to-one attributes (which should be a List). Deny template
access to get such attribute will prevent the template code change the POJO
mapping relationship eventually.
  After that, all wrapper classes and POJO List copy operations in pagers
can be removed. Change the model and pager classes to return unwrapped POJOs
directly.

  This is the source code of the customized velocity uberspect. It's quite
simple, only 5 files. Take a look at it please ;-)

http://www.nabble.com/file/p12197423/src.zip src.zip 
-- 
View this message in context: http://www.nabble.com/Proposal%3A-Eliminate-POJO-Wrapper-by-Velocity-%22uberspect%22-mechanism-tf4284948s12275.html#a12197423
Sent from the Roller - Dev mailing list archive at Nabble.com.


Re: Proposal: Eliminate POJO Wrapper by Velocity "uberspect" mechanism

Posted by Dave <sn...@gmail.com>.
Thanks Miles,

That is certainly nice way to implement "wrappers" but I am against
using that approach in Roller because it only works for Velocity.

Now that we support a pluggable view, it is possible to use languages
other than Velocity (I've used Groovy Server Pages, JavaScript and
JRuby) and so we can't use a Velocity specific approach.

I'm also against the uberspector approach because we use the wrappers
to implement display logic that does not belong in our POJOs, e.g.
escaping HTML where appropriate, etc. If we simply annotate the POJOs
we lose the ability to perform that logic.

- Dave



On 8/17/07, Miles Huang <mi...@surwing.com> wrote:
> Hi Roller developers,
>   We have developed a customized Velocity "uberspect", which can do method
> level bean access control for Velocity templates. The access control is
> based on annotations. Since roller has recently changed to support JDK 1.5,
> it could be a good replacement for roller's current POJO wrapper solution.
> If you are interested in it, we can contribute the code to roller.
>
>   Use "uberspect" to do security control will do help both on developing and
> system runtime efficient. Backend query results can be send to templates
> directly, no wrapper and list copy process are necessary now. And the single
> point control setting (on POJO class itself) method will eliminate the
> possibility of security hole that some code at somewhere give the template
> unwrapped object accidentally.
>
>   To apply the customized uberspect is easy, just change the
> velocity.properties. Add following line:
>
> runtime.introspector.uberspect =
> com.surwing.velocity.AnnotationAwareUberspect
>
>   To utilize the annotation aware uberspect, some source code changes needs
> to do:
>
> 1. For all POJO's accessible from templates, a class level annotation should
> be added, @VelocityPojoAC. The annotation have three options with default
> values: getters(ALLOWED), setters(DENIED) and (other) methods(DENIED). These
> are default settings for a POJO class, which can match most POJO method
> access control requirements.
> 2. Individual methods' access control can be defined by method level
> annotation @VelocityMethodAC, which will take precedence than the class
> level default settings. The annotation takes only one option, either
> AccessControl.ALLOWED or AccessControl.DENIED. For roller's POJO codes,
> changes need to do are add @VelocityMethodAC(AccessControl.ALLOWED) to
> findXXXAttribute methods, and add @VelocityMethodAC(AccessControl.DENIED) to
> get method of many-to-one attributes (which should be a List). Deny template
> access to get such attribute will prevent the template code change the POJO
> mapping relationship eventually.
>   After that, all wrapper classes and POJO List copy operations in pagers
> can be removed. Change the model and pager classes to return unwrapped POJOs
> directly.
>
>   This is the source code of the customized velocity uberspect. It's quite
> simple, only 5 files. Take a look at it please ;-)
>
> http://www.nabble.com/file/p12197423/src.zip src.zip
> --
> View this message in context: http://www.nabble.com/Proposal%3A-Eliminate-POJO-Wrapper-by-Velocity-%22uberspect%22-mechanism-tf4284948s12275.html#a12197423
> Sent from the Roller - Dev mailing list archive at Nabble.com.
>
>