Tags:
create new tag
, view all tags

Bug: special characters in comment field cause problems

using non-standard characters in the atttachment comment field causes problems.

Test case

upload a file and put something like changed {patch} to {name} as a comment. The metadata gets written to the topic text, see below for example. (the file used as a test case can be retrieved from ImageGalleryPluginDev)

This test case uses {} but I've also had problems with other ones recently (sorry don't remember which ones).

  • 03 Aug 2003: I remembered: putting a greater than angle bracket ( > ) in prematurely closes the parent a href link (when the attachment is placed into the topic text instead of just at the table at the end).

Environment

TWiki version: twiki.org
TWiki plugins: DefaultPlugin, EmptyPlugin, InterwikiPlugin
Server OS:  
Web server:  
Perl version:  
Client OS: windows xp
Web Browser: Mozilla Firebird 0.6.1

-- MattWilkie - 31 Jul 2003

Follow up

Fix record

This is a generic problem affecting the storage of "special" characters inside twiki variables. Specifically if you use any of % " { } inside any value in a TWikiVariable (Which includes META stuff) then whether this is unpacked correctly can rely rather heavily on the order various internal regular expressions are called. For example, if you try and put an URLPARAM inside an INCLUDE to control the topic (or section) being included this fails because the URLPARAM regex is performed first.

Similarly in other situations things that try to extract information from twiki markup (like META tags) can get confused by "early end" - cause by having the correct sequence of {,},% and " .

I've worked round this on my installation by escaping of values, and de-escaping them when they come to be used for anything. Part of the patch is (I think) included in the NamedIncludeSections patch. Ideally TWiki would store things like this encoded to avoid clashes (ala " ), but currently it doesn't. (Users shouldn't be typing markup, Twiki should detect it, and store it as markup)

-- MichaelSparks - 31 Jul 2003

I agree with Michael in that any part of TWiki that requires the user to know what is permittable to TWiki's innards is undesirable. What chokes TWiki's innards should be protected by TWiki's outards but be invisible to the user so as not to incresae the user's cognative load. For me this includes allowing users to:

  • Have any character in comments
  • Permit and preserve practially* any character in the file names uploaded
    • * Notwithstanding ':' which would need mapping to something else in the event of beign downloaded by a Windows box
  • ... insert more here.

I was going to write any character in a wiki word but that does bring up interesting questions about what to allow in WikiWords though given that one day you might want to provide extensions to the WikiWord processing using all of $^&()+-[];'"<>,\?~`! to add to *=:@#%./|{} already in use.

  • It somewhat saddens me though to think that architectural matters like these have not been fully specified and documented, as if we are dealing with each case as it comes along then the spec and/or coding complexity will increase geometrically and the cases increase linearly.

This is YetAnotherExampleOfWastedPatches caused by not having a TWikiPatchMaster, dear CoreTeam.

-- MartinCleaver - 31 Jul 2003

I don't really know what to do with this topic, so I'm bumping it. Should it be archived or copied into the Bugs web?

-- RafaelAlvarez - 17 Aug 2008

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch cygwin.patch r1 manage 2.1 K 2003-07-31 - 18:05 MattWilkie add $IDENTIFY, chg {path} to {name}
Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2008-08-24 - TWikiJanitor
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.