Add more variable types to drupal_to_js() [#126548]

This patch modifies the drupal_to_js() function to support other resource types such as functions and regular expressions. For this, a new notation has been introduced (and documented):

array(
  '#type' =&gt; 'function',
  '#value' =&gt; 'function(x) { alert(x); }'
);

array(
  '#type' =&gt; 'regex',
  '#value' =&gt; '/^(hello\\s+world)!?$/i',
);

You can also force existing types to be a certain type in JavaScript. For example, you have an indexed array in PHP and you want that to convert to a JavaScript Array. The normal behavior here is that it becomes a JS object as arrays don’t support indices in JS.

This patch is fully backwards compatible and doesn’t break existing use of this function.

Comment	File	Size	Author
	drupal-to-js.patch	3.69 KB	kkaefer

Comments

Comment #1

Steven commented 11 March 2007 at 00:15

Status:

Needs review

» Needs work

I'm not too sure about this syntax, as it mixes the structure of the data with structure for metadata. There is also the potential for confusion... what happens if I want to pass a Form API array through drupal_to_js()? This becomes impossible.

Whatever syntax we pick, it has to have a very low chance of colliding with real data.

I think we could make it much simpler, if we do it like this:

drupal_to_js(array(
'function my_function' => 'function(x) { alert(x); }'
'/my_regex/' => '/^(hello\\s+world)!?$/i'
));

becomes:

{ my_function: function (x) { alert(x); }, my_regex: /^(hello\s+world)!?$/i }

In other words: the syntaxes "function foo" and "/foo/" for the array keys indicate functions and regular expressions, respectively. There is no other change to array structure.

This does open up the possibility for exploits and XSS. The regular expression string and function body would be inserted as is, so if you were to pass raw, user-submitted data into drupal_to_js(), anyone could hijack anything. For example, specifying '' }); } } evilXSS(); as regexp or function to escape from the array (}), the function it is used in ();), and two more containing blocks (} }). Then we do whatever we want (it would be executed as soon as the script is loaded).

Because of this, I think the ability to use regexps and functions should defualt to off, and the doxygen for that parameter should carry a very big warning.

Comment #2

Steven commented 11 March 2007 at 00:19

Actually, 'myfunction()' should be a shorter and better solution than 'function myfunction'. It is just as clear what it means and shorter to type :).

Comment #3

Steven commented 11 March 2007 at 00:23

Oh and as for the ability to convert PHP associative arrays to JS arrrays, I don't see the point in this. The goal of drupal_to_js() is to match the PHP and JS as closely as possible. If you give it an associative array, an object comes out, because that's how JS does it.

If you want a JavaScript array, pass your array through array_values() before giving it to drupal_to_js(). I don't see why we would need to complicated drupal_to_js() with this.