Re: [SMARTY] Re: assigned variable namespace updates

Yes, I think you are right that using objects is / can be unsafe. But I can accept this because access control is done within my objects. I use objects which represent database records. These do already check if a specific method can be called by the current user or not. On the other hand the design is made by myself or an designer. In other projects too only designers are able to manipulate templates. So they should know the correct API of the objects and should know which methods can be called and which can't. I don't think this harms the security very much as long as you can trust the designers of the templates. You don't accept foreign PHP code, disallow JavaScript in posts and even strip out img tags so why should you accept Smarty templates from untrusted sources? The advantages of using objects in templates seems to me higher than the risk of unsecure templates. At least in my case. And you are right to say "if you assigned the object to the template, you are accepting those conditions". André "Monte Ohrt" <monte@ispi.net> schrieb im Newsbeitrag news:1040048729.11060.6.camel@lena.ispi.prv... > Andrei and I discussed object assignments a little bit, we have somewhat > differing opinions. Andrei says it is unsafe, because there is nothing > stopping the template from calling object methods that could cause harm > such as methods that begin with "__". Currently there is nothing in PHP > to prevent this. My take on it is, if you assigned the object to the > template, you are accepting those conditions. > > Thoughts? > Monte > > On Mon, 2002-12-16 at 04:44, André Rabold wrote: > > *argh* That hits me hard :-( > > > > Before your modifications I could use class methods as function > > parameters... > > {myFunc value=$myObject->getVar("myVar")} > > > > $myObject->getVar("myVar") isn't parsed correctly by Smarty and > > will not be compiled to > > $this->_tpl_vars["myObject"]->getVar("myVar"). > > Instead Smarty will leave the string as it is. > > As long as "myObject" is in global namespace this works but after testing > > the CVS version I recieve an error that "myObject" is no object which is > > the result of your changes. > > I want implement further updates of Smarty in my application so what do > > you think about a flag to disable the new functionality? This would make > > it possible for me to use further updates of Smarty. > > > > Perhaps support for class methods should be implemented into Smarty > > which is a heavy requested feature as I read in the newsboard. I have > > already done some modifications to the Smarty_Compiler. You can read > > about them in the posting titled "Smarty Patch: Calling class methods in > > templates / Object handling". > > If the parser could correctly handle constructs like the following it would > > be really great: > > {$foo->getVar($bar->getVar("field"))} > > {fooFunction value=$foo->getVar($bar->getVar("field"))} > > > > For if statements it already works as expected. > > {if $API->isAuthorized($API->getCurrentModule(), _ACCESS_READ) } > > is compiled to something like > > if > > ($this->_tpl_vars["API"]->isAuthorized($this->_tpl_vars["API"]->getCurrentMo > > dule(), _ACCESS_READ) > > This is exactly what I want for both variable output ({$myVar}) and function > > parameters ({myFunc value=$myVar}). > > If this would work there would be no problems anymore ;-) > > > > Thanks for reading, > > André > > > > > > > > "Monte Ohrt" <monte@ispi.net> schrieb im Newsbeitrag > > news:1039711488.25435.39.camel@lena.ispi.prv... > > > I just committed to CVS some new changes to Smarty, most notably > > > assigned template variables are no longer extracted into global (PHP) > > > namespace. This extraction was extraneous and takes processing time, > > > more for every assigned variable. As a test, I made a template with 1000 > > > assigned variables. The execution time of this template was bettered by > > > over 30%. > > > > > > As a consequence, there aren't issues with variable clashing in PHP > > > namespace with assigned variables. We have to be careful with this, > > > hopefully no one is using variables in a template that are not > > > explicitly assigned. If you are, they won't show up anymore! > > > > > > Also, you can now embed variables in any quoted string, including > > > modifier arguments. > > > > > > {include file="$template/foo.tpl"} > > > {$foo|bar:"I am $name"} > > > {$foo|bar:"I am \$name"} {* for literal value, escape with \ *} > > > > > > I unleashed it on our development CMS environment (good test for just > > > about everything.) It all looks good initially, speed improvement is > > > noticable! > > > > > > If you upgrade, do the usual: > > > *) delete compiled templates > > > *) delete cached files > > > *) delete accelerator files > > > *) restart apache > > > > > > Please help test if you can! > > > Monte > > > > -- > Monte Ohrt <monte@ispi.net> >