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 16:18:23 GMT
On 4/6/06, Ben <benjamin@pcguy.org> wrote:
> Thanks for pointing the way, I'll definitely take a look at the SimpleNode
> class and see if it can be used for my purpose. I don't want to use a
> separate thread since by me the render function is called from within a
> servlet running inside resin, so what i'll probably do is have it check the
> time, let's say every 10,000/100,000/1,000,000  loops or so, depending on
> how many loops it does per second, and if it's past the time limit stop the
> render process, or maybe just limit the rendering process to a certain
> amount of loops, to prevent people from writing templates with a near
> infinite loop. I do some work with Yahoo's RTML scripting language, which is
> being interpreted by a perl script running on Yahoo's servers, and I think
> that's what Yahoo does, limit the loops to 10,000,000 iterations or so.

i don't see why there should be any problem with using a separate
thread.  servlet requests are all about threads.

if it is just #foreach looping that you are concerned about, then
there is already a directive.foreach.maxloops property that you can
set.

> If people are interested I can paste the results of my experiment when I am
> done, as well as any modifications I make.
>
>
>
> 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
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
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