[ZPT] Re: Path Interpolation

[Jim Fulton]

 > I just noticed that
 > http://dev.zope.org/Wikis/DevSite/Projects/ZPT/VariablesInPaths appears
 > to have the approval of both Guido and Jim, so I'm hoping to clean up
 > one detail and then implement it.

No, it does not have my approval. I suppose I should go ahead
and officially reject it.

I can live with making the current undocumented path interpolation
syntax official and changing the special character to a '$'.
I am against making it equivalent to string interpolation, which is
why I'm still queezy about using the '$' symbol. The purpose
of interpolation is to let a name or *key* be provided as data.
In such a case, a slash should not be significant in the name or key.


 > The detail is this: if "path:$x" uses simple string interpolation (which
 > the syntax strongly implies), then given x="a/b", this expression is
 > equivalent to "path:a/b".  This isn't a problem if you defined 'x', but
 > it's a potential security hole if 'x' came from an untrusted source.
 >
 > For example, if you put the following into a template:
 >
 >    <img tal:attributes="src here/images/foo_${request/foonum}" />
 >
 > ...then a hostile request with query string "foonum=003/path/to/bar"
 > could cause traversal to an arbitrary object.
 >
 > This is why the current (undocumented) syntax "path:var1/?var2" is
 > designed so that "?var2" is always a single path step when 'var2'
 > contains a string.

As I remember it, the reason for this is that the value of var2 might
contain characters that would be meaningful in a path expression if they
were interpreted, this breaking the interpolation in odd and unexpected
ways.

 > It *does* traverse multiple steps if 'var2' contains
 > a sequence, which combined with Zope's ':list' marshalling causes the
 > same problem :-(

This sounds like a bad missfeature. This is one of the reasons that this
was an experimental feature.

 > Normally I would expect the default case to the safe one, while allowing
 > you to explicitly accept risk (as with HTML-escaping and the 'structure'
 > keyword).  In this case, though, I suspect that the vast majority of
 > usage will not involve untrusted data, and the expected semantics of '$'
 > are strong enough to choose the other course.

Do we have anyt use cases where people *really* want the value of an
interpolated variable to be treated as a path expression? I can't
think of any.

 > I recommend that '$'-expansion be treated as simple string
 > interpolation, and that an alternate syntax should be provided which
 > renders slashes in the value inert.  This could be '?', suitably
 > altered, so that "here/images/foo_?{request/foonum}" would cause the
 > example above to look for (and probably fail to find) an object in
 > 'here/images' with the id "foo_003/path/to/bar".

I recommend that the current syntax be made official absent the sequence
handling missfeature, as you suggest.

This means that interpolation can only be performed for a path segment,
the '?' is only meaningful immediately after a slash, and characters in
the interpolated value have no meaning other than data.

I could have my arm twisted to use the '$' character, but I think
that this is a bad idea.

I would need to see some really convincing use cases to support
general string interpolation in paths.

Jim



-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org