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

Priority: Urgent
Current State: Closed
Released In: 1.0.10, 1.1.0
Target Release: patch
Applies To: Engine
Component:
Reported By: GeorgeClark
Waiting For:
Last Change By: KennethLavrsen
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
 

ItemTemplate edit

Summary Incorrect behavior when invalid web name built when converting spaced text to a topic name.
ReportedBy GeorgeClark
Codebase 1.0.9, trunk
SVN Range
AppliesTo Engine
Component
Priority Urgent
CurrentState Closed
WaitingFor
Checkins distro:1db802dd617e distro:8c9e1f9671ad distro:0a2058d58347 distro:9ebe53d5c741 distro:8b98c4291a1b distro:1c2426680553 distro:24bec9350d1b
TargetRelease patch
ReleasedIn 1.0.10, 1.1.0
Topic revision: r19 - 08 Sep 2010, KennethLavrsen
 
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. see CopyrightStatement. Creative Commons License