You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Will Glass-Husain <wg...@forio.com> on 2001/07/22 05:20:23 UTC
include / parse restrictions
I've got a security-related design question for a velocity-based web
application I'm building.
In this system, independent developers will upload velocity templates to
be stored in separate directories. The idea is that each developer is
creating an independent application with a unique group of users. In
other words, a user goes to URL
http://www.zzz.com/joe/
and can use the application developed by Joe in VTL. A servlet that we've
written parses the URL, logs the end-user in, and returns
the template for the appropriate application based on the path.
Joe (and all other developers) have no access to the server except through
a web-based tool to upload VTL templates. These files are stored in 1
directory per developer.
Here's the question. Joe's application shouldn't be able to access
templates (and other private data files) stored in other
directories. Right now, if Joe's template does:
#parse("../john/abc.vtl")
Joe can display the results from a different developer John's abc.vtl
page.
Any suggestions as to how I can prevent this? My best idea (which still
seems a bit unruly), is to use Geir's new instantiation capability to
create a new velocity engine for each application when users log in.
Then I would set the file resource loader path property for each one to be
the application directory. This would constrain developers to include or
parse only from their own directories.
Any advice on hassle free ways to architect this would be appreciated.
WILL
Re: VM_PERM_INLINE_LOCAL issue
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Nope, that's good. Shouldn't be hard to find. Thanks for looking into
it.
geir
Dan Finkelstein wrote:
>
> Geir,
>
> This bug was really hard to debug -- I haven't been able to reproduce it in
> a small test case, but here is the essence:
>
> We process our templates through the velocity engine again and again until
> there is nothing that is substituted -- this allows us to expand an
> expansion, so to speak. Now, we also have a method, called text(), which
> we put into the context, and it looks something like this:
>
> public String text(String lookup)
> throws Exception
> {
> String text = getLookup(lookup);
> for (;;) {
>
> String nextText = ppEvaluate(text, text,context);
>
> if (nextText.equals(text))
> break;
>
> text = nextText;
> }
>
> return text;
> }
>
> where the ppEvaluate() method just calls Velocities evaluate() again and
> again -- usually twice -- until no substitutions are made. There was a
> case where lookup returned a text string that had length of zero, and the
> stacktrace in velocity log showed up -- this only happened if
> VM_PERM_INLINE_LOCAL was set to true.
>
> Geir, I wasn't able to reproduce this in a standalone program. Hopefully,
> this datapoint if enough to understand what is going on!!
>
> Sorry this couldn't have been more complete,
> Dan
>
> At 07:42 PM 7/23/01 -0400, you wrote:
> >Whoops :)
> >
> >Can you send me the template?
> >
> >geir
> >
> >Dan Finkelstein wrote:
> > >
> > > I've been trying to tune the runtime behavior of the velocimacro
> > > system. By just adding this line,
> > >
> > > velocityEngine.setProperty(velocityEngine.VM_PERM_INLINE_LOCAL,
> > "true");
> > >
> > > the velocity.log file would contain the below stacktrace. We're using
> > > the latest Vel 1.2 dev jar, along with one macro library which is loaded on
> > > initialization. We also include macros in templates. I'm not sure if this
> > > info helps, but it might be pertinent. Can you give me some idea what to
> > > do to isolate this problem?
> > >
> > > Thanks again,
> > > Dan
> > >
> > > Mon Jul 23 15:52:12 PDT 2001 [error] Parser Error:
> > > C:\projects\gusa/builds/common/b0/templates/External.html :
> > > java.lang.NullPointerException
> > > at
> > >
> > org.apache.velocity.runtime.VelocimacroManager.get(VelocimacroManager.java:181)
> > > at
> > >
> > org.apache.velocity.runtime.VelocimacroFactory.isVelocimacro(VelocimacroFactory.java:363)
> > > at
> > >
> > org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:378)
> > > at
> > >
> > org.apache.velocity.runtime.RuntimeInstance.getVelocimacro(RuntimeInstance.java:933)
> > > at
> > org.apache.velocity.runtime.parser.Parser.Directive(Parser.java:601)
> > > at
> > org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:306)
> > > at
> > org.apache.velocity.runtime.parser.Parser.process(Parser.java:247)
> > > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:103)
> > > at
> > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:667)
> > > at
> > org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:611)
> > > at
> > org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:324)
> > > at
> > org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:254)
> > > at
> > com.yipinet.b0.preprocess.ProcessTags.ppEvaluate(ProcessTags.java:264)
> > > at
> > com.yipinet.b0.preprocess.ProcessTags.<init>(ProcessTags.java:182)
> > > at com.yipinet.b0.build.go.processLesson(go.java:644)
> > > at com.yipinet.b0.build.go.doit(go.java:288)
> > > at com.yipinet.b0.build.go.main(go.java:77)
> > > at com.yipinet.b0.build.dgo.main(dgo.java:56)
> > > at java.lang.reflect.Method.invoke(Native Method)
> > > at com.yipinet.go.execStatic(go.java:275)
> > > at com.yipinet.go.execMain(go.java:253)
> > > at com.yipinet.go.launchGo(go.java:225)
> > > at com.yipinet.dgo.main(dgo.java:66)
> > > Dan Finkelstein
> > > Senior Architect, Instructional Tools & Technology
> > > eMind LLC
> > > Northern California Annex
> > > 1250 Addison St, Suite #210
> > > Berkeley, CA 94702-1700
> > > Tel: (510) 486-2740
> > > Fax: (510)486-2843
> > >
> > > Visit us at <http://www.emind.com/>
> > >
> > > This email message is for the sole use of the intended recipient(s) and may
> > > contain confidential and privileged information. Any unauthorized review,
> > > use, disclosure or distribution is prohibited. If you are not the intended
> > > recipient, please contact the sender by reply email and destroy all copies
> > > of the original message.
> >
> >--
> >Geir Magnusson Jr. geirm@optonline.net
> >System and Software Consulting
> >Developing for the web? See http://jakarta.apache.org/velocity/
> >Be well, do good work, and keep in touch.
>
> Dan Finkelstein
> Senior Architect, Instructional Tools & Technology
> eMind LLC
> Northern California Annex
> 1250 Addison St, Suite #210
> Berkeley, CA 94702-1700
> Tel: (510) 486-2740
> Fax: (510)486-2843
>
> Visit us at <http://www.emind.com/>
>
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
VM_PERM_INLINE_LOCAL issue
Posted by Dan Finkelstein <da...@emind.com>.
Geir,
This bug was really hard to debug -- I haven't been able to reproduce it in
a small test case, but here is the essence:
We process our templates through the velocity engine again and again until
there is nothing that is substituted -- this allows us to expand an
expansion, so to speak. Now, we also have a method, called text(), which
we put into the context, and it looks something like this:
public String text(String lookup)
throws Exception
{
String text = getLookup(lookup);
for (;;) {
String nextText = ppEvaluate(text, text,context);
if (nextText.equals(text))
break;
text = nextText;
}
return text;
}
where the ppEvaluate() method just calls Velocities evaluate() again and
again -- usually twice -- until no substitutions are made. There was a
case where lookup returned a text string that had length of zero, and the
stacktrace in velocity log showed up -- this only happened if
VM_PERM_INLINE_LOCAL was set to true.
Geir, I wasn't able to reproduce this in a standalone program. Hopefully,
this datapoint if enough to understand what is going on!!
Sorry this couldn't have been more complete,
Dan
At 07:42 PM 7/23/01 -0400, you wrote:
>Whoops :)
>
>Can you send me the template?
>
>geir
>
>Dan Finkelstein wrote:
> >
> > I've been trying to tune the runtime behavior of the velocimacro
> > system. By just adding this line,
> >
> > velocityEngine.setProperty(velocityEngine.VM_PERM_INLINE_LOCAL,
> "true");
> >
> > the velocity.log file would contain the below stacktrace. We're using
> > the latest Vel 1.2 dev jar, along with one macro library which is loaded on
> > initialization. We also include macros in templates. I'm not sure if this
> > info helps, but it might be pertinent. Can you give me some idea what to
> > do to isolate this problem?
> >
> > Thanks again,
> > Dan
> >
> > Mon Jul 23 15:52:12 PDT 2001 [error] Parser Error:
> > C:\projects\gusa/builds/common/b0/templates/External.html :
> > java.lang.NullPointerException
> > at
> >
> org.apache.velocity.runtime.VelocimacroManager.get(VelocimacroManager.java:181)
> > at
> >
> org.apache.velocity.runtime.VelocimacroFactory.isVelocimacro(VelocimacroFactory.java:363)
> > at
> >
> org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:378)
> > at
> >
> org.apache.velocity.runtime.RuntimeInstance.getVelocimacro(RuntimeInstance.java:933)
> > at
> org.apache.velocity.runtime.parser.Parser.Directive(Parser.java:601)
> > at
> org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:306)
> > at
> org.apache.velocity.runtime.parser.Parser.process(Parser.java:247)
> > at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:103)
> > at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:667)
> > at
> org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:611)
> > at
> org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:324)
> > at
> org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:254)
> > at
> com.yipinet.b0.preprocess.ProcessTags.ppEvaluate(ProcessTags.java:264)
> > at
> com.yipinet.b0.preprocess.ProcessTags.<init>(ProcessTags.java:182)
> > at com.yipinet.b0.build.go.processLesson(go.java:644)
> > at com.yipinet.b0.build.go.doit(go.java:288)
> > at com.yipinet.b0.build.go.main(go.java:77)
> > at com.yipinet.b0.build.dgo.main(dgo.java:56)
> > at java.lang.reflect.Method.invoke(Native Method)
> > at com.yipinet.go.execStatic(go.java:275)
> > at com.yipinet.go.execMain(go.java:253)
> > at com.yipinet.go.launchGo(go.java:225)
> > at com.yipinet.dgo.main(dgo.java:66)
> > Dan Finkelstein
> > Senior Architect, Instructional Tools & Technology
> > eMind LLC
> > Northern California Annex
> > 1250 Addison St, Suite #210
> > Berkeley, CA 94702-1700
> > Tel: (510) 486-2740
> > Fax: (510)486-2843
> >
> > Visit us at <http://www.emind.com/>
> >
> > This email message is for the sole use of the intended recipient(s) and may
> > contain confidential and privileged information. Any unauthorized review,
> > use, disclosure or distribution is prohibited. If you are not the intended
> > recipient, please contact the sender by reply email and destroy all copies
> > of the original message.
>
>--
>Geir Magnusson Jr. geirm@optonline.net
>System and Software Consulting
>Developing for the web? See http://jakarta.apache.org/velocity/
>Be well, do good work, and keep in touch.
Dan Finkelstein
Senior Architect, Instructional Tools & Technology
eMind LLC
Northern California Annex
1250 Addison St, Suite #210
Berkeley, CA 94702-1700
Tel: (510) 486-2740
Fax: (510)486-2843
Visit us at <http://www.emind.com/>
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message.
Re: include / parse restrictions
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Whoops :)
Can you send me the template?
geir
Dan Finkelstein wrote:
>
> I've been trying to tune the runtime behavior of the velocimacro
> system. By just adding this line,
>
> velocityEngine.setProperty(velocityEngine.VM_PERM_INLINE_LOCAL, "true");
>
> the velocity.log file would contain the below stacktrace. We're using
> the latest Vel 1.2 dev jar, along with one macro library which is loaded on
> initialization. We also include macros in templates. I'm not sure if this
> info helps, but it might be pertinent. Can you give me some idea what to
> do to isolate this problem?
>
> Thanks again,
> Dan
>
> Mon Jul 23 15:52:12 PDT 2001 [error] Parser Error:
> C:\projects\gusa/builds/common/b0/templates/External.html :
> java.lang.NullPointerException
> at
> org.apache.velocity.runtime.VelocimacroManager.get(VelocimacroManager.java:181)
> at
> org.apache.velocity.runtime.VelocimacroFactory.isVelocimacro(VelocimacroFactory.java:363)
> at
> org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:378)
> at
> org.apache.velocity.runtime.RuntimeInstance.getVelocimacro(RuntimeInstance.java:933)
> at org.apache.velocity.runtime.parser.Parser.Directive(Parser.java:601)
> at org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:306)
> at org.apache.velocity.runtime.parser.Parser.process(Parser.java:247)
> at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:103)
> at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:667)
> at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:611)
> at org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:324)
> at org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:254)
> at com.yipinet.b0.preprocess.ProcessTags.ppEvaluate(ProcessTags.java:264)
> at com.yipinet.b0.preprocess.ProcessTags.<init>(ProcessTags.java:182)
> at com.yipinet.b0.build.go.processLesson(go.java:644)
> at com.yipinet.b0.build.go.doit(go.java:288)
> at com.yipinet.b0.build.go.main(go.java:77)
> at com.yipinet.b0.build.dgo.main(dgo.java:56)
> at java.lang.reflect.Method.invoke(Native Method)
> at com.yipinet.go.execStatic(go.java:275)
> at com.yipinet.go.execMain(go.java:253)
> at com.yipinet.go.launchGo(go.java:225)
> at com.yipinet.dgo.main(dgo.java:66)
> Dan Finkelstein
> Senior Architect, Instructional Tools & Technology
> eMind LLC
> Northern California Annex
> 1250 Addison St, Suite #210
> Berkeley, CA 94702-1700
> Tel: (510) 486-2740
> Fax: (510)486-2843
>
> Visit us at <http://www.emind.com/>
>
> This email message is for the sole use of the intended recipient(s) and may
> contain confidential and privileged information. Any unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all copies
> of the original message.
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: include / parse restrictions
Posted by Dan Finkelstein <da...@emind.com>.
I've been trying to tune the runtime behavior of the velocimacro
system. By just adding this line,
velocityEngine.setProperty(velocityEngine.VM_PERM_INLINE_LOCAL, "true");
the velocity.log file would contain the below stacktrace. We're using
the latest Vel 1.2 dev jar, along with one macro library which is loaded on
initialization. We also include macros in templates. I'm not sure if this
info helps, but it might be pertinent. Can you give me some idea what to
do to isolate this problem?
Thanks again,
Dan
Mon Jul 23 15:52:12 PDT 2001 [error] Parser Error:
C:\projects\gusa/builds/common/b0/templates/External.html :
java.lang.NullPointerException
at
org.apache.velocity.runtime.VelocimacroManager.get(VelocimacroManager.java:181)
at
org.apache.velocity.runtime.VelocimacroFactory.isVelocimacro(VelocimacroFactory.java:363)
at
org.apache.velocity.runtime.VelocimacroFactory.getVelocimacro(VelocimacroFactory.java:378)
at
org.apache.velocity.runtime.RuntimeInstance.getVelocimacro(RuntimeInstance.java:933)
at org.apache.velocity.runtime.parser.Parser.Directive(Parser.java:601)
at org.apache.velocity.runtime.parser.Parser.Statement(Parser.java:306)
at org.apache.velocity.runtime.parser.Parser.process(Parser.java:247)
at org.apache.velocity.runtime.parser.Parser.parse(Parser.java:103)
at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:667)
at org.apache.velocity.runtime.RuntimeInstance.parse(RuntimeInstance.java:611)
at org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:324)
at org.apache.velocity.app.VelocityEngine.evaluate(VelocityEngine.java:254)
at com.yipinet.b0.preprocess.ProcessTags.ppEvaluate(ProcessTags.java:264)
at com.yipinet.b0.preprocess.ProcessTags.<init>(ProcessTags.java:182)
at com.yipinet.b0.build.go.processLesson(go.java:644)
at com.yipinet.b0.build.go.doit(go.java:288)
at com.yipinet.b0.build.go.main(go.java:77)
at com.yipinet.b0.build.dgo.main(dgo.java:56)
at java.lang.reflect.Method.invoke(Native Method)
at com.yipinet.go.execStatic(go.java:275)
at com.yipinet.go.execMain(go.java:253)
at com.yipinet.go.launchGo(go.java:225)
at com.yipinet.dgo.main(dgo.java:66)
Dan Finkelstein
Senior Architect, Instructional Tools & Technology
eMind LLC
Northern California Annex
1250 Addison St, Suite #210
Berkeley, CA 94702-1700
Tel: (510) 486-2740
Fax: (510)486-2843
Visit us at <http://www.emind.com/>
This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message.
Re: include / parse restrictions
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Will Glass-Husain wrote:
>
> Thanks,
>
> Appreciate the advice. I will consider whether I want to do eventCartridges
> or
> manage multiple veloctity instances. The eventCartridge suggestion
> seems the simplest, so I'll probably do that.
Note that this isn't in there yet - I want to get the separate instance
stuff put to bed either way before moving forward...
>
> On the suggestion front (much easier to contribute suggestions than code :-)
>
> I'm not exactly sure how to set it up, but some kind of property-based
> access-control
> for includes/parses might for templates served through VelocityServlet would
> be useful.
Hmmm. What do you have in mind? This sounds like a very app specific
thing...
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
RE: include / parse restrictions
Posted by Will Glass-Husain <wg...@forio.com>.
Thanks,
Appreciate the advice. I will consider whether I want to do eventCartridges
or
manage multiple veloctity instances. The eventCartridge suggestion
seems the simplest, so I'll probably do that.
On the suggestion front (much easier to contribute suggestions than code :-)
I'm not exactly sure how to set it up, but some kind of property-based
access-control
for includes/parses might for templates served through VelocityServlet would
be useful.
Will
Geir:
> Right. One way to solve this (and I don't really want to do this but
> here goes) is to add to our lovely eventCartrige system, and add a
> handler for #parse() and #include(), so it would allow you to preprocess
> the arg. Something like :
>
> public String validatePath( String path )
>
> that would be called with the resolved argument to #parse() or
> #include()
Re: include / parse restrictions
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Brian Lloyd-Newberry wrote:
>
> --- "Geir Magnusson Jr." <ge...@optonline.net> wrote:
>
> > Right. One way to solve this (and I don't really want to do this but
> > here goes) is to add to our lovely eventCartrige system, and add a
> > handler for #parse() and #include(), so it would allow you to
> > preprocess
> > the arg. Something like :
> >
> > public String validatePath( String path )
> >
> > that would be called with the resolved argument to #parse() or
> > #include()
> >
> > That way, you could simply tell your developers to not worry about
> > the
> > paths in their templates, and then prepend the appropriate /joe,
> > /john,
> > /sally, /whatever at run time...
> >
> > That way you as the programmer could enforce template access from
> > within
> > the tempalte based on application context, rather than trying to rig
> > some scheme up and trusting...
> >
>
> I think that even if this is not the way that things end up happening
> that something similar needs to be implemented. Those of us who are not
> using this for a web app really would like the ability to define
> "filters" that are not as much of a pain as the filter that web
> applications will run using. It feels like some of the restrictions on
> template loading should not be hardwired into the engine and should
> instead be based on "helper" classes that can be overwridden in a
> properties file to define a different scheme for template search paths
> among other things.
We can implement this, but would rather not add to the API unless
someone needs it.
And making a custom resource loader is trivially easy, so if you have
something magical you wish to do, it's easy to do....
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: include / parse restrictions
Posted by Brian Lloyd-Newberry <ne...@yahoo.com>.
--- "Geir Magnusson Jr." <ge...@optonline.net> wrote:
> Right. One way to solve this (and I don't really want to do this but
> here goes) is to add to our lovely eventCartrige system, and add a
> handler for #parse() and #include(), so it would allow you to
> preprocess
> the arg. Something like :
>
> public String validatePath( String path )
>
> that would be called with the resolved argument to #parse() or
> #include()
>
> That way, you could simply tell your developers to not worry about
> the
> paths in their templates, and then prepend the appropriate /joe,
> /john,
> /sally, /whatever at run time...
>
> That way you as the programmer could enforce template access from
> within
> the tempalte based on application context, rather than trying to rig
> some scheme up and trusting...
>
I think that even if this is not the way that things end up happening
that something similar needs to be implemented. Those of us who are not
using this for a web app really would like the ability to define
"filters" that are not as much of a pain as the filter that web
applications will run using. It feels like some of the restrictions on
template loading should not be hardwired into the engine and should
instead be based on "helper" classes that can be overwridden in a
properties file to define a different scheme for template search paths
among other things.
just my 2c
Brian
=====
Brian S. Lloyd-Newberry
Vertical Learning Curve Solutions
newbeb@yahoo.com
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
Re: include / parse restrictions
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Will Glass-Husain wrote:
>
> On Mon, 23 Jul 2001, Geir Magnusson Jr. wrote:
>
> > > Geir, can you confirm that in the example below? A user goes to Joe's
> > > application which is in:
> > > /joe/abc.vtl
> > >
> > > My servlet reads "abc.vtl" from the URL and gets the template
> > > "/joe/abc.vtl".
> > >
> > > The template does a #parse "../john/def.btl". This would be the path
> > > "/joe/../john/def.vtl". All of this is within the template path. (who's
> > > root is at "/".
> >
> > (where did the .. come from?)
> >
>
> Wait-- I get it. I've been assuming the path specified in the #parse is
> relative to the path of the template. (which is in this example is in a
> subdirectory "joe").
>
> Sounds like you're telling me that the #parse is always relative to the
> base template directory, even if the template is in a subdirectory. (Is
> that true?)
>
The #parse() will be tried against all the paths specified in the .paths
property of the configuration key. The leading / means nothing (it is
thrown away...), so if you had something like
file.resource.loader.path = /foo, /woogie, /blargh
then joe/test.vtl would be looked for in
/foo/joe/test.vtl
/woogie/joe/test.vtl
/blargh/joe/test.vtl
> If so, then I still need to force my developer joe to retrieve files from
> /joe/*.vtl and disallow
> /john/*.vtl
Yes.
> (Remember, the base dir for the templates is /, with each developer in a
> sub directory).
Right. One way to solve this (and I don't really want to do this but
here goes) is to add to our lovely eventCartrige system, and add a
handler for #parse() and #include(), so it would allow you to preprocess
the arg. Something like :
public String validatePath( String path )
that would be called with the resolved argument to #parse() or
#include()
That way, you could simply tell your developers to not worry about the
paths in their templates, and then prepend the appropriate /joe, /john,
/sally, /whatever at run time...
That way you as the programmer could enforce template access from within
the tempalte based on application context, rather than trying to rig
some scheme up and trusting...
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: include / parse restrictions
Posted by Will Glass-Husain <wg...@forio.com>.
On Mon, 23 Jul 2001, Geir Magnusson Jr. wrote:
> > Geir, can you confirm that in the example below? A user goes to Joe's
> > application which is in:
> > /joe/abc.vtl
> >
> > My servlet reads "abc.vtl" from the URL and gets the template
> > "/joe/abc.vtl".
> >
> > The template does a #parse "../john/def.btl". This would be the path
> > "/joe/../john/def.vtl". All of this is within the template path. (who's
> > root is at "/".
>
> (where did the .. come from?)
>
Wait-- I get it. I've been assuming the path specified in the #parse is
relative to the path of the template. (which is in this example is in a
subdirectory "joe").
Sounds like you're telling me that the #parse is always relative to the
base template directory, even if the template is in a subdirectory. (Is
that true?)
If so, then I still need to force my developer joe to retrieve files from
/joe/*.vtl and disallow
/john/*.vtl
(Remember, the base dir for the templates is /, with each developer in a
sub directory).
WILL
Re: include / parse restrictions
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Will Glass-Husain wrote:
>
> > > directories. Right now, if Joe's template does:
> > > #parse("../john/abc.vtl")
> > >
> > > Joe can display the results from a different developer John's abc.vtl
> > > page.
> >
> > Actually, no he can't, because Velocity will not let you '..' your way
> > up the template paths if using templates from files.
> >
> > geir
> >
> >
>
> Geir, can you confirm that in the example below? A user goes to Joe's
> application which is in:
> /joe/abc.vtl
>
> My servlet reads "abc.vtl" from the URL and gets the template
> "/joe/abc.vtl".
>
> The template does a #parse "../john/def.btl". This would be the path
> "/joe/../john/def.vtl". All of this is within the template path. (who's
> root is at "/".
(where did the .. come from?)
> To confirm, Velocity will disallow the ".."? That surprises me, unless
> the code parses the path string explicitly.
Yes, it should, if you are using the FileResourceLoader... I will
test if it really works, though :)
> Appreciate the help from the list, BTW.
>
> WILL
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: include / parse restrictions
Posted by Will Glass-Husain <wg...@forio.com>.
> > directories. Right now, if Joe's template does:
> > #parse("../john/abc.vtl")
> >
> > Joe can display the results from a different developer John's abc.vtl
> > page.
>
> Actually, no he can't, because Velocity will not let you '..' your way
> up the template paths if using templates from files.
>
> geir
>
>
Geir, can you confirm that in the example below? A user goes to Joe's
application which is in:
/joe/abc.vtl
My servlet reads "abc.vtl" from the URL and gets the template
"/joe/abc.vtl".
The template does a #parse "../john/def.btl". This would be the path
"/joe/../john/def.vtl". All of this is within the template path. (who's
root is at "/".
To confirm, Velocity will disallow the ".."? That surprises me, unless
the code parses the path string explicitly.
Appreciate the help from the list, BTW.
WILL
Re: include / parse restrictions
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Will Glass-Husain wrote:
>
> I've got a security-related design question for a velocity-based web
> application I'm building.
>
> In this system, independent developers will upload velocity templates to
> be stored in separate directories. The idea is that each developer is
> creating an independent application with a unique group of users. In
> other words, a user goes to URL
> http://www.zzz.com/joe/
>
> and can use the application developed by Joe in VTL. A servlet that we've
> written parses the URL, logs the end-user in, and returns
> the template for the appropriate application based on the path.
>
> Joe (and all other developers) have no access to the server except through
> a web-based tool to upload VTL templates. These files are stored in 1
> directory per developer.
>
> Here's the question. Joe's application shouldn't be able to access
> templates (and other private data files) stored in other
> directories. Right now, if Joe's template does:
> #parse("../john/abc.vtl")
>
> Joe can display the results from a different developer John's abc.vtl
> page.
Actually, no he can't, because Velocity will not let you '..' your way
up the template paths if using templates from files.
geir
--
Geir Magnusson Jr. geirm@optonline.net
System and Software Consulting
Developing for the web? See http://jakarta.apache.org/velocity/
Be well, do good work, and keep in touch.
Re: include / parse restrictions
Posted by piero de salvia <pi...@yahoo.com>.
hi Will,
this kind of questions is the exact reason why I
encourage everybody to vote yes to the new
VelocityEngine, unless we want Velocity to remain just
another templating engine.
I suppose you could do what you want to do by placing
an ACL on subdirectories of an "applications"
directory, but I also suppose we cannot pretend that
every developer who approaches Velocity knows
java.security.* ( I dont'...).
Also, as I wrote some time ago, if we want
applications to be modular, as opposed to monolithic,
we need to just plop a WAR file under root with its
own velocity.properties, instead of messing with a
unique velocity.properties all the time. yes, I know,
it can be done with what we have now, but why doing
things the messy way?
piero de salvia
--- Will Glass-Husain <wg...@forio.com> wrote:
>
> I've got a security-related design question for a
> velocity-based web
> application I'm building.
>
> In this system, independent developers will upload
> velocity templates to
> be stored in separate directories. The idea is that
> each developer is
> creating an independent application with a unique
> group of users. In
> other words, a user goes to URL
> http://www.zzz.com/joe/
>
> and can use the application developed by Joe in VTL.
> A servlet that we've
> written parses the URL, logs the end-user in, and
> returns
> the template for the appropriate application based
> on the path.
>
> Joe (and all other developers) have no access to the
> server except through
> a web-based tool to upload VTL templates. These
> files are stored in 1
> directory per developer.
>
> Here's the question. Joe's application shouldn't be
> able to access
> templates (and other private data files) stored in
> other
> directories. Right now, if Joe's template does:
> #parse("../john/abc.vtl")
>
> Joe can display the results from a different
> developer John's abc.vtl
> page.
>
> Any suggestions as to how I can prevent this? My
> best idea (which still
> seems a bit unruly), is to use Geir's new
> instantiation capability to
> create a new velocity engine for each application
> when users log in.
> Then I would set the file resource loader path
> property for each one to be
> the application directory. This would constrain
> developers to include or
> parse only from their own directories.
>
> Any advice on hassle free ways to architect this
> would be appreciated.
>
> WILL
>
>
>
>
>
>
>
>
>
>
>
__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/