X-Cart forums

[rubyaryat]

I recently revisited this problem and thought I'd share the solution.
Say you're setting up the help/conditions_customers.tpl page.
You want the smarty language variable:
{$lng.txt_conditions_customer}

to contain something like:


{$config.Company.location_address}

{$config.Company.location_city}, {$config.Company.location_state} {$config.Company.location_zipcode}


The trick is, in help/conditions_customers.tpl, instead of using the statement:
{$lng.txt_conditions_customer}

use:

{eval var=$lng.txt_conditions_customer}


This will render the smarty variables within the smarty variable {$lng.txt_conditions_customer}.

Hope this helps someone,
Rubyaryat

[balinor]

Nice one...moving to FAQ

[shan]

good find

[B00MER]

There's a reason eval is one letter away from evIl

Most interpreted and semi-compiled programming languages provide a feature in which it is possible to have a variable that contains program code statements, and have that variable executed by the interpreter. Examples are VBScript's Eval function and Execute and ExecuteGlobal statements, and PHP's and Perl's eval function and /e regular expression modifiers. People have even used Java's Reflection mechanism to make Java interpreters that may execute dynamic Java statements inside Java programs, e.g. BeanShell [64].

Needless to say, if user input, whether directly or indirectly, is incorporated in strings handed to the evaluation mechanism, an attacker may "extend" the web application to do whatever he wants it to do by passing code statements as part of his input. We should never include user input in strings passed to the eval family of functions.

Just to note, eval can be an evil function if it is overused, be sure and use such sparingly. It can become a security exploit and even cause excessive cpu cycles on your server end.