velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Bubna" <nbu...@gmail.com>
Subject Re: using Velocity in an untrusted environment
Date Fri, 07 Apr 2006 00:58:18 GMT
On 4/6/06, Ben <benjamin@pcguy.org> wrote:
> Thanks Will, I appreciate your response.
<snip/>
> I'll be happy to share my solution about interrupting the rendering process,
> if I come up with a generic way which can be applied to other projects
> besides mine. Ideally I would like this to be a function of Velocity itself,
> where for every operation it does it would assign some number, which would
> be the cost of that operation, and then the developer would have the ability
> to set the maximum cost, after which velocity would automatically interrupt
> the rendering process. Another option would be for it to save the starting
> date/time of the rendering process, and then every now and then to check how
> much time has passes, and if the time limit has expired to interrupt the
> rendering process. I am not sure I have sufficient understanding of the
> Velocity source code to do this though, can anybody who knows the Velocity
> code well tell me if any of these two options are feasable, and if yes, what
> class/classes would I need to modify for this?

Hmm.  To be honest, I'm not interested in having this be an
out-of-the-box piece of Velocity.  Adding this "maximum cost" option
for "every operation it does" would mean a performance hit, a big rise
in complexity, or both.  I would want to see a lot of interest in this
from others before i would let this change go through without vetoing
it.  I really don't think this is something most of our users want or
need.  No one else has asked for it (to my memory) in the five years
i've been around.

For you, however, it ought to be fairly easy straightforward to create
a VelocityRunnable that you can start in a new Thread to do the
template merge/render and then have the request thread check up on it
(sleeping in between checks, of course) periodically.

The tricky part is stopping the rendering thread when it goes over
time.  It's not really safe to use the deprecated Thread.stop()
method.  The recommended replacement
(http://java.sun.com/j2se/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html)
is to create velocityRunnable.stop() method that can flip a flag to
interrupt the rendering.  But Velocity doesn't have any built in way
to *interrupt* the rendering.  The only thing i'm aware of is the
#stop directives ability to make Velocity stop sending output to the
writer.  So far as i know, it doesn't actually stop the template
processing (personally, i think it'd be better if it did).

To actually stop template processing, you will probably have to alter
some of the internals yourself.  The driver of the rendering process
is a simple for() loop in the render(context, writer) method of the
SimpleNode class.  all the nodes extend this class, so this method is
how the AST is traversed.  I would imagine that the "real way" to do
this would be to somehow put the flag in that for() loop's conditional
that would be shared by all nodes in that template.  That probably
means you need a flag that resides in the context that's being passed
around.  When the flag is tripped, no further nodes should be
rendered.

Of course, i'm not 100% sure that that is all you'll need to change,
and it also might not catch all possible problems.  For instance, if
it is the rendering of a particular leaf on the AST that is taking
forever, then this won't stop that node's rendering; it would only
stop further traversal of the tree.  Still, that is hopefully enough
info to get you started...

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Mime
View raw message