Item13286: regular expressions encoded in a string loose their backslashes

the NAMEFILTER string is losing all the escapes in the regular expressions on Foswiki 1.2.

To debug this I modified FOSWIKI.pm on 1.1.9 and 1.2.0 to insert an alert:

jQuery.extend(foswiki, {
 "preferences": {
    "PUBURL": "http://foswiki.fenachrone.com/pub",
    "PUBURLPATH": "/pub",
    "SCRIPTSUFFIX": "",
    "SCRIPTURL": "http://foswiki.fenachrone.com/bin",
    "SCRIPTURLPATH": "/bin",
    "SERVERTIME": "27 Feb 2015 - 23:57",
    "SKIN": "natedit,pattern",
    "SYSTEMWEB": "System",
    "TOPIC": "WebHome",
    "USERNAME": "admin",
    "USERSWEB": "Main",
    "WEB": "Sandbox",
    "WIKINAME": "AdminUser",
    "WIKIUSERNAME": "Main.AdminUser",
    "NAMEFILTER": "[\s\*?~^\$@%`\"'\x26;|\x3c>\[\]#\x00-\x1f]"
}});
alert( foswiki.preferences['NAMEFILTER'] );</script>

On 1.1.9, the alert shows all the backslashes in NAMEFILTER. On 1.2.0, the backslashes are all removed. This explains why the WebCreateNewTopic dialog is not working on 1.2.

This can be fixed on 1.2, by modifying core to double all the backslashes in the NAMEFILTER before it is added to the script tag. I've tried switching jquery to 1.8.3 on Foswiki 1.2, but it still fails.

-- GeorgeClark - 28 Feb 2015

Michael, fixing this in FOSWIKI.pm is difficult because the NAMEFILTER field is rendered late by the %ENCODE% macro. The fix I came up with added a new encode type of 'regex' and uses that type for the NAMEFILTER field. Unfortunately that's not backwards compatible to 1.1.x, so I can't check it in. The real fix would be to not lose the escapes in the first place.

-- GeorgeClark - 28 Feb 2015

Two things:

(1) What do we need NAMEFILTER for ... I mean really ... in javascript land?

(2) To prevent jquery.extend() to mistreat the regex string we could add a RegExp constructor which will create an appropriate Object before jquery.extend() sees the string. I still doubt that jquery.extend() does remove any escapes. This would rather be done by string interpolation of javascript. I will check that.

This here is worth a try:

jQuery.extend(foswiki, {
 "preferences": {
...
    "NAMEFILTER": /[\s\*?~^\$@%`\"'\x26;|\x3c>\[\]#\x00-\x1f]/
}});

Note that alert() might lie to you with regards to string interpolation. Better use console.log(foswiki.preferences.NAMEFILTER)

-- MichaelDaum - 28 Feb 2015

1) - well we need it partly because it works in 1.1.9 I looked at the jquery WikiWord, but it appears to be very restrictive on what's valid.

NAMEFILTER derived from {NameFilter} allows the javascript code to use identical rules to the Perl code that validates topic names. So if a user enter "my@$foo barTopic", they will get MyFooBarTopic as the topic name. Illegal characters are filtered out and core will be happy with it.

I'll play around with log vs. alert, but it's really quite mystifying, as I showed above, the alert in the same script tag as the extend gives different results on 1.1.9 and 1.2.0 with identical input. ..., even when I drop 1.2.0 back to jquery 1.8.3. I'm rather baffled.

The problem with your above code is the script tag is generated. So it's not straight forward to change the encoding:

    foreach my $pref ( split( /\s*,\s*/, $prefs ) ) {
        push @prefs,
          '    "' . $pref . '": "%ENCODE{"%' . $pref . '%" type="quote"}%"';
    }
    my $text =
"<script type='text/javascript'>\njQuery.extend(foswiki, {\n \"preferences\": {\n"
      . join( ",\n", @prefs )
      . "\n}});\n</script>";

-- GeorgeClark - 01 Mar 2015

NAMEFILTER is now properly escaped while creating the foswiki.preferences

While looking over jquery.wikiword, I fixed it's parameter handling so that it can be used this way:

*Title* %BR%
<input type="text" name="TopicTitle" size="80" />

*Topic will be named:* %BR%
<input type="text" name="topic" class="jqWikiWord" data-source="input[name=TopicTitle]" data-forbidden-regexp="%ENCODE{"{NAMEFILTER}" type="entity"}%" disabled size="80" />

%JQREQUIRE{"wikiword"}%

Note that this approach doesn't require NAMEFILTER in foswiki.preferences.

-- MichaelDaum - 02 Mar 2015

Commenting is disabled while not logged in