Re: [SMARTY-DEV] Bug in Smarty Compiler concerning constants?

--- Oliver Jones <[email protected]> wrote:
> On Tue, 2005-03-08 at 07:26 -0800, boots wrote:
> > Erk, no, I meant PHP constants simply aren't supposed to be
> > producible as clear tokens from Smarty. I wasn't suggesting a new 
> > behaviour -- that's the way it already is. You found a bug where 
> > they are being let through. 
> 
> I see.  Well then I will "correct" my code to avoid the bug.  Though
> personally I think it makes the code look very ugly.  

It is certainly heavier. sigh.

> > I can't speak for why it was included in the first place but an
> > interface onto constants is consistent with Smarty's conception of
> > using data provided from outside. It also makes possible a more
> > secure restricted environment where you don't want the possibility 
> > of leaking any non-passed information from PHP into the user 
> > templates. This prevents, amoung other things, common paths stored 
> > in constants (eg: SMARTY_DIR) from being accessible to template 
> > users.
> > 
> > I'm not a huge fan of the $smarty reserved var either, but I don't
> > think we should make a special case for their handling for if tags.
> 
> Your reasoning is sound.  You are right, things should be explicitly
> passed to smarty for use in the templates.  Though for the sake of
> code cleanliness perhaps we should instead have some sort of facility

> to set constants in the same manner as we set 'variables' with 
> assign() (perhaps an assign_constant() method).  That way the
compiler
> could inspect the constants map and treat them accordingly.
>
> Just an idea.

IIR, whitelisting constants was considered for security mode (similar
to whitelisting PHP functions in security mode) but it was decided to
be a simple switch. By default, constants are not at all available when
security is on, but you can alter that by setting the ALLOW_CONSTANTS
item to true in the $security_settings member. The idea is that if you
are going to trust constants, you are probably want to trust all
constants. If there are in fact just a few constants you want to
expose, you are probably better off simply assigning them to a custom
associative array template variable (eg: $CONST). By default
(particularly with security on) arrays are read-only in user templates
so this amounts to nearly the same thing.

That said, I don't think anyone considered whitelisting constants so
that they can be used as straight tokens (at least at that time). I
think there are other problems with that. For one thing, Smarty is very
loose about quoting strings. In nearly every context where an
"expression" is expected, unquoted text is treated as a literal text
token (with notable exceptions such as smarty's usage of: true, yes,
on, false, no, off, null; the booleans are also special in that even if
quoted, Smarty will identify them as booleans). Because of this, I
don't doubt it could potentially be a bit of a chore to try adding
constants to the parsing regex's. Asides from that, it will undoubtedly
play havoc with existing templates that rely on Smarty's behaviour.
Even to simply close the bug that you discovered will be a chore. I
quickly looked at the regex's that are behind it; remembering the
trying time that Monte had with the object method handling a few
versions ago I'm really hoping that Someone Else(tm) takes an interest
in fixing it.

aside: PHP5 class constants are not supported at all, AFAIK. Perhaps
one fine day when someone cooks up the next generation of Smarty it
will have better integration with PHP constants or maybe it will ignore
them altogether. To paraphrase another PHP list, "Smarty != PHP" (but
it doesn't fall too far from the tree either)

xo boots