Details
Minor Description
I've created a simple but flexible new event handler that is called by the
#parse and #include directive. This event handler takes as an argument the
resource path argument for #parse or #include, and returns a modified path
indicating the resource to actually be returned. If the event handler returns
null, no page is included.
This has many uses. A few examples.
– Relative path. All #include/#parse directives can be forced to refer to a
directory relative to the current template
– Security. A page can be restricted to only be able to refer to a
particular group of pages.
– Localization. Templates can include pages for a particular language or
region, and the app can switch those pages to refer to a different language or
region as appropriate.
This patch is 100% backwards compatible with existing templates and code.
Personally, I have urgent need of this feature. My web app allows numerous
(untrusted) users to upload templates into a common web space (each user has
their own directory). A major problem was that users could access other
user's pages with #parse and #include. In just a few lines of code, I've
implemented a security-oriented implementation of this event handler to allow
each user to only be able to include their own set of pages. Without this
event handler, I was not able to figure out a straight forward solution to
this problem.
As a side note, I believe this presents an elegant way to solve this problem
as well (allowing the developer to force paths to be relative to the template).
http://www.mail-archive.com/velocity-dev@jakarta.apache.org/msg07223.html
Best, WILL
P.S. If this approach is acceptable to the committers, I'll go ahead and
create test cases and documentation in relatively short order. I've already
built some informal test code. I can't run "ant test" completely as it fails
(on the encoding test), even without the patch, but it ran fine up until that
point.