You are here: Foswiki>Tasks Web>Item13286 (05 Jul 2015, GeorgeClark)Edit Attach

Item13286: regular expressions encoded in a string loose their backslashes

Priority: Urgent
Current State: Closed
Released In: 2.0.0
Target Release: major
Applies To: Extension
Component: JQueryPlugin
Branches: master
Reported By: GeorgeClark
Waiting For:
Last Change By: GeorgeClark
the NAMEFILTER string is losing all the escapes in the regular expressions on Foswiki 1.2.

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

jQuery.extend(foswiki, {
 "preferences": {
    "PUBURL": "",
    "PUBURLPATH": "/pub",
    "SCRIPTURL": "",
    "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 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" />


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

-- MichaelDaum - 02 Mar 2015

ItemTemplate edit

Summary regular expressions encoded in a string loose their backslashes
ReportedBy GeorgeClark
Codebase trunk
SVN Range
AppliesTo Extension
Component JQueryPlugin
Priority Urgent
CurrentState Closed
Checkins distro:a1cf11d19368 distro:d6a10bf6ad86
TargetRelease major
ReleasedIn 2.0.0
CheckinsOnBranches master
masterCheckins distro:a1cf11d19368 distro:d6a10bf6ad86
Topic revision: r6 - 05 Jul 2015, GeorgeClark - This page was cached on 18 Sep 2021 - 01:55.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy