465029 - Warn when creating articles with bad characters

Status: VERIFIED FIXED

(support.mozilla.org :: Knowledge Base Software, task)

Description

[[:Cww]]

There is no warning when you try to create an article (either through the creating articles page or via translation) and the article title contains invalid characters.  Since there's no sanitizing of invalid title characters, you can go all the way, write the article and click submit, only to find that the article can't be linked to or accessed because of those characters.

Invalid characters are: :/?#[]@!$&'()*+,;=.<>

This means that contributors will make articles with Firefox version numbers (3.0.X) or phrases like and/or or (parentheticals) in the title and have no idea why their article doesn't show up after editing.

What would be nice is a little javascript that checks your proposed article title to make sure that it's OK before you click and make the article.

< and > don't break the wiki but aren't sanitized so you can inject HTML here.  (<script> tags are <x>'d)

Comment 3

[[:Cww]]

So we can block these characters but some (like ' and . and ()) are really really useful to have in article titles.  (Slashes will break lots of things so those have to be sanitized) I'm going to file bugs for making the wiki allow those characters and the remaining ones can be sanitized on the creating+articles page.

Comment 4

[Paul Craciunoiu [:paulc]]

Perhaps upgrading tiki will take care of this.

Comment 5

[Paul Craciunoiu [:paulc]]

Sylvie, any changes in a later version of Tiki that allow for the characters listed here? (and if so, which)
Thank you :)

Comment 6

[sgreverend]

This should be fixed in 3

Comment 7

[Paul Craciunoiu [:paulc]]

Thanks Sylvie. Could you point me to the bug(s)/pactch(es) that fix this? I would hope there's an easy way to merge the changes into the SUMO version.

If this isn't an easy merge, Laura, David: perhaps we can just wait for the update.

Comment 8

[sgreverend]

We clean the code all over the place with smarty functions {title}, {sefurl}....Hard to point directly to a commit.

Comment 9

[Paul Craciunoiu [:paulc]]

What we can do is simply not allow the editpage to show up if the title contains bad characters. That will work and does not require javascript.
Since article title is not actually an input field on the page, but only in the URL, we can just provide a warning message and text input on the page, instead of the full edit with the textarea + categories + etc...
E.g. when you go to
https://support-stage.mozilla.org/tiki-editpage.php?page=test<title

Sound good?

Comment 10

[David Tenser [:djst]]

Sounds good to me - Chris, would this work for you?

Comment 11

[Chris Ilias [:cilias]]

I'm not sure I follow. The main place to create a page is via <https://support.mozilla.com/en-US/kb/Creating+articles> or <https://support.mozilla.com/tiki-edit_translation.php>, which both provide a text field.

Comment 12

[Paul Craciunoiu [:paulc]]

(In reply to comment #11)
> I'm not sure I follow. The main place to create a page is via
> <https://support.mozilla.com/en-US/kb/Creating+articles> or
> <https://support.mozilla.com/tiki-edit_translation.php>, which both provide a
> text field.
True, but both of those ultimately lead to tiki-editpage.php?locale=blah&page=title+of+page

Comment 13

[Chris Ilias [:cilias]]

What would happen if someone tries to create an article with an illegal character? "a warning message and text input on the page"? If so, that sounds good to me.

Comment 14

[Paul Craciunoiu [:paulc]]

Attachment: patch, v1

This patch adds a content label called "badchars_notify_data" to tiki-editpage.php
When any of the bad chars are in the title, the rest of the page does not display, so it cannot be created. Also, the edit form displays if the page already exists, and the author sees the warning at the top and should change the title accordingly.

The text for the content label is:
---------------------------
<div class="top-notify">{tr}The article title you are trying to edit contains one or more of the following disallowed characters:{/tr} {$page_badchars_display}
<form method="get" action="/tiki-editpage.php"><h3>{tr}Please enter a new title{/tr}</h3><input type="text" size="15" name="page" value="{$page}" /><input type="submit" name="quickedit" value="{tr}Edit{/tr}" /></form></div>
---------------------------
We can always change this text, of course.

Comment 15

[Paul Craciunoiu [:paulc]]

Oops. I meant the content label name is "editpage_badchars_notify" :)

Comment 16

[[:Cww]]

SELECT lang, pageName FROM tiki_pages where pageName REGEXP '[[.:.][./.][.?.][.#.][.[.][.].][.@.][.!.][.$.][.&.][.\'.][.(.][.).][.+.][.,.][.;.][.=.][...][.<.][.>.]]'; is the query to find all KB articles that have bad titles.  Putting it here so we know to go through and fix them.

Comment 17

[Paul Craciunoiu [:paulc]]

r48073 / r48074

Comment 18

[Paul Craciunoiu [:paulc]]

This shows up for staging articles. Patch to follow.

Comment 19

[Paul Craciunoiu [:paulc]]

Attachment: patch to patch, v1

Comment 20

[Paul Craciunoiu [:paulc]]

r48208 / r48209

Comment 21

[Stephen Donner [:stephend] Not actively reading bugmail]

Yet another bug where content needs to be created and assigned on staging?  (Please also add the instructions to the push bug for 1.3 when that time comes.)

Comment 22

[Paul Craciunoiu [:paulc]]

Attachment: editpage_badchars_notify: content label

I've created it on staging and attached it here.

Comment 23

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED; nice work!  Tried all the characters listed there; all attempts to create with any of those failed -- without any of those characters, creation succeeds.

Comment 24

[Paul Craciunoiu [:paulc]]

This warning breaks creating translations with bad characters. The translation data should be passed over along with the new title.
STR:
1. Go to any article, click "translate this page" and enter a title containing bad characters.
2. Click "Create translation"
2. On the next page, you're prompted to change the title. Change it to a valid title. Click "Edit"
3. The translation data is lost.

The fix won't be too hard and it can be done in the template. Basically it involves carrying the translation data over.

Comment 25

[Paul Craciunoiu [:paulc]]

Attachment: editpage_badchars_notify: content label v2

This is the updated content label. The only change is removing the form tag.

Comment 26

[Paul Craciunoiu [:paulc]]

Attachment: patch, v3

This adds hidden form inputs to make sure the submitted information gets posted until the title selected is valid. I really should've done this from the start.

Comment 27

[Paul Craciunoiu [:paulc]]

r49759 / r49760

Updated the content label on stage and also created it on prod to match attachment 395615 [details]
https://support-stage.mozilla.org/tiki-edit_programmed_content.php?locale=en-US&contentId=215
https://support.mozilla.com/tiki-edit_programmed_content.php?contentId=217

Comment 28

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED on https://support-stage.mozilla.org/tiki-editpage.php?locale=en-US.

Comment 29

[Paul Craciunoiu [:paulc]]

That URL probably had some post data to it -- doesn't work when just linking to it.

Comment 30

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to comment #29)
> That URL probably had some post data to it -- doesn't work when just linking to
> it.

Yeah, but that page is shared when editing pages and/or doing translations.

Comment 31

[Marc Laporte]

Great work. This has been annoying me for years. And it's not just for page names, but also tags, usernames, etc.

Related discussion:
http://dev.tikiwiki.org/Character+substitutions

I look forward to the upstream!

Comment 32

[Louis-Philippe Huberdeau]

<> are no longer possible as they get filtered out.

For the other characters, I too the check almost as-is in the PHP file. For the template, I made it a suggestion by default. the wiki_badchar_prevent switch can be turned on to disallow them completely.

The page name field was made part of the standard form rather than creating a new form with hidden fields to ease maintainability. The save buttons are disabled if prevent is turned on.