velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain" <wgl...@forio.com>
Subject Re: using Velocity in an untrusted environment
Date Fri, 07 Apr 2006 18:36:50 GMT
Have you seen this?

http://jakarta.apache.org/velocity/docs/developer-guide.html#Velocity%20Configuration%20Keys%20and%20Values

Most of the properties should be documented.  If anyone finds missing
ones they should file JIRA issues.

In addition to:
directive.foreach.maxloops

you can also limit #parse with
directive.parse.maxdepth

Nathan - Congrats on the upcoming baby, by the way.  We just had our
second two months ago.

WILL

On 4/7/06, Nathan Bubna <nbubna@gmail.com> wrote:
> On 4/7/06, Ben <benjamin@pcguy.org> wrote:
> > I just don't want to have to create a new thread every time a request comes
> > in, since that would double the number of threads on the server from 1 per
> > page access to 2. If i were to create a new thread it would be easy to
> > interrupt it, by doing thread.join(number of milliseconds); and then
> > thread.interrupt();
> >
> > Thanks about pointing out foreach.maxloops property, is there a list
> > somewhere of all properties i can set for velocity? I browsed through the
> > docs, but didn't find them.
>
> unfortunately, the config properties are not all documented well.
> it's something on my long wish-i-had-time-to-do-this list, but with a
> new house, pregnant wife, and pressure from my main paying job, i
> haven't had time. :)
>
> however, the latest version of the RuntimeConstants class will give a
> pretty good of the properties available, as it has deprecated the
> meaningless ones and include most of the newer ones.
>
> > ----- Original Message -----
> > From: "Nathan Bubna" <nbubna@gmail.com>
> > To: "Velocity Users List" <velocity-user@jakarta.apache.org>
> > Sent: Friday, April 07, 2006 12:18 PM
> > Subject: Re: using Velocity in an untrusted environment
> >
> >
> >
> >
> > 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
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>


--
Forio Business Simulations

Will Glass-Husain
wglass@forio.com
www.forio.com

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