You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by "Geir Magnusson Jr." <ge...@optonline.net> on 2000/11/06 07:20:23 UTC
#include
#include now works. #parse is coming tomorrow (or so). A brief summary
:
The syntax is
#include( arg1 [arg2 arg3 ...] )
where
argn = string literal or reference
yes, it requres the () and yes, it takes multiple args if you wish.
Also
#include( arg1 arg2 )
is equivalent to
#include( arg1 )
#include( arg2 )
What else ...
1) The included files *must* come from the template.path tree for
security reasons [#include(/etc/passwd) is uncool :) ] So if you have
content that lives outside of the template tree, link it in. We should
probably add a staticcontent.path property for this to allow the static
content to be separated from the templates.
2) The included filename must not have a .. in it (see #1).
3) If something other than a reference or stringlit is used as an arg,
an error will be logged and processing will continue.
4) If an incorrect filename is given (FileNotFound...) then an error
will be logged and processing will continue.
5) If there is an error, default behavior is silent in render output.
You can change this to make debugging easy for uses with two properties.
Both must be there to work:
include.output.errormsg.start = <!-- include error :
include.output.errormsg.end = see error log -->
You should see from above why two : so for HTML, you use above. For
Java, maybe /* and */. A vaguely helpful error will be placed between
errormsg.start and errormsg.end and written to the output. The point is
to see that something happened in the stream, to prompt you to look at
better error messages in the log.
geir
--
Geir Magnusson Jr. geirm@optonline.com
Dakota tribal wisdom: "when you discover you are riding a dead horse,
the best strategy is to dismount."
Re: #include
Posted by Daniel Rall <dl...@collab.net>.
Gunnar R|nning wrote:
>
> "Daniel L. Rall" <dl...@finemaltcoding.com> writes:
>
> >
> > This sounds like an excellent option, but I think that the ftp and http
> > paths should be specified via the same staticcontent.path property (in a
> > list).
>
> What is the rationale for this ? The static content path is important to
> protect local filesystem resources against exposure, but it would be a pain
> if we have to edit a property every time a new external content provider
> showed up.
>
> Okay, I can understand that some might want to restrict the external sites
> you can access from a template - but cant you do that another way ?
>
> Maybe a property :
>
> allowed_sites=http://www.cnn.com/,ftp://ftp.redhat.com
>
> and to open up all external access :
>
> allowed_sites=
>
> and to deny all external access :
>
> allowed_sites=none
I like your suggested implementation. I made my previous suggestion
because I do not like the idea of a per-template configuration.
--
Daniel Rall <dl...@collab.net>
Re: #include
Posted by Gunnar R|nning <gu...@candleweb.no>.
"Daniel L. Rall" <dl...@finemaltcoding.com> writes:
>
> This sounds like an excellent option, but I think that the ftp and http
> paths should be specified via the same staticcontent.path property (in a
> list).
What is the rationale for this ? The static content path is important to
protect local filesystem resources against exposure, but it would be a pain
if we have to edit a property every time a new external content provider
showed up.
Okay, I can understand that some might want to restrict the external sites
you can access from a template - but cant you do that another way ?
Maybe a property :
allowed_sites=http://www.cnn.com/,ftp://ftp.redhat.com
and to open up all external access :
allowed_sites=
and to deny all external access :
allowed_sites=none
regards,
Gunnar
Re: #include
Posted by Gunnar R|nning <gu...@candleweb.no>.
"Daniel L. Rall" <dl...@finemaltcoding.com> writes:
>
> This sounds like an excellent option, but I think that the ftp and http
> paths should be specified via the same staticcontent.path property (in a
> list).
What is the rationale for this ? The static content path is important to
protect local filesystem resources against exposure, but it would be a pain
if we have to edit a property every time a new external content provider
showed up.
Okay, I can understand that some might want to restrict the external sites
you can access from a template - but cant you do that another way ?
Maybe a property :
allowed_sites=http://www.cnn.com/,ftp://ftp.redhat.com
and to open up all external access :
allowed_sites=
and to deny all external access :
allowed_sites=none
regards,
Gunnar
Re: #include
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Gunnar R|nning wrote:
>
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
>
> > 1) The included files *must* come from the template.path tree for
> > security reasons [#include(/etc/passwd) is uncool :) ] So if you have
>
> Agreed, but what about support for http and ftp includes. We currently use
> this with Webmacro. Also how do you configure caching of included
> content ? Maybe a default property plus the ability to control this on a
> per include basis.
This sounds like an excellent option, but I think that the ftp and http
paths should be specified via the same staticcontent.path property (in a
list).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: #include
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
Gunnar R|nning wrote:
>
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
>
> > 1) The included files *must* come from the template.path tree for
> > security reasons [#include(/etc/passwd) is uncool :) ] So if you have
>
> Agreed, but what about support for http and ftp includes. We currently use
> this with Webmacro. Also how do you configure caching of included
> content ? Maybe a default property plus the ability to control this on a
> per include basis.
This sounds like an excellent option, but I think that the ftp and http
paths should be specified via the same staticcontent.path property (in a
list).
--
Daniel Rall <dl...@finemaltcoding.com>
Re: #include
Posted by Christoph Reck <Ch...@dlr.de>.
I will do includes of ftp and http via an url context tool:
$file.readURL(String url)
Note that my application will pass file contents into variables
for which the #include cannot be used (neither in WM). These
are passed either to a textarea (e.g. after counting lines) or
transparently to an applet in the browser.
Using such a context tool you then have full control of caching
algorithm and time-outs.
:) Christoph
Gunnar R|nning wrote:
>
> "Geir Magnusson Jr." <ge...@optonline.net> writes:
>
> > 1) The included files *must* come from the template.path tree for
> > security reasons [#include(/etc/passwd) is uncool :) ] So if you have
>
> Agreed, but what about support for http and ftp includes. We currently use
> this with Webmacro. Also how do you configure caching of included
> content ? Maybe a default property plus the ability to control this on a
> per include basis.
>
> regards,
>
> Gunnar
Re: #include
Posted by Gunnar R|nning <gu...@candleweb.no>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> 1) The included files *must* come from the template.path tree for
> security reasons [#include(/etc/passwd) is uncool :) ] So if you have
Agreed, but what about support for http and ftp includes. We currently use
this with Webmacro. Also how do you configure caching of included
content ? Maybe a default property plus the ability to control this on a
per include basis.
regards,
Gunnar
Re: #include
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
>
> #include now works. #parse is coming tomorrow (or so). A brief summary
> :
>
> The syntax is
>
> #include( arg1 [arg2 arg3 ...] )
>
> where
> argn = string literal or reference
>
> yes, it requres the () and yes, it takes multiple args if you wish.
>
> Also
> #include( arg1 arg2 )
>
> is equivalent to
>
> #include( arg1 )
> #include( arg2 )
Excellent Geir, that kicks some serious ass. :)
I really like the multi-arg improvement to the directive.
> What else ...
>
> 1) The included files *must* come from the template.path tree for
> security reasons [#include(/etc/passwd) is uncool :) ] So if you have
> content that lives outside of the template tree, link it in. We should
> probably add a staticcontent.path property for this to allow the static
> content to be separated from the templates.
#include'd files are generally not going to contain VTL. I'm all for
narrow interfaces (even in config files), but +1 on adding an additional
property to help manage static content.
> 2) The included filename must not have a .. in it (see #1).
Yup.
> 3) If something other than a reference or stringlit is used as an arg,
> an error will be logged and processing will continue.
>
> 4) If an incorrect filename is given (FileNotFound...) then an error
> will be logged and processing will continue.
>
> 5) If there is an error, default behavior is silent in render output.
> You can change this to make debugging easy for uses with two properties.
> Both must be there to work:
> include.output.errormsg.start = <!-- include error :
> include.output.errormsg.end = see error log -->
> You should see from above why two : so for HTML, you use above. For
> Java, maybe /* and */. A vaguely helpful error will be placed between
> errormsg.start and errormsg.end and written to the output. The point is
> to see that something happened in the stream, to prompt you to look at
> better error messages in the log.
That's beautiful man. The default behavior sounds very reasonable.
--
Daniel Rall <dl...@finemaltcoding.com>
Re: #include
Posted by Gunnar R|nning <gu...@candleweb.no>.
"Geir Magnusson Jr." <ge...@optonline.net> writes:
> 1) The included files *must* come from the template.path tree for
> security reasons [#include(/etc/passwd) is uncool :) ] So if you have
Agreed, but what about support for http and ftp includes. We currently use
this with Webmacro. Also how do you configure caching of included
content ? Maybe a default property plus the ability to control this on a
per include basis.
regards,
Gunnar
Re: #include
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." wrote:
>
> #include now works. #parse is coming tomorrow (or so). A brief summary
> :
>
> The syntax is
>
> #include( arg1 [arg2 arg3 ...] )
>
> where
> argn = string literal or reference
>
> yes, it requres the () and yes, it takes multiple args if you wish.
>
> Also
> #include( arg1 arg2 )
>
> is equivalent to
>
> #include( arg1 )
> #include( arg2 )
Excellent Geir, that kicks some serious ass. :)
I really like the multi-arg improvement to the directive.
> What else ...
>
> 1) The included files *must* come from the template.path tree for
> security reasons [#include(/etc/passwd) is uncool :) ] So if you have
> content that lives outside of the template tree, link it in. We should
> probably add a staticcontent.path property for this to allow the static
> content to be separated from the templates.
#include'd files are generally not going to contain VTL. I'm all for
narrow interfaces (even in config files), but +1 on adding an additional
property to help manage static content.
> 2) The included filename must not have a .. in it (see #1).
Yup.
> 3) If something other than a reference or stringlit is used as an arg,
> an error will be logged and processing will continue.
>
> 4) If an incorrect filename is given (FileNotFound...) then an error
> will be logged and processing will continue.
>
> 5) If there is an error, default behavior is silent in render output.
> You can change this to make debugging easy for uses with two properties.
> Both must be there to work:
> include.output.errormsg.start = <!-- include error :
> include.output.errormsg.end = see error log -->
> You should see from above why two : so for HTML, you use above. For
> Java, maybe /* and */. A vaguely helpful error will be placed between
> errormsg.start and errormsg.end and written to the output. The point is
> to see that something happened in the stream, to prompt you to look at
> better error messages in the log.
That's beautiful man. The default behavior sounds very reasonable.
--
Daniel Rall <dl...@finemaltcoding.com>