Page MenuHomePhabricator

Pipe (|) in inputs leads to hiding and possibly deletion of content
Closed, ResolvedPublic

Description

Using a | in a form input is currently problematic since | has a special meaning in templates. Doing this will put the page into a very bad state, and this cannot be recovered with "edit with form" since the | confuses SF as well. It is not possible to avoid this by clever template construction, since it already happens when parameter values are passed.

The problem can be avoided by replacing | with |. The example URL shows this workaround -- see older versions for what it looks like without it. Doing this escape in general, however, would break intentional mark-up, e.g. when a user includes a link with an alternative display text in a form input. I suggest to either parse the user input with the MW parser to distinguish those cases, or to have some option "verbatim" that can be declared for an input field when defining a form: this option should make SF escape all special characters, thus preventing most HTML or MW markups, but preserving the original writing. This should be very useful for wikis where users are completely unaware of the underlying wiki.

Note that this solution could also be useful in the context of Bug 19062. Also note that it is not possible to have a parser function that does the escaping in the template, since the special characters often affect the way in which parser functions are actually interpreted, and since mark-up like <!-- will never get to aparser function.

Tested on FF 3.0.10, MW 1.14alpha, SMW 1.5e-SVN, SF 1.6.


Version: unspecified
Severity: normal
URL: http://km.aifb.uni-karlsruhe.de/projects/owltests/index.php?title=Inconsistent-pattern-disjointness&oldid=3330

Details

Reference
bz19063

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:40 PM
bzimport set Reference to bz19063.
Yaron_Koren claimed this task.
Yaron_Koren subscribed.

This was finally fixed! Although pipes in the user input are now not escaped, but rather forbidden - unless they're part of template calls or parser functions, which has always worked fine.