Item8713: Incorrect behavior when invalid web name built when converting spaced text to a topic name.

The following forced link

discuss 'wiki': philosophy vs. technology

results in creating a topic named Technology, with preceding text ignored.

The transformation from forced link follows the rules, converting illegal characters, to spaces, capitalizing words after a space, removing spaces, and converting period to slash.

DiscussWiki:PhilosophyVs/Technology

It appears that the colon in the "web name" causes the web name to be completely ignored, and the topic name of "Technology" is created in the "Main" web, not the current web.

If the colon is omitted, the topic fails with a missing web, which is the expected behavior.

If the colon is included on the right side of the name - as in Tech:nology - then the topic created is Main.Tech:nology including the colon.

I believe that the bug is that both examples should fail with an invalid or missing web. The topic should not be created in the default "Main" web.

Write	Get	Comment
[[ab.c:d]]	ab.c:d	Submits bin/edit/Ab/C:d and fails with: "Ab web does not exist"
[[a:b.c:d]]	a:b.c:d	Submits bin/edit/A:b/C:d which ignores the A:b web and creates topic C:d in the Main web

The invalid web A:b should not be silently ignored.

-- GeorgeClark - 15 Mar 2010

Note: Trying to recreate this problem by calling Func::saveTopic with the invalid A:B web results in Meta creating an "empty" A:B directory, and saves the topic in the correct web. See FuncTests::test_Item8713 (currently commented out).

-- GeorgeClark - 09 Jun 2010

The cause of this is in Foswiki.pm around line 1767. The Webname is passed through Foswiki::Sandbox::validateWebName which returns null if the web is invalid. The code then tests the webname and changes it to the configured UsersWeb (Main) if not set.

This can result in operations being silently performed on topics in Main without any indication to the user that the incorrect topic is edited or created. For example, in addition to creating a topic in the wrong web, A:B.WebPreferences will show the user the "missing topic" link, but will actually cause the user to edit Main.WebPreferences - without any indication that they are editing in the wrong web. If the URL is entered manually - http://trunk.foswiki.org/A:B/WebPreferences - then the user will be taken to WebPreferences.

I'm not sure the best way of correcting this, or why the web is replaced with Main web.

The other issue with Func is somewhat unrelated. I've coded a fix for this, but it breaks a number of unit tests that reference Webs without actually populating the web first. In addition, the populateWeb function copies the template web in alphabetical order, and the web is not really valid until the WebPreferences topic is created. So populateWeb had to be changed to first create a WebPreferences topic, and then copy the template web.

I'm setting this task to urgent because I suspect it explains some unintended edits of pages at some production sites. Also changing the summary to better reflect that the Web component of the spaced name was incorrect.

-- GeorgeClark - 11 Jun 2010

A bit more information.

• The invalid web name is initially created in Render::_handleSquareBracketedLink - which will allow a webname to be created which is invalid.
• Foswiki::new does the substitution of UsersWeb for a missing web in the process of handling the missing web/topic default of Main/WebHome.
• normailzeWebTopicName also defaults to the UsersWeb if the web is missing

-- GeorgeClark - 11 Jun 2010

I have a possible fix for Render::_handleSquareBracketedLink - As the last step after the Web/Topic is normalized, it tests if the web exists. If the web does not exist, then it removes any subweb separators from the Web component, and concatenates the WebTopic back into a single topic name. Does this sound reasonable?

-- GeorgeClark - 14 Jun 2010

After some IRC discussion, it was decided that it is probably best to not try to guess when a link with a . is referencing a web, and when it's punctuation. It could be future links to a web that has not yet been created. So no changes will be made to Render.pm. Added a unit test that captures the invalid text. Also porting the fix back to 1.0.10

-- GeorgeClark - 20 Jun 2010

where's the unit test in 1.0.10 :} - fixed the nightly build - we can't presume to know where the foswiki baseURI is.

-- SvenDowideit - 21 Jun 2010

I've added the tests to the Release branch as well. They pass. Changing this to Waiting for Release.

-- GeorgeClark - 21 Jun 2010

Commenting is disabled while not logged in