Bug: $securityFilter in TWiki.cfg is altered by UpgradeTWiki

The UpgradeTWiki script alters the $securityFilter variable in TWiki.cfg. In the distribution, the variable is set to:

$securityFilter     = "[\\\*\?\~\^\$\@\%\`\"\'\&\;\|\<\>\x00-\x1F]"; 

$securityFilter = '[\\*?~^$@%`"\'&;|<> -]'; 

This in turn produces other errors, I had some problems with spaced WikiWords, leading to this discovery.

Discussion from KnownIssuesOfTWiki01Sep2004:

Something seems to have changed with spaced wiki words. [[A wiki word]] in Beijing would become AWikiWord - but in Cairo it looks like it becomes Awikiword instead. This gives me lots and lots of broken links, and I'm unsure which strategy to follow now - I could change the spaced words, uppercasing the first letter of each word ([[A Wiki Word]]) or I could rename affected pages to the new Awikiword-style? Or perhaps did I just miss a configuration parameter that could give me back the automatic CamelCase? - Anyway, here at twiki.org it seems the Beijing-style is in use (eg. Sandbox.SpacedWordTest) ..?

• Lets see: web notify ([[web notify]]) should link to WebNotify and it does. This is the current spec. In your case possibly different because of locale setup? In any case, Awikiword is incorrect, as a workaround, use just [[AWikiWord][A wiki word]] type links -- PTh
  • Ahh, the sequence of things ... what has happened here, is that my choice of editor is not very happy with unprintable chars. First time I edited TWiki.cfg it changed a character in the $securityFilter variable, resulting in this error: Invalid [] range " -" in regex; marked by <-- HERE in m/[\*?~^$@%`"'&;|<> - <-- HERE ]/ at ../lib/TWiki.pm line 417. So I (thought I) just deleted the bad char, but apparently the editor still left a regular space in the variable, resulting in the bad casing. I have now removed both the unprintable chars - but of course, now I'm uncertain if I opened up a security hole this way. Is there another way to represent the two chars (to make it comply with my bad choice of editor ..)? It looks like it's the hex values "00" and "1F" that bugged me. -- SteffenPoulsen - 06 Sep 2004
  • On second thought this actually looks like it might stem from a problem with the upgrade script. The regexp in the $securityFilter variable looks good in the untouched Cairo distribution, but the merged version the upgrade script produces has a corrupted "non-expanded" versíon. I'll check this one out next time I get a chance to run the script. -- SteffenPoulsen - 06 Sep 2004

Test case

Try running UpgradeTWiki against any Beijing release, and examine TWiki.cfg in the merged output.

Environment

-- SteffenPoulsen - 06 Sep 2004

Follow up

Fix record