Item8681: Func should provide safeTopicName function
Priority: Normal
Current State: No Action Required
Released In:
Target Release: n/a
Applies To: Engine
Component:
Branches:
http://trac.foswiki.org/browser/trunk/UiByRestPlugin/lib/Foswiki/Plugins/UiByRestPlugin.pm?rev=2378
The authors violated the Func:: encapsulation:
137 use Foswiki::UI::Manage;
138 $theNewTopic = Foswiki::UI::Manage::_safeTopicName( $theNewTopic );
In later versions this was moved to
http://trac.foswiki.org/browser/trunk/UiByRestPlugin/lib/Foswiki/Plugins/UiByRestPlugin/TopicRename.pm
Where the authors just duplicated the code:
150 # former Foswiki::UI::Manage::_safeTopicname()
151 $theNewTopic =~ s/\s//go;
152 $theNewTopic = ucfirst $theNewTopic; # Item3270
153 $theNewTopic =~ s![./]!_!g;
154 $theNewTopic =~ s/($Foswiki::cfg{NameFilter})//go;
This same code is used in Foswiki::UI::Rename
sub _safeTopicName {
my ($topic) = @_;
$topic =~ s/\s//go;
$topic = ucfirst $topic; # Item3270
$topic =~ s![./]!_!g;
$topic =~ s/($Foswiki::cfg{NameFilter})//go;
return $topic;
}
However:
- This code should be centralised and made available throughout, for both core and plugins
- This code is quite crude: the javascript version capitalizes each new word rather than just stripping them out.
--
MartinCleaver - 08 Mar 2010
I tried to add some documentation to System/TopicsAndWebs better explaining what is acceptable for Topic names. It would be good if this and other places that filter for valid topic names should use common rules.
A note on Topic Names
The best strategy is to use WikiWords for your topic names. In this way,
linking is automatic, as described above. However if you have custom
requirements for non-standard names, you can use "Forced Links" written inside
square brackets to force a link to a non-standard topic name. Forced links
are subject to some special rules and the actual topic name visible in the URL
may anot be identical to what was entered into the forced link.
- The first letter of each "word" will be automatically capitalized
- Spaces are compressed out of the topic name
- The following special characters are removed: (The default rules may be different at your installation):
- Any other "whitespace" characters
-
*
(Asterisk)
-
?
(Question mark)
-
~
(Tilde)
-
^
(Caret / Circumflex)
-
\
(Backslash)
-
$
(Dollar-sign)
-
@
(At-sign)
-
%
(Percent-sign)
-
`'"
Quotes (Open-quote, Close-quote/Apostrophe, and Double-quote)
-
&
(Ampersand)
-
;
(Semicolon)
-
|
(Vertical line)
-
<>
(Less and Greater signs)
-
[]
(Open and close square brackets)
- And any ASCII control characters (Hex x00-x1f)
For an example, If you enter [[my special-topic @here]]
, you will see my special-topic @here
, but the actual topic created will be MySpecial-topicHere
.
Note that if you use the Topic Creator, WikiWord rules
are strictly enforced and the resulting topic name would be MySpecialTopicHere
For more details on forced links, see EditingShorthand#HeRe
--
GeorgeClark - 08 Mar 2010
Not only should it be consolidated with any sanitizeWikiWord, it looks like there is some duplication even within Render.p:
http://trac.foswiki.org/browser/trunk/core/lib/Foswiki/Render.pm?rev=5954
605 $topic =~ ucfirst($topic);
606 $topic =~ s/\s([$Foswiki::regex{mixedAlphaNum}])/\U$1/go;
843 # Capitalise first word
844 $link = ucfirst($link);
845
846 # Collapse spaces and capitalise following letter
847 $link =~ s/\s([$Foswiki::regex{mixedAlphaNum}])/\U$1/go;
848
849 # Get rid of remaining spaces, i.e. spaces in front of -'s and ('s
850 $link =~ s/\s//go;
--
MartinCleaver - 08 Mar 2010
I oppose the idea of a sanitisation function. The Sandbox API is exposed to plugins authors, and they should be using the validate-and-untaint functions in there to validate data. I don't think there's any need for more - renaming topics without being absolutely sure the user knows what is going on and - importantly - case reverse the encoding is definitely a no-no.
--
CrawfordCurrie - 13 Jun 2010