Forum OpenACS Development: Using tcl expressions in l10n messages

I just stumbled over some l10n messages with tcl expressions. e.g.: acs-tcl.lt_name_is_too_long__Ple_1

"%name% is too long. Please enter a value of at most [lindex $length 1] characters long. The value you entered was [string length $value] characters long."

As the expression is not being interpreted, I assume that tcl expressions are not allowed (anymore?). Instead
variables to be used in l10n messages need to be provided by the calling environment.

In our effort to follow OpenACS coding standards I was looking in particular at:
ad_page_contract_filter_proc_string_length

If my assumption is correct, I'd be happy to provide a patch. Otherwise I'd love to hear about alternative solutions.

Cheers
Klaus

Collapse
Posted by Gustaf Neumann on
Hi Klaus,

i am not sure, where and when the feature was lost, but altogether, allowing arbitrary commands in strings that could be supplied by users opens potentially a wide set of attack vectors (one could e.g. shut the server down via entries in the message catalog).

The better approach is to use named bind variables, such as:

ad_page_contract_filter string_length { name value length } {
    Checks whether the string is less or greater than the minimum or
    maximum length specified, inclusive
    e.g.address_1:notnull,string_length(max|100) will test address_1 for
    maximum length of 100.

    @author Randy Beggs (randyb@arsdigita.com)
    @creation-date August 2000
} {
    set actual_length [string length $value]
    if { [lindex $length 0] eq "min" } {
	if { $actual_length < [lindex $length 1] } {
	    set binding [list name $name actual_length $actual_length min_length [lindex $length 1]]
	    ad_complain "[_ acs-tcl.lt_name_is_too_short__Pl_1]"
	    return 0
	}
    } else {
	if { $actual_length > [lindex $length 1] } {
	    set binding [list name $name actual_length $actual_length max_length [lindex $length 1]]
	    ad_complain "[_ acs-tcl.lt_name_is_too_long__Ple_1 $binding]"
	    return 0
	}
    }
    return 1
}
Are you aware of situations, where this approach might be a problem?
Collapse
Posted by Gustaf Neumann on
this is now fixed in the oacs-5-8 branch. This must be most likely quite an old bug, since many packages use unescaped square brackets in message strings, some packages such as evaluation have even tcl code there (which i would not recommend). Seems as if the contract-filters "string_length" and "range" are not widely used.
Collapse
Posted by Noor Alam on
that is today preset inside the oacs-5-8 side. This specific have to be possibly very an old bug, because so many plans use unescaped sq . brackets in concept guitar strings, a number of plans like evaluate get even tcl value presently there (which i'd personally not really recommend). Would seem just as if this contract-filters "string_length" as well as "range" aren't trusted.

NoorAlamShahzad