create new tag
, view all tags

Implemented: Properly encode parameters for form fields with ENCODE variable

Search forms like FormattedSearchFormTesting and TWikiApplication sometimes show URL parameters in a form field using the %URLPARAM{...}% variable. URL parameters need to be encoded properly into HTML entities before passing it into a form field. There are two enhancements to do that:

1. ENCODE variable with type parameter

The existing %URLENCODE{...}% variable is renamed to %ENCODE{...}%, and a new type parameter is added. The URLENCODE variable is kept as an undocumented feature to be backward compatible. The type parameter can be set to "url" for URL encoding (default), or "entity" to encode special characters into HTML entities. Other encoding types can be added in the future as needed.

Example <input type="text" name="myparam" value="%ENCODE{ "%PARAM{ "myparam" }%" type="entity" }%" />

2. PARAM veriable with encode parameter

The existing %URLPARAM{...}% variable is renamed to %PARAM{...}%, and a new encode parameter is added. The URLPARAM variable is kept as an undocumented feature to be backward compatible. The encode parameter can be set to "url" for URL encoding, or "entity" to encode special characters into HTML entities, default is no encoding. Renaming the variable is in preparation of ParameterizedIncludes.

Example <input type="text" name="myparam" value="%PARAM{ "myparam" encode="entity" }%" />

-- PeterThoeny - 14 Jan 2004

Sample form

Silly example:
You entered: %PARAM{myparam}%
URL encoded: %ENCODE{%PARAM{myparam}%}%
Entity encoded:  

Try out above form. All it does is to show the submitted text in the text field. It should work for these special characters: (please report if you experience any problem)

Char Problem Fix
" Double quote and text after disappears because it gets interpreted as the end of the value parameter Escape with &#034;
% Variables like %WEB% and %INCLUDE{...}% get expanded Escape percent sign with &#037;
*, _, = TWiki formatting like *bold*, _italic_ and =fixed= get interpreted Escape with &#042;, &#095;, &#061;
[, ] [[][]] links like [[WebHome][home]] get interpreted Escape with &#091;, &#093;
<, > HTML tags get interpreted, like when you enter normal<italic>normal Escape with &#060;, &#062;
| Fails if form field is in a TWiki table Escape with &#124;
WikiWord WikiWords get autolinked Place whole form into <noautolink> tags

Above characters need to be converted into their HTML entities if placed in HTML form fields.

Possible solutions

1. Introduce new ENTITYENCODE variable

The %ENTITYENCODE{...}% variable (any better name?) encodes special characters into HTML entities.

Example %ENTITYENCODE{ "%URLPARAM{ "myparam" }%" }%

Pros and cons:

  • smile Simple to use
  • smile Consistent with existing %URLENCODE{...}% variable
  • frown Slightly slower rendering due to new variable

2. Add an encode parameter to URLPARAM variable

Special characters get translated into their HTML entities if the encode="entity parametr is specified.

Example %URLPARAM{ "myparam" encode="entity" }%

Pros and cons:

  • smile Simple to use

3. Add a translate parameter to URLPARAM variable

The translate parameter can be used to change special characters into their HTML entities. The parameter has comma delimited from,to pairs; $quot represents the double quote char.

Example %URLPARAM{ "myparam" translate="$quot, &#034;, %, &#037;, <, &#060;, >, &#062;, |, &#124;" }%

Pro and cons:

  • smile Flexible to do all types of conversions, not just HTML entities
  • frown More complex to use

4. Rename URLENCODE to ENCODE and add type parameter

Rename %URLENCODE{...}% to %ENCODE{...}%, but keep URLENCODE as an undocumented feature to be backward compatible. Add a type parameter: type="url" for URL encode (default), type="entity" to encode special characters into HTML entities.

Example %ENCODE{ "%PARAM{ "myparam" }%" type="entity" }%

Pros and cons:

-- PeterThoeny - 14 Jan 2004



-- PeterThoeny - 14 Jan 2004

I like option 2. However, is there any reason to encode something that is not from a url parameter where option 1 would be required?

-- SamHasler - 14 Jan 2004

An interesting failure above is that if you enter a closing right angle bracket, for example, ,test> in above field, the submit button disappears. The vertical bar gets interpreted (into a table cell separator), as are TWiki variables.

-- ThomasWeigert - 14 Jan 2004

At work I got feedback for option 4. I like option 2 and 4, favoring option 4.

Option 2 has the advantage that a Plugin can use it without breaking an older TWiki installation (just fallback of not supporting special chars)

Option 4 has the advantage that content not received by URL parameter can be encoded as Sam pointed out. It also is extensible for other encoding types added in the future.

-- PeterThoeny - 14 Jan 2004

I implemented option 2 and 4 because it was easy and it does not degrade the performance.

A small change to the parameter parsing of variables was necessary so that double quotes are treated properly: The nameless parameter may now contain double quotes. Example:

%ANYVAR{ "now you can use "quoted text" in the nameless parameter" param="one" more="etc" }%

Change is in TWikiAlphaRelease and TWiki.org.

-- PeterThoeny - 14 Jan 2004

Using this could you put the simple search and advanced search forms from the WebSearch page on separate topics (alternatively paramaterised includes could be used to keep the forms on the WebSearch topic) and have the search results contain the forms for easy re-searching with the search parameters as they were entered for the search?

-- SamHasler - 15 Jan 2004

Sounds like a good idea, split up into WebSearch and WebSearchAdvanced should be done.

-- PeterThoeny - 14 Jan 2004

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2004-05-20 - PeterThoeny
  • 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-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.