I thought the discussion was about not allowing template designers to
arbitrarily create objects (aside from the on-the-fly lists, Integers,
and Strings). That IS a security problem. However, I think the
programmer should keep control of the methods by not passing classes
in the context with dangerous methods. My policy with Velocity is
to only pass immutable classes to the context.
BTW, I never pass a HashMap to the context. I have created a class
called SecureHashMap that looks exactly like HashMap but overrides all
methods that would change the content so they do nothing. So in
actual practice, my last line would read:
ctx.put("map",new SecureHashMap<String, String>(hm));
Barbara Baughman
X2157
On Wed, 7 Jun 2006, Nathan Bubna wrote:
> Allowing a template to call arbitrary methods is only dangerous if you
> are allowing 3rd-parties to create templates and do not have your java
> security policies properly configured for that.
>
> Calling arbitrary methods does also allow for bad design if you allow
> methods which change model state to be called.
>
> I would say it is likely that we will someday block "dangerous"
> methods by default (or with a simple switch). However, it is
> extremely unlikely that we would go so far as to block method calls
> that would lead to "bad" design, and we will definitely never block
> Map.get(). :)
>
> On 6/7/06, Keith R. Bennett <[EMAIL PROTECTED]> wrote:
> > Barbara -
> >
> > Thank you, that worked beautifully.
> >
> > I remember reading somewhere, though, that allowing a template to call
> > arbitrary methods (that is, methods other than bean-like getters) on
> > classes was dangerous, and that support for it might be eliminated in a
> > future version. Is this true, and if so, would it affect Map.get()?
> >
> > - Keith
> >
> >
> > Barbara Baughman wrote:
> >
> > >Try using a Map interface object like HashMap or TreeMap.
> > >
> > >HashMap<String, String> hm=new HashMap<String, String>();
> > >hm.put("a","apple");
> > >hm.put("b","blueberry");
> > >ctx.put("map",hm);
> > >
> > >Then in Velocity:
> > >
> > >#foreach ($key in $map.keySet())
> > > $key $map.get($key)
> > >#end
> > >
> > >Barbara Baughman
> > >X2157
> > >
> > >On Wed, 7 Jun 2006, Keith R. Bennett wrote:
> > >
> > >
> > >
> > >>What Velocity template code can I use to get a list of keys and iterate
> > >>over that list, getting the value corresponding to each key? Here is
> > >>what I've tried so far:
> > >>
> > >>Before calling Velocity, I place the list of keys plus each key/value
> > >>pair in the context. For example:
> > >>
> > >>--
> > >>String [] letters = { "a", "b" };
> > >>context.put("letters", letters);
> > >>context.put("a", "apple");
> > >>context.put("b", "blueberry");
> > >>--
> > >>
> > >>In the template I have:
> > >>
> > >>--
> > >>$a
> > >>$b
> > >>
> > >>#foreach ( $letter in $letters )
> > >>$letter
> > >>${${letter}} ## <-- This is the line in question
> > >>#end
> > >>--
> > >>
> > >>However, the output is:
> > >>
> > >>--
> > >>apple
> > >>blueberry
> > >>
> > >>a
> > >>${a}
> > >>b
> > >>${b}
> > >>--
> > >>
> > >>The ${a} and ${b} above should be apple and blueberry instead.
> > >>
> > >>What can I use in the line in question to dereference the reference?
> > >>
> > >>Also, is there a better way of accomplishing my goal, which is this?:
> > >>
> > >>I have an app that will have database records of arbitrary type. The
> > >>record metadata allows me to get the field names with which to populate
> > >>the Velocity context. The record itself has, of course, the data. I
> > >>want the Velocity template designer to be able to loop through the
> > >>fields in the database record without knowing its format at design time,
> > >>as in:
> > >>
> > >>#foreach ($fieldName in $field_names)
> > >> <$fieldname>
> > >> ... ## put the field's value here, as in my vain attempt above
> > >> ## with ${${fieldname}}
> > >> </$fieldname
> > >>#end
> > >>
> > >>The data record is not a Java object with named field member variables,
> > >>so I can't use the Java Bean approach. Perhaps I could create a class
> > >>dynamically at runtime, but I expect this would be overkill.
> > >>
> > >>Thanks for any help you can offer.
> > >>
> > >>- Keith
> > >>
> > >>
> > >>---------------------------------------------------------------------
> > >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>For additional commands, e-mail: [EMAIL PROTECTED]
> > >>
> > >>
> > >>
> > >>
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
